I know!! was trying to pass some optimism on to the hunters: D
I'm scanning address 61;)
That is a good idea. Feel free to post your keyspaces for us to check.
@Bajula, sure
. 
Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 304. (Read 230098 times)
I know!! was trying to pass some optimism on to the hunters: D
I'm scanning address 61;)
That is a good idea. Feel free to post your keyspaces for us to check.
@Bajula, sure
. 
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!!!
Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.
I know!! was trying to pass some optimism on to the hunters: D
I'm scanning address 61;)
Good luck
So, speaking of case 61:
In my case, what I do is mix randomness with full range scan. I keep the range small enough to get reasonable waiting time (say 10 min) .
This is an example:
1) generate all possibles 5 bits number: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
2) pick a random 5 hex digit number (20bit) : for instance CADE9
we have now 16 possibles header for our key
10CADE9
11CADE9
12CADE9
13CADE9
14CADE9
15CADE9
16CADE9
17CADE9
18CADE9
19CADE9
1ACADE9
1BCADE9
1CCADE9
1DCADE9
1ECADE9
1FCADE9
3) call 16 instances of Bitcrack fully scanning following 16 ranges
10CADE9000000000:10CADE9FFFFFFFFF
11CADE9000000000:11CADE9FFFFFFFFF
12CADE9000000000:12CADE9FFFFFFFFF
13CADE9000000000:13CADE9FFFFFFFFF
14CADE9000000000:14CADE9FFFFFFFFF
15CADE9000000000:15CADE9FFFFFFFFF
16CADE9000000000:16CADE9FFFFFFFFF
17CADE9000000000:17CADE9FFFFFFFFF
18CADE9000000000:18CADE9FFFFFFFFF
19CADE9000000000:19CADE9FFFFFFFFF
1ACADE9000000000:1ACADE9FFFFFFFFF
1BCADE9000000000:1BCADE9FFFFFFFFF
1CCADE9000000000:1CCADE9FFFFFFFFF
1DCADE9000000000:1DCADE9FFFFFFFFF
1ECADE9000000000:1ECADE9FFFFFFFFF
1FCADE9000000000:1FCADE9FFFFFFFFF
goto step 2 and repeat.
each cycle will take 16*10min = 160 min if you have one GPU.
This trick will increase your likelihood in finding the key as times increases and not wait 180 years (1GPU) or 5 years (36GPUs). LOL
a random 5 hex digit is one of 1,048,575 if you get it right, you have the key in 160 min with only one GPU
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!!!
Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.
If you don't mind, I'm going to totally steal that and use it in conversation - lucky256
I'm still snickering over that.
https://imgur.com/9V8vq4O
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!!!
Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.
I know!! was trying to pass some optimism on to the hunters: D
I'm scanning address 61;)
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!!!
Very good! Good luck!
You have to be lucky256 to hit an address in 256 bit range.
in this script, pubkeys, where from you get pubkeys ?
In general you get the pubkeys from a transaction that has been sent from the target address (spent).
For puzzle key #60:
https://www.blockchain.com/btc/tx/6c08747ecd15904128c3f15f3bf47f6f365405da2661f17eb5119008807cee3e
ScriptSig: PUSHDATA(72)[3045022100b0d935af1a8b20186c2cd3e43dddb391d85acbfab890f025e683bc0da2534de702200b7816d64a59579da5328fbfd7ddd34b19ad864915fe2474338e53d04131257f01]
PUSHDATA(33)0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d
Compressed public key in red: 0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d
You can convert between compressed and uncompressed public key here:
https://iancoleman.io/bitcoin-key-compression/
But better use python and use bitcoin library. E.g.:
Code:
import bitcoin as b
pubkey = b.decode_pubkey("0348e843dc5b1bd246e6309b4924b81543d02b16c8083df973a89ce2c7eb89a10d")
print("X:", hex(pubkey[0]), "Y:", hex(pubkey[1]))
Just research little on your own from here.
What memory size are your rx480?
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
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 ...
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
True
with -c -u you get half the speed
!Never tried it, because most of non empty BTC addresses are compressed
83Mkey/s now!!!
:-D
try with one target
bc.exe -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
https://imgur.com/9V8vq4O
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!!!
What memory size are your rx480?
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
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 ...
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
True
with -c -u you get half the speed
!Never tried it, because most of non empty BTC addresses are compressed
83Mkey/s now!!!
:-D
try with one target
bc.exe -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -o ohmygodimrich.txt -b 72 -t 256 -p 1024 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
What memory size are your rx480?
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
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 ...
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
True
with -c -u you get half the speed
!Never tried it, because most of non empty BTC addresses are compressed
83Mkey/s now!!!
:-D
@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.
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
baby-step-giant-step (--> http://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/):
you create two lists, the first one (the baby steps list) in a hash table stored in the Ram and the second one (the giant steps list) dynamic:
a) (baby steps list): each baby step is equal to 1 (the distance between 2 consecutive elements is 1*G) and we store all these public keys: (0G), 1*G, 2*G, 3*G, 4*G, 5*G, ..., 2^30*G (because sqrt(2^60) = 2^30) in a hash table
b) (giant steps list): each giant step is equal to the sqrt(space size), in our case sqrt(2^60) = 2^30, namely the distance between 2 elements is 2^30*G . We generate on fly this list:
P, P - 2^30*G, P - 2*2^30*G, P - 3*2^30*G, P - 4*2^30*G, P - 5*2^30*G, ....., P - (2^30 - 1)*2^30*G
and we check if there is a element in the giant-steps list equal to an element in the baby-steps list.
If for example P - 5*2^30*G = 1000*G, then P = 5*2^30*G + 1000*G
--> P = (5*2^30 + 1000) * G --> private key k = (5*2^30 + 1000)
2 lists, 2^30 elements * 2^30 elements = 2^60 comparisons without doing 2^60 operations, this is the trick.
you create two lists, the first one (the baby steps list) in a hash table stored in the Ram and the second one (the giant steps list) dynamic:
a) (baby steps list): each baby step is equal to 1 (the distance between 2 consecutive elements is 1*G) and we store all these public keys: (0G), 1*G, 2*G, 3*G, 4*G, 5*G, ..., 2^30*G (because sqrt(2^60) = 2^30) in a hash table
b) (giant steps list): each giant step is equal to the sqrt(space size), in our case sqrt(2^60) = 2^30, namely the distance between 2 elements is 2^30*G . We generate on fly this list:
P, P - 2^30*G, P - 2*2^30*G, P - 3*2^30*G, P - 4*2^30*G, P - 5*2^30*G, ....., P - (2^30 - 1)*2^30*G
and we check if there is a element in the giant-steps list equal to an element in the baby-steps list.
If for example P - 5*2^30*G = 1000*G, then P = 5*2^30*G + 1000*G
--> P = (5*2^30 + 1000) * G --> private key k = (5*2^30 + 1000)
2 lists, 2^30 elements * 2^30 elements = 2^60 comparisons without doing 2^60 operations, this is the trick.
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.
in this script, pubkeys, where from you get pubkeys ?
What memory size are your rx480?
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
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 ...
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
True
with -c -u you get half the speed
!Never tried it, because most of non empty BTC addresses are compressed
What memory size are your rx480?
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
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 ...
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
What memory size are your rx480?
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
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 ...
What memory size are your rx480?
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?
5 years pass quickly :-D LOL
i have 40Mkeys per gpu(Is there any way to improve?)
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
Try this
bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 2048
now 50Mkey/s
Is that correct?
add 61
from: dec:1152921504606846976- hex:1000000000000000
to: dec:2305843009213693953- hex:2000000000000001
add62
from: dec:2305843009213693953 - hex:2000000000000001
to: dec:4611686018427387904 - hex:4000000000000000
addr63
from: dec:4611686018427387904- hex:4000000000000000
to: dec:9223372036854775808 - hex:8000000000000000
addr64
from: dec:9223372036854775808 - hex: 8000000000000000
to: dec:18446744073709551616 - hex:010000000000000000
addr65
from: dec:18446744073709551616 - hex:010000000000000000
to: dec:36893488147419103232 - hex: 020000000000000000
add 61
from: dec:1152921504606846976- hex:1000000000000000
to: dec:2305843009213693953- hex:2000000000000001
add62
from: dec:2305843009213693953 - hex:2000000000000001
to: dec:4611686018427387904 - hex:4000000000000000
addr63
from: dec:4611686018427387904- hex:4000000000000000
to: dec:9223372036854775808 - hex:8000000000000000
addr64
from: dec:9223372036854775808 - hex: 8000000000000000
to: dec:18446744073709551616 - hex:010000000000000000
addr65
from: dec:18446744073709551616 - hex:010000000000000000
to: dec:36893488147419103232 - hex: 020000000000000000
Addr61Range
0x1000000000000000:0x1FFFFFFFFFFFFFFF
Addr62Range
0x2000000000000000:0x2FFFFFFFFFFFFFFF
Etc
Tks
How do you share works among your cards?
We can PM if you wish.
Hello
I created the addrdata.txt file with 45,000 abandoned addresses, including those of the puzzle
I am currently scanning address 61
bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
All help and tips are welcome! :-D
Hi Netlakes
in you command:
bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
with -d 1 you use one card.
I understand you have 36 rx480, right?
(newbies can't PM you lol )
Yes, i have 6 rigs with 6 rx480 each
for each rig i run multiple instances like that:
bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 2 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 3 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 4 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 5 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 6 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
This way you are scanning the same range 1000000000000000:1FFFFFFFFFFFFFFF for all cards !!!! that's no good.
the range 1000000000000000:1FFFFFFFFFFFFFFF should be split equally, you could do it manually or using the command --share M/N for each rig.
for sure!
I'm setting it up again!
I'll add also added --continue last.txt
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.
i have 40Mkeys per gpu(Is there any way to improve?)
use b 36 t 512 p 2304
CL_INVALID_WORK_SIZE
5 years pass quickly :-D LOL
i have 40Mkeys per gpu(Is there any way to improve?)
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
Try this
bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 72 -t 256 -p 2048
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
As a general rule
-b is twice your computing unit (Rx480 have usually 36)
-t 256 (I believe it is the max)
-p (depends on you GPU ram) 1024 for 4Gb and 2048 for 8Gb
As a general rule
-b is twice your computing unit (Rx480 have usually 36)
-t 256 (I believe it is the max)
-p (depends on you GPU ram) 1024 for 4Gb and 2048 for 8Gb
-b is twice your computing unit (Rx480 have usually 36)
-t 256 (I believe it is the max)
-p (depends on you GPU ram) 1024 for 4Gb and 2048 for 8Gb
Is that correct?
add 61
from: dec:1152921504606846976- hex:1000000000000000
to: dec:2305843009213693953- hex:2000000000000001
add62
from: dec:2305843009213693953 - hex:2000000000000001
to: dec:4611686018427387904 - hex:4000000000000000
addr63
from: dec:4611686018427387904- hex:4000000000000000
to: dec:9223372036854775808 - hex:8000000000000000
addr64
from: dec:9223372036854775808 - hex: 8000000000000000
to: dec:18446744073709551616 - hex:010000000000000000
addr65
from: dec:18446744073709551616 - hex:010000000000000000
to: dec:36893488147419103232 - hex: 020000000000000000
add 61
from: dec:1152921504606846976- hex:1000000000000000
to: dec:2305843009213693953- hex:2000000000000001
add62
from: dec:2305843009213693953 - hex:2000000000000001
to: dec:4611686018427387904 - hex:4000000000000000
addr63
from: dec:4611686018427387904- hex:4000000000000000
to: dec:9223372036854775808 - hex:8000000000000000
addr64
from: dec:9223372036854775808 - hex: 8000000000000000
to: dec:18446744073709551616 - hex:010000000000000000
addr65
from: dec:18446744073709551616 - hex:010000000000000000
to: dec:36893488147419103232 - hex: 020000000000000000
Addr61Range
0x1000000000000000:0x1FFFFFFFFFFFFFFF
Addr62Range
0x2000000000000000:0x2FFFFFFFFFFFFFFF
Etc
Tks
How do you share works among your cards?
We can PM if you wish.
Hello
I created the addrdata.txt file with 45,000 abandoned addresses, including those of the puzzle
I am currently scanning address 61
bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
All help and tips are welcome! :-D
Hi Netlakes
in you command:
bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
with -d 1 you use one card.
I understand you have 36 rx480, right?
(newbies can't PM you lol )
Yes, i have 6 rigs with 6 rx480 each
for each rig i run multiple instances like that:
bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 2 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 3 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 4 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 5 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
bc.exe -c -u -d 6 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096
This way you are scanning the same range 1000000000000000:1FFFFFFFFFFFFFFF for all cards !!!! that's no good.
the range 1000000000000000:1FFFFFFFFFFFFFFF should be split equally, you could do it manually or using the command --share M/N for each rig.
for sure!
I'm setting it up again!
I'll add also added --continue last.txt
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.
i have 40Mkeys per gpu(Is there any way to improve?)
use b 36 t 512 p 2304
Jump to: