Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 303. (Read 230098 times)
In fact, the code in this puzzle, I think, is the 310 bitcoin private keys, and these private keys are scattered and hidden in the picture, like playing a puzzle game, to find them and put them together correctly! Sounds simple, but a little bit of cryptography knows how to work out the combination of private keys by manpower, and it is estimated that it will not be worked out by the day of entering the coffin. The last thing Lao Shi regrets in his life is that he didn't study hard at the beginning. If he could study hard at the beginning, he would develop towards cryptography experts or mathematicians. It's not a piece of cake to crack such puzzles. It's hard to knock on keyboards every day like now. Therefore, the folks who have become parents must educate their children to listen from an early age. Ha-ha.
Hi guys,
In continuation to this thread: https://bitcointalksearch.org/topic/brute-force-on-bitcoin-addresses-video-of-the-action-1305887
While playing around with my bot, I found out this mysterious transaction:
https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.
For example:
Address 2:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3
Address 3:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7
Address 4:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8
Address 5:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15
Address 6:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31
Address 7:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C
Address 8:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0
Address 9:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3
Address 10:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202
Address 11:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483
Address 12:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b
Address 13:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460
Address 14:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930
and so on...
until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.
Any ideas what's the formula behind the generation of these addresses?
Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?
The prize would be ~32 BTC
EDIT: If you find the solution feel free to leave a tip 1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3
Did anyone ever have any luck cracking these? In continuation to this thread: https://bitcointalksearch.org/topic/brute-force-on-bitcoin-addresses-video-of-the-action-1305887
While playing around with my bot, I found out this mysterious transaction:
https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.
For example:
Address 2:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3
Address 3:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7
Address 4:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8
Address 5:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15
Address 6:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31
Address 7:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C
Address 8:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0
Address 9:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3
Address 10:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202
Address 11:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483
Address 12:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b
Address 13:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460
Address 14:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930
and so on...
until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.
Any ideas what's the formula behind the generation of these addresses?
Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?
The prize would be ~32 BTC
EDIT: If you find the solution feel free to leave a tip
1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3Please explain more what " -r
"-r 61" will make all points start at a random offset in 61 bit range.
The 3 sample starting points are just for information/confirmation the correct range is used.
If your BitCrack is generating 37,748,736 starting points then each point starts at a random offset in 61 bit range.
It is easy to adjust the code now. Simply adjust in generateStartingPoints() function.
You can combine -r with --keyspace if you need to additional control.
Please "git pull" to get the latest version that also contains fixes.
Yes ... still a OpenCL novice lol (I am too old now, maybe not you lol)
I've asked brichard19 about it ... he does not seem to be interested.
I am no youngling too but I like code. I can make adjustments to Cuda but have no experience with OpenCL yet so lets see.
Ok, let us know
Initial version
https://github.com/pikachunakapika/BitCrack
use -r
Please notice:
The total movement relative to each random starting point is defined by total processed keys / number of starting points.
E.g. if BitCrack generated 200,000 starting points and your total processed keys is 4,000,000. Each point moved by (only) 20 steps.
This is by original design and the only way to benefit from the huge parallel processing power of GPUs.
Tested OpenCL and Cuda with Nvidia Device on Linux.
Not tested on Windows. Please give feedback!
Please explain more what " -r
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
try all, and nothing
Quote
C:\Users\kknd\Desktop>clBitCrack.exe -c --keyspace 13CADE9000000000:13CADE9FFFFFFFFF -i 1btc.txt -o kknd.txt -b 128 -t 512 -p 1024
[2019-02-23.03:55:15] [Info] Compression: compressed
[2019-02-23.03:55:15] [Info] Starting at: 00000000000000000000000000000000000000000000000013CADE9000000000
[2019-02-23.03:55:15] [Info] Ending at: 00000000000000000000000000000000000000000000000013CADE9FFFFFFFFF
[2019-02-23.03:55:15] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2019-02-23.03:55:15] [Info] Compiling OpenCL kernels...
[2019-02-23.03:55:15] [Info] Initializing Tesla V100-SXM2-16GB
[2019-02-23.03:55:26] [Info] Generating 67,108,864 starting points (2560.0MB)
[2019-02-23.03:55:41] [Info] 10.0%
[2019-02-23.03:55:42] [Info] 20.0%
[2019-02-23.03:55:43] [Info] 30.0%
[2019-02-23.03:55:43] [Info] 40.0%
[2019-02-23.03:55:43] [Info] 50.0%
[2019-02-23.03:55:44] [Info] 60.0%
[2019-02-23.03:55:44] [Info] 70.0%
[2019-02-23.03:55:44] [Info] 80.0%
[2019-02-23.03:55:44] [Info] 90.0%
[2019-02-23.03:55:44] [Info] 100.0%
[2019-02-23.03:55:44] [Info] Done
[2019-02-23.03:55:45] [Info] Loading addresses from '1btc.txt'
[2019-02-23.03:55:48] [Info] 466,284 addresses loaded (8.9MB)
Tesla V100-SXM2- 4112/16258MB | 466284 targets 546.19 MKey/s (68,451,041,280 total) [00:02:03][2019-02-23.03:57:54] [Info] Reached end of keyspace
[2019-02-23.03:55:15] [Info] Compression: compressed
[2019-02-23.03:55:15] [Info] Starting at: 00000000000000000000000000000000000000000000000013CADE9000000000
[2019-02-23.03:55:15] [Info] Ending at: 00000000000000000000000000000000000000000000000013CADE9FFFFFFFFF
[2019-02-23.03:55:15] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2019-02-23.03:55:15] [Info] Compiling OpenCL kernels...
[2019-02-23.03:55:15] [Info] Initializing Tesla V100-SXM2-16GB
[2019-02-23.03:55:26] [Info] Generating 67,108,864 starting points (2560.0MB)
[2019-02-23.03:55:41] [Info] 10.0%
[2019-02-23.03:55:42] [Info] 20.0%
[2019-02-23.03:55:43] [Info] 30.0%
[2019-02-23.03:55:43] [Info] 40.0%
[2019-02-23.03:55:43] [Info] 50.0%
[2019-02-23.03:55:44] [Info] 60.0%
[2019-02-23.03:55:44] [Info] 70.0%
[2019-02-23.03:55:44] [Info] 80.0%
[2019-02-23.03:55:44] [Info] 90.0%
[2019-02-23.03:55:44] [Info] 100.0%
[2019-02-23.03:55:44] [Info] Done
[2019-02-23.03:55:45] [Info] Loading addresses from '1btc.txt'
[2019-02-23.03:55:48] [Info] 466,284 addresses loaded (8.9MB)
Tesla V100-SXM2- 4112/16258MB | 466284 targets 546.19 MKey/s (68,451,041,280 total) [00:02:03][2019-02-23.03:57:54] [Info] Reached end of keyspace
Ok
but the trick is not to choose 5 digit HEX manually and once... you can write a shell script loop to it automatically. CADE9 is just one out of 1,048,576
Yes ... still a OpenCL novice lol (I am too old now, maybe not you lol)
I've asked brichard19 about it ... he does not seem to be interested.
I am no youngling too but I like code. I can make adjustments to Cuda but have no experience with OpenCL yet so lets see.
Ok, let us know
Initial version
https://github.com/pikachunakapika/BitCrack
use -r
Please notice:
The total movement relative to each random starting point is defined by total processed keys / number of starting points.
E.g. if BitCrack generated 200,000 starting points and your total processed keys is 4,000,000. Each point moved by (only) 20 steps.
This is by original design and the only way to benefit from the huge parallel processing power of GPUs.
Tested OpenCL and Cuda with Nvidia Device on Linux.
Not tested on Windows. Please give feedback!
Yes ... still a OpenCL novice lol (I am too old now, maybe not you lol)
I've asked brichard19 about it ... he does not seem to be interested.
I am no youngling too but I like code. I can make adjustments to Cuda but have no experience with OpenCL yet so lets see.
Ok, let us know
Yes ... still a OpenCL novice lol (I am too old now, maybe not you lol)
I've asked brichard19 about it ... he does not seem to be interested.
I am no youngling too but I like code. I can make adjustments to Cuda but have no experience with OpenCL yet so lets see.
You can't ignore ranges completely because bitcrack is not designed so. If you start an offset for each GPU working point, things will awfully slow down ...
You have to adjust the initial point generation, remove the first point doubling kernel and adjust the result reporting slightly.
Everything else can remain almost untouched and will not influence performance.
It would be nice if you could do that
K. You need OpenCL too, right?
Yes ... still a OpenCL novice lol (I am too old now, maybe not you lol)
I've asked brichard19 about it ... he does not seem to be interested.
You can't ignore ranges completely because bitcrack is not designed so. If you start an offset for each GPU working point, things will awfully slow down ...
You have to adjust the initial point generation, remove the first point doubling kernel and adjust the result reporting slightly.
Everything else can remain almost untouched and will not influence performance.
It would be nice if you could do that
K. You need OpenCL too, right?
......
Could you please give quickly this last output in hex using bitcrack keyrange format because they seem wrong to me.
The first one
1149318624904950579 1156524384308743373
which is:
FF3333333333333:100CCCCCCCCCCCCD
does not seem to be correct for case 61
You can't ignore ranges completely because bitcrack is not designed so. If you start an offset for each GPU working point, things will awfully slow down ...
You have to adjust the initial point generation, remove the first point doubling kernel and adjust the result reporting slightly.
Everything else can remain almost untouched and will not influence performance.
It would be nice if you could do that
Look at this:
I was doing some calculations and realized the following:
Ex:
the private key of address 60 in decimal is:
1135041350219496382
It had 0.54btc of balance
2 ^ 60-2 ^ 54 = 1134907106097364992
Does it make any sense ??
1135041350219496382
1134907106097364992
I was doing some calculations and realized the following:
Ex:
the private key of address 60 in decimal is:
1135041350219496382
It had 0.54btc of balance
2 ^ 60-2 ^ 54 = 1134907106097364992
Does it make any sense ??
1135041350219496382
1134907106097364992
You can't ignore ranges completely because bitcrack is not designed so. If you start an offset for each GPU working point, things will awfully slow down ...
You have to adjust the initial point generation, remove the first point doubling kernel and adjust the result reporting slightly.
Everything else can remain almost untouched and will not influence performance.
a continuation
6) The Paradox of Birthdays as an average prvkey distribution.
We look at the table from paragraph (2 + 3).
"probability theory as an average distribution" (paragraph (2)) is very good when the number of prvkeys is much more than the number of parts of N.
But we have just the opposite! We need a lot more prvkeys to get the uniformity of the average distribution.
It's still too early for this probability - the data is simply not enough.
But for the classic Paradox of Birthdays - the most it!
Ie, it is still too early for us to wait there where it was not yet, but we have to wait there where it already was! Paradox!
We calculate the probability of PofB for known prvkeys, reducing N from 1000.
- there is an alternation, so that the PofB works odd/even;
- when PofB works - it could be found by performing 10-40% of the entire work of the range;
- every 5-8 prvkeys there is an uncertainty on 2-3 prvkeys (22-23) (26-27) (31-32) (35-56) (38-39) (48-49-50) (56-57)
#55 could be found by performing 5.2% of the entire work of the range, dividing the range 2^55 into 1000 parts, and checking only 52 parts, where at 38 there was a prvkey.
The last time the uncertainty was recently, so you can expect stability 2-4 steps.
Since if #60 had a low probability of paradox, then #61 would have a high.
Calculate the ranges for #61 by performing 30% of the entire work of the range.
=================================
post update
- fix some bad automatic translate
- fix range, fail border
1149318624904950579 1156524384308743373
1152921504606846976 1156524384308743373
6) The Paradox of Birthdays as an average prvkey distribution.
We look at the table from paragraph (2 + 3).
"probability theory as an average distribution" (paragraph (2)) is very good when the number of prvkeys is much more than the number of parts of N.
But we have just the opposite! We need a lot more prvkeys to get the uniformity of the average distribution.
It's still too early for this probability - the data is simply not enough.
But for the classic Paradox of Birthdays - the most it!
Ie, it is still too early for us to wait there where it was not yet, but we have to wait there where it already was! Paradox!
We calculate the probability of PofB for known prvkeys, reducing N from 1000.
Code:
C:\Python37\3\3>C:\Python37\python.exe birthday_gen.py
[calc_stat_for_know_keys]
(decr group_N -> recalc N, clean of intersect -> find pair)
[#] decimalKey in [n/N](start_n, end_n)
[i] Birthday paradox: P(N) % (N/group_N = ScopeOfJob %)
[60] 1135041350219496382 in [32/32](1135004854555241826, 1145485959142576798)
[i] Birthday paradox: 100.0 % (32/55=58.18%)
[59] 525070384258266191 in [42/48](525067402010273812, 526930246477961196)
[i] Birthday paradox: 99.8 % (48/198=24.24%)
[58] 199976667976342049 in [5/13](181218507180000013, 199988258920252172)
[i] Birthday paradox: 99.2 % (13/21=61.9%)
[57] 138245758910846492 in [37/39](138244799370002046, 139092535770448258)
[i] Birthday paradox: 100.0 % (39/85=45.88%)
[56] 44218742292676575 in [10/37](44215844467503839, 44677752121593121)
[i] Birthday paradox: 100.0 % (37/78=47.44%)
[55] 30045390491869460 in [38/52](30042326262253355, 30060340660762837)
[i] Birthday paradox: 74.1 % (52/1000=5.2%)
[54] 9974455244496707 in [3/17](9971837456176469, 10425839084811435)
[i] Birthday paradox: 100.0 % (17/24=70.83%)
[53] 6763683971478124 in [26/46](6747090216651001, 6763708665460487)
[i] Birthday paradox: 98.3 % (46/271=16.97%)
[52] 4216495639600700 in [6/7](4045973546795871, 4219893567293446)
[i] Birthday paradox: 91.5 % (7/11=63.64%)
[51] 2058769515153876 in [39/42](2050595615694800, 2058770198712368)
[i] Birthday paradox: 99.6 % (42/171=24.56%)
[50] 611140496167764 in [2/18](592612914657143, 611377913104521)
[i] Birthday paradox: 99.9 % (18/30=60.0%)
[49] 409118905032525 in [17/36](409117085870718, 413069957531010)
[i] Birthday paradox: 100.0 % (36/93=38.71%)
[48] 191206974700443 in [14/36](191201537860455, 192698745183385)
[i] Birthday paradox: 100.0 % (36/94=38.3%)
[47] 119666659114170 in [29/36](119023196097019, 119668780905989)
[i] Birthday paradox: 99.9 % (36/109=33.03%)
[46] 51408670348612 in [21/43](51408605559994, 51480557241158)
[i] Birthday paradox: 85.1 % (43/489=8.79%)
[45] 19996463086597 in [3/28](19688431486077, 19997066328963)
[i] Birthday paradox: 100.0 % (28/57=49.12%)
[44] 15404761757071 in [36/41](15381558444507, 15404767133221)
[i] Birthday paradox: 89.4 % (41/379=10.82%)
[43] 7409811047825 in [19/25](7409146480081, 7509102082607)
[i] Birthday paradox: 100.0 % (25/44=56.82%)
[42] 2895374552463 in [10/34](2871686716893, 2895380619811)
[i] Birthday paradox: 99.4 % (34/120=28.33%)
[41] 1458252205147 in [10/27](1458213802972, 1477170900004)
[i] Birthday paradox: 99.9 % (27/58=46.55%)
[40] 1003651412950 in [33/36](1002096172661, 1003653554571)
[i] Birthday paradox: 84.2 % (36/353=10.2%)
[39] 323724968937 in [4/29](319870188763, 323741708581)
[i] Birthday paradox: 99.9 % (29/71=40.85%)
[38] 146971536592 in [2/5](146565758977, 196041244672)
[i] Birthday paradox: 79.5 % (5/8=62.5%)
[37] 100251560595 in [14/32](100250150111, 100705245985)
[i] Birthday paradox: 97.1 % (32/151=21.19%)
[36] 42387769980 in [4/8](42323323562, 48294483286)
[i] Birthday paradox: 95.4 % (8/12=66.67%)
[35] 20112871792 in [3/19](20104890014, 20697299298)
[i] Birthday paradox: 100.0 % (19/29=65.52%)
[34] 14133072157 in [21/31](14133071070, 14156100386)
[i] Birthday paradox: 72.3 % (31/373=8.31%)
[33] 7137437912 in [20/28](7137264382, 7192328066)
[i] Birthday paradox: 99.6 % (28/78=35.9%)
[32] 3093472814 in [9/27](3065738372, 3093627772)
[i] Birthday paradox: 99.4 % (27/77=35.06%)
[31] 2102388551 in [19/19](2101502954, 2146242198)
[i] Birthday paradox: 100.0 % (19/24=79.17%)
[30] 1033162084 in [7/7](1032110126, 1091762450)
[i] Birthday paradox: 96.2 % (7/9=77.78%)
[29] 400708894 in [11/23](400707999, 404598369)
[i] Birthday paradox: 98.4 % (23/69=33.33%)
[28] 227634408 in [11/13](227503372, 238236468)
[i] Birthday paradox: 99.4 % (13/20=65.0%)
[27] 111949941 in [12/16](107618835, 111963465)
[i] Birthday paradox: 99.9 % (16/23=69.57%)
[26] 54538862 in [14/18](54530168, 55745736)
[i] Birthday paradox: 99.6 % (18/34=52.94%)
[25] 33185509 in [1/1](13981013, 33401515)
[i] Birthday paradox: 0.0 % (1/3=33.33%)
[24] 14428676 in [16/18](14428576, 14559648)
[i] Birthday paradox: 92.9 % (18/64=28.12%)
[23] 5598802 in [5/13](5493855, 5600350)
[i] Birthday paradox: 98.9 % (13/22=59.09%)
[22] 3007503 in [6/11](3004655, 3128017)
[i] Birthday paradox: 98.6 % (11/17=64.71%)
[21] 1811764 in [11/12](1811176, 1858840)
[i] Birthday paradox: 97.6 % (12/22=54.55%)
[20] 863317 in [13/15](856152, 863336)
[i] Birthday paradox: 78.7 % (15/73=20.55%)
[19] 357535 in [4/8](325861, 358628)
[i] Birthday paradox: 99.2 % (8/9=88.89%)
[18] 198669 in [8/12](198657, 202752)
[i] Birthday paradox: 90.6 % (12/32=37.5%)
[17] 95823 in [5/9](95783, 102873)
[i] Birthday paradox: 97.6 % (9/13=69.23%)
[16] 51510 in [5/8](47786, 51542)
[i] Birthday paradox: 95.4 % (8/12=66.67%)
[15] 26867 in [2/3](23553, 27136)
[i] Birthday paradox: 62.5 % (3/4=75.0%)
[14] 10544 in [4/9](10318, 10546)
[i] Birthday paradox: 66.4 % (9/36=25.0%)
[13] 5216 in [4/7](5208, 5534)
[i] Birthday paradox: 86.2 % (7/13=53.85%)
[12] 2683 in [5/9](2683, 2693)
[i] Birthday paradox: 13.3 % (9/255=3.53%)
[11] 1155 in [2/6](1152, 1280)
[i] Birthday paradox: 92.3 % (6/8=75.0%)
[10] 514 in [1/7](510, 514)
[i] Birthday paradox: 8.0 % (7/255=2.75%)
[9] 467 in [5/5](429, 467)
[i] Birthday paradox: 85.0 % (5/7=71.43%)
[8] 224 in [6/6](223, 225)
[i] Birthday paradox: 5.7 % (6/256=2.34%)
[7] 76 in [2/4](76, 92)
[i] Birthday paradox: 90.6 % (4/4=100.0%)
[6] 49 in [3/4](47, 49)
[i] Birthday paradox: 9.1 % (4/64=6.25%)
[5] 21 in [2/3](21, 27)
[i] Birthday paradox: 77.8 % (3/3=100.0%)
[4] 8 in [1/3](7, 9)
[i] Birthday paradox: 18.0 % (3/16=18.75%)
[3] 7 in [2/2](6, 7)
[i] Birthday paradox: 12.5 % (2/8=25.0%)
[2] 3 in [1/1](1, 3)
[i] Birthday paradox: 0.0 % (1/4=25.0%)
- there is an alternation, so that the PofB works odd/even;
- when PofB works - it could be found by performing 10-40% of the entire work of the range;
- every 5-8 prvkeys there is an uncertainty on 2-3 prvkeys (22-23) (26-27) (31-32) (35-56) (38-39) (48-49-50) (56-57)
#55 could be found by performing 5.2% of the entire work of the range, dividing the range 2^55 into 1000 parts, and checking only 52 parts, where at 38 there was a prvkey.
The last time the uncertainty was recently, so you can expect stability 2-4 steps.
Since if #60 had a low probability of paradox, then #61 would have a high.
Calculate the ranges for #61 by performing 30% of the entire work of the range.
Code:
C:\Python37\3\3>C:\Python37\python.exe birthday_gen.py
[i] Load keys: 60
[61][start,finish] (1152921504606846976, 2305843009213693952)
[ranges] Load: 58
==========================
[combine intersect ranges]
[ranges] before: 58
[intersect] [1157425104234217472] x:1153822224532321075 <= y_last:1156524384308743373
[cancel_intersect] (y - y_last)/radius >= 0.5 (0.62)
[intersect] [1513209474796486656] x:1509606595094590259 <= y_last:1513997604731276493
[intersect] [1518010133361721344] x:1514407253659824947 <= y_last:1516812354498383053
[cancel_intersect] (y - y_last)/radius >= 0.5 (0.67)
[intersect] [1572455559347568640] x:1568852679645672243 <= y_last:1569970416447925453
[cancel_intersect] (y - y_last)/radius >= 0.5 (0.84)
[intersect] [1681942086439403520] x:1678339206737507123 <= y_last:1679353914715118797
[cancel_intersect] (y - y_last)/radius >= 0.5 (0.86)
[intersect] [1684559309983318016] x:1680956430281421619 <= y_last:1685544966141299917
[intersect] [1685736043334074368] x:1682133163632177971 <= y_last:1688162189685214413
[intersect] [1731503096698399744] x:1727900216996503347 <= y_last:1732985136612166861
[intersect] [1896908834572599296] x:1893305954870702899 <= y_last:1894199929523195085
[cancel_intersect] (y - y_last)/radius >= 0.5 (0.88)
[intersect] [1898454159913385984] x:1894851280211489587 <= y_last:1900511714274495693
[intersect] [1922904991479645440] x:1919302111777749043 <= y_last:1919544280281304269
[cancel_intersect] (y - y_last)/radius >= 0.5 (0.97)
[intersect] [1923285341536518144] x:1919682461834621747 <= y_last:1926507871181541837
[intersect] [1960618542926561280] x:1957015663224664883 <= y_last:1958967555310537933
[cancel_intersect] (y - y_last)/radius >= 0.5 (0.73)
[intersect] [2019132933022810112] x:2015530053320913715 <= y_last:2021215512763878605
[intersect] [2103181025982021632] x:2099578146280125235 <= y_last:2103884416734960845
[intersect] [2104809567970918400] x:2101206688269022003 <= y_last:2106783905683918029
[intersect] [2108179983517569024] x:2104577103815672627 <= y_last:2108412447672814797
[intersect] [2218698681123602432] x:2215095801421706035 <= y_last:2215535022275440333
[cancel_intersect] (y - y_last)/radius >= 0.5 (0.94)
[intersect] found 18
[ranges] after: 48
==========================
[i] Parts: 160
[i] Birthday paradox: 100.0 % (48/160)
[i] Econom work time: 30.0%
==========================
[ranges] 48
1149318624904950579 1156524384308743373
1156524384308743374 1161027983936113869
1229283727926047539 1236489487329840333
1248012856449684275 1255218615853477069
1273127391593682227 1280333150997475021
1296811512701334323 1304017272105127117
1306885325141324595 1314091084545117389
1346149098036867891 1353354857440660685
1354198052410438451 1361403811814231245
1365491407018734387 1372697166422527181
1411396873663754035 1418602633067546829
1418694665723654963 1425900425127447757
1464570598820885299 1471776358224678093
1480333197516682035 1487538956920474829
1506791845327483699 1516812354498383053
1516812354498383054 1521613013063617741
1525485384562324275 1532691143966117069
1535384095451984691 1542589854855777485
1562764657044132659 1569970416447925453
1569970416447925454 1576058439049465037
1596210464108839987 1603416223512632781
1649789379833705267 1656995139237498061
1657192691197489971 1664398450601282765
1672148155311326003 1679353914715118797
1679353914715118798 1689338923035970765
1717428715244434227 1724634474648227021
1725779377208374067 1735105976400296141
1743908124927144755 1751113884330937549
1761808174227338035 1769013933631130829
1808744126593839923 1815949885997632717
1870338149506560819 1877543908910353613
1886994170119402291 1894199929523195085
1894199929523195086 1902057039615282381
1912338520877511475 1919544280281304269
1919544280281304270 1926888221238414541
1938834627619140403 1946040387022933197
1951761795906745139 1958967555310537933
1958967555310537934 1964221422628457677
1979459249724666675 1986665009128459469
1988452705084060467 1995658464487853261
2014009753360085811 2022735812724706509
2096678657331168051 2111782863219465421
2155242887773662003 2162448647177454797
2208329262871647539 2215535022275440333
2215535022275440334 2222301560825498829
2253819637805560627 2261025397209353421
2266479820737096499 2273685580140889293
2276887933995922227 2284093693399715021
post update
- fix some bad automatic translate
- fix range, fail border
1152921504606846976 1156524384308743373
...snip...
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
I like the idea of including randomness in the process. Because in the end you don't have to search any repeating patterns if consequently followed (0101, 1f1f).
It is possible in theory these patterns appear but very unlikely in practice.
I thought about ignoring ranges completely and just generate random starting offsets for each GPU working point. This would raise the factor of luck by a magnitude but make inclusion of deterministic methods harder.
You can't ignore ranges completely because bitcrack is not designed so. If you start an offset for each GPU working point, things will awfully slow down ...
o great translate.google, come and help me)
According to the author, the puzzle addresses are formed from truncated leading zeros of a hierarchical deterministic wallet. This means that the distribution is close to the ideal random, as far as hmac_sha512 is good, that is, very much.
Stop! Randomness does not mean the absence of patterns. What do you know about game theory?)
Yes, i have.
Ok) let's start
More than a year I have been watching this topic. But no one has described many obvious things.
What random factors affect search?
1) Classic factor 50%: on average we will find prvkey by sorting around 50% of the range.
(example, its stat print vanity-gen, where search vanity address)
2) The classical theory of probability, as the average distribution.
Divide each range into N parts.
We calculate in which part each known prvkey is located.
Parts with less prvkeys have a higher probability of finding a prvkey in the next puzzle.
In the theory of games, when the casino guarantees that all possible options will fall out approximately equal to the number of times.
+50% prob
3) The classical theory of probability, as in time.
Divide each range into N parts.
We calculate in which part each known prvkey is located.
The lowest probability will be in the part in which prvkey was found the previous time.
In game theory, this is known as the "double up game".
+50%prob
The graph is built for Nmax = 50 for convenience (as the well-known prvkey is a little over 50 and a lot less than 100)
Below - the theory of probability as an average distribution, from 0 to 9 points, for N = 50,25,10,5,2.
On the side, the theory of probability, as in time, is indicated in% (it does not matter in principle, it can be expressed in points of 0-9, etc.).
It will be enough just to add a code taking into account these probabilities to the pool in order to start searching from them and find the average faster.
4) The paradox of birthdays as a hash function ripemd160
The most useless case for us, since the simplification to 2 ^ 80 is still too great.
5) The paradox of birthdays, as recurring characters in the password (prvkey).
This is much more interesting.
And this affects 99% of the existing id / password generators / token-csrf and so on.
(Andzhig constantly writes about this, he just doesn't know what it is called, the "collective unconscious" lol)
Take the known prvkeys in base10 and analyze how often repetitions occur in them.
For
[9974455244496708] /5=1/3=1/2=2
means one 5x repeat, one 3x repeat, two 2x repeat
What part of the whole range will be set /5=1/3=1/2=2 repetitions?
Unfortunately, I am not strong in combinatorics to create a universal formula for calculating any large ranges.
But we can empirically analyse a small sample in order to roughly estimate the entire range.
Generate 1000 random prvkey from the range 10 ^ 18 (~ 2 ^ 60)
(prvkey consists of "1234567890" and a length of 18)
Then, to narrow the search range to 39.0%, we could only check prvkeys with 9 any repetitions. (/9=39.0%/)
These 9 any repetitions will form two 2x and one 3x (/2=283.4%/3=165.7%/)
or
Then, to narrow the search range to 33.5%, we could only check prvkeys with 9 any repetitions. (/10=33.5%/)
These 10 any repetitions form two 3x and one 4x (/3=165.7%/4=70.6%/)
It is necessary to remake the program generator (BitCrack / Vanity) from a naive increment to a smart one.
But there is a problem. The increment does not require resources at all, and smart generation will require so many resources that we will spend a lot more on generating the prvkey candidate than on calculating ecdsa pubkey.
Especially, it is expensive for the GPU, where every extra IF () leads to a loss of concurrency of simultaneous calculations.
What to do?
If BitCrack counts 250Mh / s (gtx1070), then for 1 hour, 250,000,000 * 3,600 = 9 * 10^11. Round up to 10^12
0000001000000000000 (=10^12)
1152921000000000000 (~ 2^60)
2305843000000000000 (~ 2^61)
Let's drop 1-12 first and last 19 bits - we can control 6 bits with a minimum step of about 1 hour of operation of 1 video card.
We can generate a new task, excluding ranges without repetitions.
What part of the whole range will be set /2=1 repetitions?
Empirically analyse a small sample in order to roughly estimate the entire range.
Generate 1000 random prvkey from the range 10^6
(prvkey consists of "1234567890" and a length of 6)
Then, to narrow the search range to 45.9%, we could only check prvkeys with 1 repetition. (/1=45.9%/)
This 1 repetition will form one 2x (/2=95.0%/)
It will be enough just to add a code that takes into account these repetitions into the pool in order to start searching from them and find them faster.
+45.9% prob
6) The paradox of birthdays as an average prvkey distribution.
with what probability the limit of characters in this post will be reached?) I will not risk and I will write continuation in the following.
(I'm not sure that due to the status of the user I can do it immediately and quickly, wait)
to be continued
According to the author, the puzzle addresses are formed from truncated leading zeros of a hierarchical deterministic wallet. This means that the distribution is close to the ideal random, as far as hmac_sha512 is good, that is, very much.
There is no magic formula. As the author of the puzzle stated the addresses were selected randomly. Random = no formula, got it? Continue to waste your time looking but you will never find it.
Alas, blockheads constantly try to solve "something" in this, usually by trying to spot a pattern in walls of digits in every possible notation, missing the point that brute-forcing the private keys is only possible option, and there is no other possible approach. Looks like many humans are not only bad in comprehending extremely large numbers, they also fail to understand what word "random" means.
Lol. I remind you once again that the private key does not result from any algorithm. It's located at 2 ^ 59 and only this rule applies here.
why are you trying so hard to find a pattern where there are none?
this is not even "exactly a puzzle", i think you are misled by the choice of words by the starter. all these numbers you are trying to find a pattern for are chosen using a cryptographically secure pseudorandom number generator which has no pattern, if it did then it would have never been "secure" and should be considered broken.
this is not even "exactly a puzzle", i think you are misled by the choice of words by the starter. all these numbers you are trying to find a pattern for are chosen using a cryptographically secure pseudorandom number generator which has no pattern, if it did then it would have never been "secure" and should be considered broken.
Stop! Randomness does not mean the absence of patterns. What do you know about game theory?)
Do you have a formula or anything close? What exactly do your calculations mean? I'll appreciate some explanations!
Yes, i have.
I know it's been said already but to those of you who are posting these giant walls of numbers and analysis you're wasting your time. The only way these wallets will be cracked is by brute force. If you manage to find a flaw in the process used to generate random addresses you'd be much better off focusing on a larger payout. That being said, if you do manage to come up with a solid theory but lack the capacity to test a certain keyspace, post it here. I'll run it for you and even let you sweep the wallet yourself if you prove to be correct. The conjecture is ugly to try to read here and generally irrelevant nonsense.
Ok) let's start
More than a year I have been watching this topic. But no one has described many obvious things.
What random factors affect search?
1) Classic factor 50%: on average we will find prvkey by sorting around 50% of the range.
(example, its stat print vanity-gen, where search vanity address)
2) The classical theory of probability, as the average distribution.
Divide each range into N parts.
We calculate in which part each known prvkey is located.
Parts with less prvkeys have a higher probability of finding a prvkey in the next puzzle.
In the theory of games, when the casino guarantees that all possible options will fall out approximately equal to the number of times.
+50% prob
3) The classical theory of probability, as in time.
Divide each range into N parts.
We calculate in which part each known prvkey is located.
The lowest probability will be in the part in which prvkey was found the previous time.
In game theory, this is known as the "double up game".
+50%prob
Code:
C:\php-5.6.32>php _puzzle2prob.php
[002]{.........................$........................} 2.0%
[003]{.....................................$............} 4.0%
[004]{$.................................................} 5.9%
[005]{...............$..................................} 7.8%
[006]{..........................$.......................} 9.6%
[007]{.........$........................................}11.4%
[008]{.....................................$............} 9.6%
[009]{.........................................$........}14.9%
[010]{$.................................................}11.4%
[011]{......$...........................................}18.3%
[012]{...............$..................................}13.2%
[013]{.............$....................................}21.5%
[014]{..............$...................................}23.1%
[015]{...............................$..................}24.6%
[016]{............................$.....................}26.1%
[017]{.......................$..........................}27.6%
[018]{.........................$........................}27.6%
[019]{..................$...............................}30.5%
[020]{................................$.................}31.9%
[021]{....................................$.............}33.2%
[022]{.....................$............................}34.6%
[023]{................$.................................}35.9%
[024]{....................................$.............} 5.9%
[025]{................................................$.}38.4%
[026]{...............................$..................}19.9%
[027]{.................................$................}40.9%
[028]{..................................$...............}42.1%
[029]{........................$.........................}43.2%
[030]{..............................................$...}44.4%
[031]{...............................................$..}45.5%
[032]{......................$...........................}46.6%
[033]{.................................$................}11.4%
[034]{................................$.................}24.6%
[035]{........$.........................................}49.7%
[036]{...........$......................................}50.7%
[037]{......................$...........................} 9.6%
[038]{...$..............................................}52.7%
[039]{........$.........................................} 7.8%
[040]{.........................................$........}46.6%
[041]{................$.................................}30.5%
[042]{...............$..................................}45.5%
[043]{..................................$...............}26.1%
[044]{.....................................$............}51.7%
[045]{......$...........................................}49.7%
[046]{.......................$..........................}44.4%
[047]{...................................$..............}60.6%
[048]{.................$................................}61.3%
[049]{......................$...........................}21.5%
[050]{....$.............................................}62.9%
[051]{.........................................$........}19.9%
[052]{...........................................$......}64.3%
[053]{.........................$........................}50.7%
[054]{.....$............................................}65.8%
[055]{.................................$................}35.9%
[056]{...........$......................................}33.2%
[057]{.............................................$....}67.8%
[058]{...................$..............................}68.4%
[059]{.........................................$........}14.9%
[060]{................................................$.}50.7%
[___]{__________________________________________________}
[N50]{67742137477176633261752351776775413253777072715507}
[N25]{|5|3|2|5|7|4|6|3|4|4|4|4|4|7|7|5|2|4|5|7|4|4|3|2|9}
[N10]{|4 |5 |5 |4 |3 |7 |3 |6 |3 |5 }
[N 5]{|4 |4 |5 |5 |4 }
[N 2]{|4 |5 }
The graph is built for Nmax = 50 for convenience (as the well-known prvkey is a little over 50 and a lot less than 100)
Below - the theory of probability as an average distribution, from 0 to 9 points, for N = 50,25,10,5,2.
On the side, the theory of probability, as in time, is indicated in% (it does not matter in principle, it can be expressed in points of 0-9, etc.).
It will be enough just to add a code taking into account these probabilities to the pool in order to start searching from them and find the average faster.
4) The paradox of birthdays as a hash function ripemd160
The most useless case for us, since the simplification to 2 ^ 80 is still too great.
5) The paradox of birthdays, as recurring characters in the password (prvkey).
This is much more interesting.
And this affects 99% of the existing id / password generators / token-csrf and so on.
(Andzhig constantly writes about this, he just doesn't know what it is called, the "collective unconscious" lol)
Take the known prvkeys in base10 and analyze how often repetitions occur in them.
Code:
C:\php-5.6.32>php _puzzle2birthdayparadox.php
[ Puzzle Analyzer ]
[~] Analyse...
[+] success
[i] Origin keys:
[3]
[7]
[8]
[21]
[49]
[76]
[224] /2=1
[467]
[514]
[1155] /2=2
[2683]
[5216]
[10544] /2=1
[26867] /2=1
[51510] /2=2
[95823]
[198669] /2=2
[357535] /3=1/2=1
[863317] /2=1
[1811764] /3=1
[3007503] /3=1/2=1
[5598802] /2=2
[14428676] /2=2
[33185509] /2=2
[54538862] /2=2
[111949941] /4=1/3=1/2=1
[227634408] /2=2
[400708894] /3=1/2=2
[1033162084] /2=3
[2102388551] /2=4
[3093472814] /2=2
[7137437912] /3=1/2=2
[14133072157] /3=1/2=2
[20112871792] /3=2/2=1
[42387769980] /2=3
[100251560595] /4=1/3=1/2=1
[146971536592] /2=4
[323724968937] /3=1/2=3
[1003651412950] /3=2/2=1
[1458252205147] /3=2/2=2
[2895374552463] /3=1/2=3
[7409811047825] /2=5
[15404761757071] /4=1/3=1/2=3
[19996463086597] /4=1/3=1
[51408670348612] /2=5
[119666659114170] /5=1/4=1/2=1
[191206974700443] /3=2/2=3
[409118905032525] /3=2/2=3
[611140496167764] /4=2/3=1/2=1
[2058769515153876] /4=1/2=4
[4216495639600700] /4=1/3=1/2=2
[6763683971478124] /3=2/2=4
[9974455244496708] /5=1/3=1/2=2
[30045390491869460] /4=1/3=2/2=2
[44218742292676576] /4=1/3=3
[138245758910846506] /3=2/2=4
[199976667976342048] /4=2/3=1/2=1
[525070384258266266] /4=2/3=1/2=2
[1135041350219496420] /4=1/3=2/2=4
[x] EXIT.
For
[9974455244496708] /5=1/3=1/2=2
means one 5x repeat, one 3x repeat, two 2x repeat
What part of the whole range will be set /5=1/3=1/2=2 repetitions?
Unfortunately, I am not strong in combinatorics to create a universal formula for calculating any large ranges.
But we can empirically analyse a small sample in order to roughly estimate the entire range.
Generate 1000 random prvkey from the range 10 ^ 18 (~ 2 ^ 60)
(prvkey consists of "1234567890" and a length of 18)
Code:
C:\php-5.6.32>php _puzzle2birthdayparadox.php
(str = "1234567890" and length = 18)
[range^order] 10^18 = ~2^60
[range] 10
[order] 18
[~] Generate Passwords...
[pairs/pcs] pairs=9482; avg=9.5; /0=0.0%/1=0.0%/2=0.0%/3=0.0%/4=0.0%/5=0.0%/6=0.0%/7=0.0%/8=14.2%/9=39.0%/10=33.5%/11=11.2%/12=1.9%/13=0.2%/../13;
- 9482 repetitions found in 1000 random prvkeys
- prvkey c less than 7 or more than 13 by any repetitions - rare or absent
- in 39.0% prvkeys 9 any repetitions were found, in 35% there are 10 any repetitions, ..
[pairN/pairs] pairs=9482; /2=29.9%/3=35.0%/4=22.3%/5=9.9%/6=2.5%/7=0.4%/../7;
- 9482 make up 29.9% 2x repeats, 35% 3x, 22% 4x, ..
[pairN/pcs] pcs=1000; /2=283.4%/3=165.7%/4=70.6%/5=23.5%/6=4.8%/7=0.6%/../7;
- in each prvkey found 2-3 2x repeat, 1-2 3x, 0-1 4x, ..
- in 235 prvkey 5x repetition found, in 48 prvkey 6x repetition found, ..
Then, to narrow the search range to 39.0%, we could only check prvkeys with 9 any repetitions. (/9=39.0%/)
These 9 any repetitions will form two 2x and one 3x (/2=283.4%/3=165.7%/)
or
Then, to narrow the search range to 33.5%, we could only check prvkeys with 9 any repetitions. (/10=33.5%/)
These 10 any repetitions form two 3x and one 4x (/3=165.7%/4=70.6%/)
It is necessary to remake the program generator (BitCrack / Vanity) from a naive increment to a smart one.
But there is a problem. The increment does not require resources at all, and smart generation will require so many resources that we will spend a lot more on generating the prvkey candidate than on calculating ecdsa pubkey.
Especially, it is expensive for the GPU, where every extra IF () leads to a loss of concurrency of simultaneous calculations.
What to do?
If BitCrack counts 250Mh / s (gtx1070), then for 1 hour, 250,000,000 * 3,600 = 9 * 10^11. Round up to 10^12
0000001000000000000 (=10^12)
1152921000000000000 (~ 2^60)
2305843000000000000 (~ 2^61)
Let's drop 1-12 first and last 19 bits - we can control 6 bits with a minimum step of about 1 hour of operation of 1 video card.
We can generate a new task, excluding ranges without repetitions.
What part of the whole range will be set /2=1 repetitions?
Empirically analyse a small sample in order to roughly estimate the entire range.
Generate 1000 random prvkey from the range 10^6
(prvkey consists of "1234567890" and a length of 6)
Code:
C:\php-5.6.32>php _puzzle2birthdayparadox.php
(str = "1234567890" and length = 6)
[range^order] 10^6 = ~2^20
[range] 10
[order] 6
[~] Generate Passwords...
[pairs/pcs] pairs=1283; avg=1.3; /0=16.1%/1=45.9%/2=31.7%/3=6.2%/4=0.1%/../4;
[pairN/pairs] pairs=1283; /2=74.0%/3=23.5%/4=2.1%/5=0.3%/../5;
[pairN/pcs] pcs=1000; /2=95.0%/3=15.1%/4=0.9%/5=0.1%/../5;
Then, to narrow the search range to 45.9%, we could only check prvkeys with 1 repetition. (/1=45.9%/)
This 1 repetition will form one 2x (/2=95.0%/)
It will be enough just to add a code that takes into account these repetitions into the pool in order to start searching from them and find them faster.
+45.9% prob
6) The paradox of birthdays as an average prvkey distribution.
with what probability the limit of characters in this post will be reached?) I will not risk and I will write continuation in the following.
(I'm not sure that due to the status of the user I can do it immediately and quickly, wait)
to be continued
...snip...
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
I like the idea of including randomness in the process. Because in the end you don't have to search any repeating patterns if consequently followed (0101, 1f1f).
It is possible in theory these patterns appear but very unlikely in practice.
I thought about ignoring ranges completely and just generate random starting offsets for each GPU working point. This would raise the factor of luck by a magnitude but make inclusion of deterministic methods harder.
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;)
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
Cool!! nice tip!!!
I'll try
Jump to: