Bitcoin puzzle transaction ~32 BTC prize to who solves it

[kTimesG]

keep in mind, there is a difference in base58 prefixes and h160 bits. It feels like you are mixing the two up/together.

I'm not mixing anything. These are all (and only) the possible H160 values that convert back to a "1PWo3JeB9jrGw" address prefix.

Code:

Unfilled base58 digits: 21
Adjusting min H160 up from "1PWo3JeB9jrGvzzzzzzzzzzzzzzzza76BM"
min NB+H160+CS: 00f6f5431d25bbf7b129329c4be9ce9c7064f457fc76e8cd54 len: 25 minAddr: 1PWo3JeB9jrGw1111111111111117sfssh
Address right before the computed minimum: 1PWo3JeB9jrGvzzzzzzzzzzzzzzzza76BM
max NB+H160+CS: 00f6f5431d25bbf7b1314bbfcb22658f6370ac8ac91e478669 len: 25 maxAddr: 1PWo3JeB9jrGwzzzzzzzzzzzzzzzwVNymA
Address right after the computed maximum: 1PWo3JeB9jrGx11111111111111163WUG8
H160 target prefix len: 67 bits
Total possible H160: 2506270853702237716179595982 = 91.01760089767902 bits
Expected average in subset: 2.02
99% confidence interval: [0, 6] successes

And matching the first 67 bits in the RIPEMD hash yields

Code:

Total possible H160: 9903520314283042199192993792 = 93.0 bits
Expected average in subset: 8.00
99% confidence interval: [2, 16] successes

Hence, matching H160 prefixes will provide many results which don't result in the 1+12 b58 prefix. Simply because most of those fall below and above the min/max BOUNDED H160s that convert to the desired base58 1+12 prefix.

[MrGPBit]

keep in mind, there is a difference in base58 prefixes and h160 bits. It feels like you are mixing the two up/together.

I'm not mixing anything. These are all (and only) the possible H160 values that convert back to a "1PWo3JeB9jrGw" address prefix.

Code:

Unfilled base58 digits: 21
Adjusting min H160 up from "1PWo3JeB9jrGvzzzzzzzzzzzzzzzza76BM"
min NB+H160+CS: 00f6f5431d25bbf7b129329c4be9ce9c7064f457fc76e8cd54 len: 25 minAddr: 1PWo3JeB9jrGw1111111111111117sfssh
Address right before the computed minimum: 1PWo3JeB9jrGvzzzzzzzzzzzzzzzza76BM
max NB+H160+CS: 00f6f5431d25bbf7b1314bbfcb22658f6370ac8ac91e478669 len: 25 maxAddr: 1PWo3JeB9jrGwzzzzzzzzzzzzzzzwVNymA
Address right after the computed maximum: 1PWo3JeB9jrGx11111111111111163WUG8
H160 target prefix len: 67 bits
Total possible H160: 2506270853702237716179595982 = 91.01760089767902 bits
Expected average in subset: 2.02
99% confidence interval: [0, 6] successes

And matching the first 67 bits in the RIPEMD hash yields

Code:

Total possible H160: 9903520314283042199192993792 = 93.0 bits
Expected average in subset: 8.00
99% confidence interval: [2, 16] successes

Hence, matching H160 prefixes will provide many results which don't result in the 1+12 b58 prefix. Simply because most of those fall below and above the min/max BOUNDED H160s that convert to the desired base58 1+12 prefix.

I think it’s your original wording.

Also, without a script and just reading your results, is it saying for an h160 of a minimum of 67 bits, there will be only 2^91?

In 2^70 hash trials, there is a 100% confidence of between 0 and 2^71 h160s having that base58 property?

[kTimesG]

Also, without a script and just reading your results, is it saying for an h160 of a minimum of 67 bits, there will be only 2^91?

What I'm saying is that when filtering for a match, the first thing that happens is filtering the H160 bits.

However, depending on the specific base58 prefix, that filter will return false positives, in a less or greater amount.

Explicitly for the "1PWo3JeB9jrGw" prefix (this calculation and the results will differ for every possible prefix):

- I gave the minimum possible H160 value that converts to a valid address having this b58 prefix
- I gave the maximum H160 value as well

The script is too complex, so it's irrelevant. What matters is that these are the min/max bounds for any H160 value that will correctly encode into a correct and valid desired base58 address.

So, once we have this (max - min + 1) total unique H160 values, than when we hash ANY value, and it falls into this interval, then it's a 100% base58 match.

