Bitcoin puzzle transaction ~32 BTC prize to who solves it

[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

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.

[pbies]

For old wallets (2009-2017) there is not much to do beside having "performance counter data" which can lead to guessing private keys.

If you have this old perfdata you can generate old private keys and take the balance.

Seems like the only way to steal funds from these old addresses.

[FlleOWA]

For old wallets (2009-2017) there is not much to do beside having "performance counter data" which can lead to guessing private keys.

If you have this old perfdata you can generate old private keys and take the balance.

Seems like the only way to steal funds from these old addresses.

I considered this possibility, studied the source code of the original application, looked for generator errors.
At that time I didn't have strong knowledge in coding. That's why I didn't understand and didn't know what data the generator takes as a basis, I tried to generate billions using time but it didn't help.
But I got tired of it, but apparently it is worth delving into it.

[kTimesG]

For old wallets (2009-2017) there is not much to do beside having "performance counter data" which can lead to guessing private keys.

If you have this old perfdata you can generate old private keys and take the balance.

Seems like the only way to steal funds from these old addresses.

My best guess is that Satoshi wanted a pizza last September, and was out of cash.

Lucky delivery guy.

Now, where's the OG satoshi mining app used in Jan 2009?

[CriptoGiga]

For old wallets (2009-2017) there is not much to do beside having "performance counter data" which can lead to guessing private keys.

If you have this old perfdata you can generate old private keys and take the balance.

Seems like the only way to steal funds from these old addresses.

My best guess is that Satoshi wanted a pizza last September, and was out of cash.

Lucky delivery guy.

Now, where's the OG satoshi mining app used in Jan 2009?

https://satoshi.nakamotoinstitute.org/code/

[crytoestudo]

BitcoinMiner started
RefreshListCtrl starting
RefreshListCtrl done
IRC :*.freenode.net NOTICE * :*** Looking up your ident...
IRC :*.freenode.net NOTICE * :*** Looking up your hostname...
IRC :*.freenode.net NOTICE * :*** Found your hostname (191-222-253-40.user3p.v-tal.net.br)
SENDING: NICK uBnDnodZugfSEou
SENDING: USER uBnDnodZugfSEou 8 * : uBnDnodZugfSEou

For old wallets (2009-2017) there is not much to do beside having "performance counter data" which can lead to guessing private keys.

If you have this old perfdata you can generate old private keys and take the balance.

Seems like the only way to steal funds from these old addresses.

My best guess is that Satoshi wanted a pizza last September, and was out of cash.

Lucky delivery guy.

Now, where's the OG satoshi mining app used in Jan 2009?

https://satoshi.nakamotoinstitute.org/code/

[nomachine]

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.

Yep. But now, let’s say you’ve got a bot with a pre-calculated DP. Puzzle 71 can be solved in, like, 2 seconds on a CPU as soon as the public key pops up. It’s a huge problem if folks ain’t using MARA slipstream, if you ask me.