Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 228. (Read 192829 times)

1 target =  86 Mkey/s  -b 108 -t 256 -p 1024
45000 targets = 90 Mkeys/s  -b 72 -t 256 -p 1024

I already started my project.

bc.exe -d 1 --keyspace 000000000000000 -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF

LOL   

you are awesome!
thank you so much guys!!!

in this script, pubkeys, where from you get pubkeys ?

import bitcoin as b
pubkey = b.decode_pubkey("0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d")
print("X:", hex(pubkey[0]), "Y:", hex(pubkey[1]))

try with one target

bc.exe -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF  -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB

83Mkey/s now!!!

:-D

True

with -c -u  you get half the speed !
Never tried it, because most of non empty BTC addresses are compressed

@zielar: it is possible, I used the baby step giant step algorithm to retrieve the key #60 in about 80 seconds. And I have 32 GB ram.

space search for each key of the puzzle transaction:

key #1 : from 1 to 1   (2^0 -> 2^1 - 1)
key #2 : from 2 to 3   (2^1 -> 2^2 - 1)
key #3 : from 4 to 7   (2^2 -> 2^3 - 1)
key #4 : from 8 to 15 (2^3 -> 2^4 - 1)
....
key #60: from 2^59 to 2^60 - 1

Let's say for semplicity that our space search in this case is 2^60 (actually is only half, 2^59).

P is the public key, we want to find the private key k. If G is the generator of the curve, the private key k is the number :

k*G = P


Hash table: 2^30 entries, each entry has the coordinate x of the public key (256 bit) + the number of the private key (max 32 bit). I'm using only the first 32 bits of the x instead of 256 bits (there are only few false collisions looking at the first 32 bits and I check these collisions), then I need to store (32 + 32) * 2^30 bit, 2^36 bit, 8 GByte. The hash table actually has to have the double of the number of the keys in the baby steps list (to avoid collisions between two different "x" that share the same 32 bits), so I need at least 16 GByte.

With some other optimizations (the search space is actually 2^59 and not 2^60 + other properties of the secp256k1 curve), I can run the program.

When the search space is greater than 60 bit, let's say 62 bit, I can't store all the 2^31 public keys of the baby steps list at once in the Ram, then I split 2^31 in 2 lists of 2^30 elements, A e B, then first I check the entire giant steps list against the list A, and if there is no match, I generate the list B and I generate again the giant steps list.

Can you please check your performance with -u -c again please. I noticed you got 80Mkeys/s with compressed only.

[2019-02-22.19:47:44] [Info] Compression: compressed

with Rx480 4Gb, this must work better

bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 1024


also watch your core-clock and memory-clock
no need to overclock,  you won't gain much. In fact you can lower core clock to 975MHz, you will still get around 100MKeys/s ...
 

4GB

I downloaded the latest version of bitcrack!

Is compiling ....

I think it was the old version that was giving me half of mkey / s

What memory size are your rx480?

One target or 45000 target won't change much.

Try this


bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 2048

use b 36 t 512 p 2304

Look here
[2019-02-22.19:47:44] [Info] Compression: compressed
[2019-02-22.19:47:44] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000000000001
[2019-02-22.19:47:44] [Info] Ending at:   F000000000000000000000000000000000000000000000000000000000000000
[2019-02-22.19:47:44] [Info] Counting by: 000000000C6323BDF5ED6969A34C18CA8E09B4CE2B7A6ED00F931CBAE8DBF0E8
[2019-02-22.19:47:44] [Info] Compiling OpenCL kernels...
[2019-02-22.19:47:51] [Info] Initializing Ellesmere
[2019-02-22.19:47:53] [Info] Generating 37,748,736 starting points (1440.0MB)
[2019-02-22.19:48:05] [Info] 10.0%
[2019-02-22.19:48:15] [Info] 20.0%
[2019-02-22.19:48:23] [Info] 30.0%
[2019-02-22.19:48:33] [Info] 40.0%
[2019-02-22.19:48:42] [Info] 50.0%
[2019-02-22.19:48:51] [Info] 60.0%
[2019-02-22.19:49:00] [Info] 70.0%
[2019-02-22.19:49:09] [Info] 80.0%
[2019-02-22.19:49:18] [Info] 90.0%
[2019-02-22.19:49:20] [Info] 100.0%
[2019-02-22.19:49:20] [Info] Done
[2019-02-22.19:49:20] [Info] Loading addresses from 'btc.txt'
[2019-02-22.19:49:36] [Info] 2,749,473 addresses loaded (52.4MB)
Ellesmere        2368/6509MB | 2749473 targets 81.53 MKey/s (69,684,166,656 total) [00:13:53]

I get over 80MKey/s  on one Rx480 with 2,749,473 targets

5 years pass quickly :-D LOL
i have 40Mkeys per gpu(Is there any way to improve?)

One target or 45000 target won't change much.

Try this


bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 2048

Good speed increase if you only want to target the #61 puzzle address.

• Only -c
• Only one target: 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
• Make sure to use latest BitCrack version from github. There have been good speed improvements to the OpenCL version recently
• Check your settings. For Cuda I have better performance with more threads (~512) instead of high processes

GL HF

5 years pass quickly :-D LOL
i have 40Mkeys per gpu(Is there any way to improve?)

OK
I suppose you are getting around 100Mkeys/sec search rate per GPU?
So with 36*100 Mkeys/sec and if we assume that the  private key for puzzle #61 is at  mid  range between 0x10000000000000 and 0x1FFFFFFFFFFFFFFF, you should expect to find  this key in 5 years.