Since H160 is 160 bits, then the probability to ever have a match becomes:

(max - min + 1) / 2**160

for every time we do a hash.

HOWEVER, people will most likely want to fast-filter the H160 itself, right?

So, counting the common front bits between the minH160 and maxH160, we have 67 matching bits.

This means:

- if a H160 has those 67 bits matched, then it MIGHT also lie between the min and max

but... that is not a guarantee. There will ALWAYS be more H160 matches than the number of actual base58 matches, and this is why:

- the minH160 has 67 common bits, followed by a 0 bit, and then 92 ANY other bits
- the maxH160 has 67 common bits, followed by a 1, and then some ANY other bits

Extreme example to understand the problem:

minH = <67 bits> 0 <1111111....1>
maxH = <67 bits> 1 <0000........0>

So, in this case we have only 2 valid H160 values that yield some prefix.

However, there are 2**93 H160 actual hashes that match the first 67 bits.

Ratio between H160 matches and base58 matches: 1 / 2**92.

Hope that clears it. Of course the example isn't practical, but the ratio can go up to 3 or 4 depending on how the base58 prefix's min/max H160 end up looking.

In 2^70 hash trials, there is a 100% confidence of between 0 and 2^71 h160s having that base58 property?

Sorry, I meant between 0 and 2**70. Typo. Yes, 100% confidence, since it may be observed not at all, or every single time, due to the uniform distribution.

[Akito S. M. Hosana]

There's no way this can be solved this way.  .. go away now. 

Here is the whole code

https://github.com/AkitoHosana/mnemonic-puzzle-solver

[MrGPBit]

There's no way this can be solved this way.  .. go away now. 

Here is the whole code

https://github.com/AkitoHosana/mnemonic-puzzle-solver

Unfortunately this link does not exist you made a mistake

[Akito S. M. Hosana]

There's no way this can be solved this way.  .. go away now. 

Here is the whole code

https://github.com/AkitoHosana/mnemonic-puzzle-solver

Unfortunately this link does not exist you made a mistake

Try again. 

[nomachine]

Taк кaк вce пaзлы этo aдpecca oднoгo дeтepминиpoвaннoгo кoшeлькa,o чeм гoвopил coздaтeль ,тo в cлyчae иcпoльзoвaния cид фpaзы нyжeн пyть coздaния кaждoгo aдpecca пaзлa.Кaкoй пyть вы иcпoльзyeтe для 71 пaзлa ?

Instead of starting from a known seed, script randomly guesses valid 24-word BIP39 mnemonics.

The first 16 words are hardcoded ("abandon" repeated), while the last 8 are picked from custom wordlists (17.txt to 24.txt).

This script skips the seed phrase and directly generates valid entropy combinations (via mnemonics) to derive private keys.

But despite everything, it’s terribly slow. For example, it only processes 500 per second here on my 16-core system.

P.S.
I understand Ukrainian, Russian, and Udmurt, but just speak English here, cool?

[FrozenThroneGuy]

Hello guys!
My implementation of Pollard-rho algo:
https://github.com/Dookoo2/Mark1
38 minutes for solving 80 bits puzzle with half billion of DP, 14 minutes for solving 70 bits with 200 millions of dp.
AVX2 bloom filter, compact DP table, Brent loop detection and others features.
May be useful for somebody.
Have a nice day:)

[kTimesG]

Hello guys!
My implementation of Pollard-rho algo:
https://github.com/Dookoo2/Mark1
38 minutes for solving 80 bits puzzle with half billion of DP, 14 minutes for solving 70 bits with 200 millions of dp.
AVX2 bloom filter, compact DP table, Brent loop detection and others features.
May be useful for somebody.
Have a nice day:)

Thanks for the code

I don't want to sound mean or anything, but let's do a quick and simple math exercise:

Device | TDP | Speed | Keys/Watt
Ryzen 9 7945HX | 55W | 160 M/s | 2.9 M/W
RTX 4090 | 450W |. 10800 M/s | 24 M/W

So it's more than eight times more costly to solve any puzzle on that CPU.

Moreover, RC claimed he got up to 13.8 GK/s on a RTX 4090, which, if true, would mean it's ten times cheaper, than running a Ryzen 9 7945HX at 100% peak power.

I would also say that solving 80 bits, with some proper Tame precomputed database (with way less than half a billion DPs) takes much less than 20 seconds, even on a budget GPU. There is a precise balance where having too many DPs (of lower bits) is not beneficial, and having fewer DPs (of higher bits) is better overall.

[FrozenThroneGuy]

Hello guys!
My implementation of Pollard-rho algo:
https://github.com/Dookoo2/Mark1
38 minutes for solving 80 bits puzzle with half billion of DP, 14 minutes for solving 70 bits with 200 millions of dp.
AVX2 bloom filter, compact DP table, Brent loop detection and others features.
May be useful for somebody.
Have a nice day:)

Thanks for the code

I don't want to sound mean or anything, but let's do a quick and simple math exercise:

Device | TDP | Speed | Keys/Watt
Ryzen 9 7945HX | 55W | 160 M/s | 2.9 M/W
RTX 4090 | 450W |. 10800 M/s | 24 M/W

So it's more than eight times more costly to solve any puzzle on that CPU.

Moreover, RC claimed he got up to 13.8 GK/s on a RTX 4090, which, if true, would mean it's ten times cheaper, than running a Ryzen 9 7945HX at 100% peak power.

I would also say that solving 80 bits, with some proper Tame precomputed database (with way less than half a billion DPs) takes much less than 20 seconds, even on a budget GPU. There is a precise balance where having too many DPs (of lower bits) is not beneficial, and having fewer DPs (of higher bits) is better overall.

Of course, but:
1. I do not participate in the puzzle race:) For fun, not more.
2. Optimal amount of DP (for 135 and higher) is much more than we can collect and save in RAM.
3. You can start Mark1 with different DP bits, amount of DP, different jump size (k parameter) and others.
4. And I have gpu code too, but it is boring.

And by the way, 135 and higher are like a lottery ticket.

[kTimesG]

Of course, but:
1. I do not participate in the puzzle race:) For fun, not more.
2. Optimal amount of DP (for 135 and higher) is much more than we can collect and save in RAM.
3. You can start Mark1 with different DP bits, amount of DP, different jump size (k parameter) and others.
4. And I have gpu code too, but it is boring.

And by the way, 135 and higher are like a lottery ticket.

Yeah, having FTL GPU jumper's boring.

There's absolutely no need to store DPs in RAM, let alone a bloom filter. That requirement is needed by BSGS's "fast memory lookup", but for DPs this is an "offline" step, and it's conceptually either an "insert this DP" (because we want to store a DP, of course) or "the DP could not be inserted" (collision, yay) op-code. So, basically, a storage database. A bloom filter is useless, and fast lookup is also useless, for this scenario. Kangaroo requires zero memory (except for the current point), in its essence.

[heseke]

It was literally designed to be even more solvable by reducing the range and exposing pub keys.

Give me the public key for puzzle 71

No. But I'll give you a dramatically reduced range. Somewhere in there: 400000000000000000:7fffffffffffffffff

Stop complaining about everything and try to find it with us.

I did a deep analysis the key lies between START = 1298650782789152433766
STOP = 19999999999999999999999

[crytoestudo]

a colleague got good speed with the 5090
https://media.discordapp.net/attachments/1379824747117940887/1385264671270899774/Captura_de_tela_2025-06-19_112456.png?ex=68556fc2&is=68541e42&hm=5912b561312925724e091f60a2247277ba4eec0a768e17c2805e32e5e976f04a&=&format=webp&quality=lossless&width=1474&height=423

It was literally designed to be even more solvable by reducing the range and exposing pub keys.

Give me the public key for puzzle 71

No. But I'll give you a dramatically reduced range. Somewhere in there: 400000000000000000:7fffffffffffffffff

Stop complaining about everything and try to find it with us.

I did a deep analysis the key lies between START = 1298650782789152433766
STOP = 19999999999999999999999

[E36cat]

if he had 2305 Pkeys/s would have solve 71 in less than a day

a colleague got good speed with the 5090
https://media.discordapp.net/attachments/1379824747117940887/1385264671270899774/Captura_de_tela_2025-06-19_112456.png?ex=68556fc2&is=68541e42&hm=5912b561312925724e091f60a2247277ba4eec0a768e17c2805e32e5e976f04a&=&format=webp&quality=lossless&width=1474&height=423

It was literally designed to be even more solvable by reducing the range and exposing pub keys.

Give me the public key for puzzle 71

No. But I'll give you a dramatically reduced range. Somewhere in there: 400000000000000000:7fffffffffffffffff

Stop complaining about everything and try to find it with us.

I did a deep analysis the key lies between START = 1298650782789152433766
STOP = 19999999999999999999999

[FlleOWA]

While everyone is trying to brute force this puzzle. Some people have already hacked Bitcoin itself, or rather secp, otherwise some transactions cannot be explained. Of course, the one who hacks the system itself will not say anything about it, otherwise his life will be in danger, a lot of money is kept by influential people and also the black market.
One thing is certain, old addresses from 2009-2010 have been active for some time now. And transfers to exchanges and other addresses are made from them. It is logical that if you have found a vulnerability, it is better to use old wallets, because in this case, few will be able to confirm the legitimacy of these coins, because they have long lost the keys.

[kTimesG]

While everyone is trying to brute force this puzzle. Some people have already hacked Bitcoin itself, or rather secp, otherwise some transactions cannot be explained. Of course, the one who hacks the system itself will not say anything about it, otherwise his life will be in danger, a lot of money is kept by influential people and also the black market.
One thing is certain, old addresses from 2009-2010 have been active for some time now. And transfers to exchanges and other addresses are made from them. It is logical that if you have found a vulnerability, it is better to use old wallets, because in this case, few will be able to confirm the legitimacy of these coins, because they have long lost the keys.

Link / examples? Did they have the public key exposed?

It's always possible (and even happened) that old software had bugs like bad RNG, making exploits viable more or less. More probable than secp being broken in secret (though not excluded).

[Frequence]

a colleague got good speed with the 5090
https://media.discordapp.net/attachments/1379824747117940887/1385264671270899774/Captura_de_tela_2025-06-19_112456.png?ex=68556fc2&is=68541e42&hm=5912b561312925724e091f60a2247277ba4eec0a768e17c2805e32e5e976f04a&=&format=webp&quality=lossless&width=1474&height=423

Impossible

[crytoestudo]

it's bug

a colleague got good speed with the 5090
https://media.discordapp.net/attachments/1379824747117940887/1385264671270899774/Captura_de_tela_2025-06-19_112456.png?ex=68556fc2&is=68541e42&hm=5912b561312925724e091f60a2247277ba4eec0a768e17c2805e32e5e976f04a&=&format=webp&quality=lossless&width=1474&height=423

Impossible

[Frequence]

While everyone is trying to brute force this puzzle. Some people have already hacked Bitcoin itself, or rather secp, otherwise some transactions cannot be explained. Of course, the one who hacks the system itself will not say anything about it, otherwise his life will be in danger, a lot of money is kept by influential people and also the black market.
One thing is certain, old addresses from 2009-2010 have been active for some time now. And transfers to exchanges and other addresses are made from them. It is logical that if you have found a vulnerability, it is better to use old wallets, because in this case, few will be able to confirm the legitimacy of these coins, because they have long lost the keys.

Okay, can you give an example?!

[FlleOWA]

Okay, can you give an example?!

You can see these addresses from 2011, which were translated 13 years later.

1L8SXqb31Ry2dKPRaY19xddo9fcsvCKVYN
1EySSGtSVitbMZSQmhNobvTEPdmGSwpsjA

And these are wallets from the very beginning of 2009, when they were still giving 50 bitcoins for a block.

1CGT3Ywaa2upJfWtUtbXonDPNTfZPWqzmA
1MBBJBFEaYKHFZAeV7hQ7DWdu3aZktjzFH
13J8FkimCLQ2EnP1xRm7yHhpaZQa9H4p8E
18E5d2wQdAfutcXgziHZR71izLRyjSzGSX
1C4rE41Kox3jZbdJT9yatyh4H2fMxP8qmD

I doubt that a person found his software after 15 years. It is impossible. And considering that these are the initial blocks and possibly the addresses of Satoshi himself, but not for sure. But it is a huge blunder to transfer funds from these addresses.
I myself mined in 2009, at the very beginning through the satoshi application. But at that time I was just playing around, and the reward for each block was on a new address, save a private key or see at that time there was no such function in the application. Or maybe I didn't know, only wallet.dat was for saving your funds.
At that time I had 2 servers at home, I kept my websites on one, and launched pirated game servers on the other. And a friend told me about bitcoin, I don’t remember how much I mined, the software worked for a month, probably 1000btc and that was it. I just deleted the application later, I didn’t know what to do with these coins.

You can search more precisely and find even more addresses.

It's always possible (and even happened) that old software had bugs like bad RNG, making exploits viable more or less. More probable than secp being broken in secret (though not excluded).

I doubt it. From those addresses that transferred 50 btc, all this stuff won't work. Only if there is a vulnerability in that original application. There were no others at that time.