Bitcoin puzzle transaction ~32 BTC prize to who solves it

[crypto_user_new]

If a user is asking for a simple information, why you give more that he asked? At least if you give the private key, give also the address...he needs now to scan again and again wasting power and money....sometimes is a joke for everyone...

There is only 2 addresses with form 1PWo3JeB9jrG for puzzle 71. If the first one is on 4, the second one should be on 60-68.

[simonmales]

I built a browser WebGPU brute-forcer for Puzzle 71. Free, no backend, and here is exactly where the money goes.

The money part first, since this thread has seen plenty of tools that bury it: if the app ever finds the key, the signed tx pays 6 BTC to an address you enter and the remainder to me, the developer. That split sits on the page before the Start button does anything, and I'm stating it here too so nobody has to dig for it later.

The found key itself stays in your browser. Signing happens locally with @scure/btc-signer, and since there's no backend, nothing gets uploaded anywhere. You don't make an account and there's no pool to join.

The app is krackpot.io. It does secp256k1, SHA-256 and RIPEMD-160 in WGSL compute shaders and searches Puzzle 71's range right in the browser. The search path has zero dependencies, and the whole site is a static PWA that keeps working offline.

I'm not claiming this beats the math. The pitch is only that it's the easiest way for a normal person to point a GPU at the puzzle, and you should see the numbers before you bother:

• The keyspace is 2^70, about 1.18e21 keys.
• Measured rates from the live app, not estimates: RTX 4070 ~44 MK/s, M3 Max ~26 MK/s, RTX 3070 ~21 MK/s, MacBook Air M1 ~5.8 MK/s.
• A single fast GPU needs roughly 400k to 900k years, median, to sweep the range. A million GPUs gets that down to about a year. It's a lottery.

I'm posting here before anywhere else because this is where my claims are most likely to get broken. If the WGSL math is off by a single bit the whole search is wasted electricity, so a deterministic test suite (known privkey -> address vectors, including the incremental +G hot path) has to pass before any search runs. If you spot a flaw in the crypto, the endianness handling, or the claim tx, I want to hear about it.

The one attack I'll be upfront about: claim-time front-running. The moment a winning tx hits the public mempool it exposes the public key, and since everyone knows the key sits in Puzzle 71's range, Kangaroo cracks it from there in seconds. So a bot watching the mempool can derive the same key and rebroadcast a higher-fee tx that takes the coins before mine confirms. Krackpot broadcasts through the public mempool (mempool.space, then blockstream/blockchain.info) at 69 sat/vB, so it doesn't defend against this, and I'm not going to pretend it does. For a free tool where the realistic odds of a hit are zero, I traded that risk for a claim path that just works with no accounts or services. Anyone who actually found the key would be better off skipping the auto-broadcast and submitting the signed tx privately (Slipstream, Rebar, or straight to a miner). The tool always shows the recovered key and the full signed hex first, so that manual route stays open.

Where it actually runs, so nobody burns time on a dead platform: desktop macOS and Windows are solid, and that's where it's fastest. On Linux I've only confirmed AMD, and only with Chromium's Vulkan flags enabled (the app tells you which ones). Intel on Linux hasn't worked for me, and I haven't tested NVIDIA on Linux at all. Android is a write-off for now, since even a small dispatch trips the OS GPU watchdog. iPhone works. If you get it going on Intel or NVIDIA under Linux, tell me the GPU and browser and I'll add it.

The technical write-up (the WGSL math, the +G hot path, watchdog calibration) is at krackpot.io/blog/how-it-works.

One warning: krackpot.io is the only domain this lives on. Krackpot on any other URL is a clone, probably with the payout address swapped. Check before you run anything.

Built by Simon Males (sime.net.au). Tear it apart.

[mumsidea]

The first stage of the methodology is deliberately simple.

For each puzzle, identify the nearest relevant Fibonacci anchor, then retain only the interval spanning approximately 0.8 × F to 1.3 × F.
No prediction is made regarding the precise location of the private key.
No relationship between different puzzles is assumed.
The Fibonacci anchor merely defines the initial candidate region from which the search begins.
As part of this research, I generated every possible private key for Puzzles 1 through 45 and exhaustively analysed their corresponding address prefixes and hash prefixes.
The conclusion was unambiguous.
Neither address prefixes nor hash prefixes provide any statistically meaningful predictive information. Any apparent success achieved through prefix filtering is simply the consequence of random chance rather than scientific inference.
When the solved puzzles are examined within the Fibonacci-anchor framework described above, every solved private key falls inside its corresponding 0.8–1.3 anchor interval.
At first glance, a few apparent exceptions may seem to exist. However, once the construction rule is correctly understood and applied consistently across the currently solved 82 puzzles, those apparent inconsistencies disappear.
Naturally, a sample of 82 observations cannot constitute a formal mathematical proof for a population of 160 puzzles.
Nevertheless, complete agreement across all currently solved puzzles provides compelling empirical evidence that the observed behaviour reflects a genuine structural property rather than coincidence.
The practical implication is straightforward.
Large inactive regions surrounding each puzzle can be discarded before any computationally intensive search begins. The search space becomes substantially smaller without introducing any assumption regarding the actual position of the unknown private key.
For Puzzle 71, for example, the first structural reduction decreases the candidate domain from
1,180,591,620,717,411,303,424
to
750,260,268,103,448,041,640
candidate keys.
Conceptually, the first stage may be summarised as follows:
Search interval: 0x4000000000000 – 0x7ffffffffffff
Midpoint: 0x6000000000000
Reference Fibonacci anchor: F(75) = 2,111,485,077,978,050
Candidate interval: approximately 0.8F to 1.3F
Low anchor: 0x6004ebe6ac968
High anchor: 0x7ffffffffffff
This represents only the first structural filter.
Our current research consists of a sequence of independent filters arranged as a funnel. Each successive stage preserves the previous reduction while eliminating additional regions that appear to be structurally irrelevant. Ultimately, as many as nine successive filtering stages may be applied before arriving at the final candidate region.
The remaining stages are intentionally omitted here.
The purpose of this article is not to disclose a complete methodology, but rather to clarify a misconception that has persisted within the Bitcoin Puzzle community.
There is no hidden pattern.
There is no statistical bias in the private keys.
There is no algorithm that directly predicts the solution.

A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic  wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.

What may exist, however, is an unintended mathematical structure arising from the deterministic masking process used to establish puzzle difficulty. If that interpretation is correct, then the objective is not to discover the private key itself, but to identify a smaller, more meaningful search domain—the golden search region—within which conventional computational methods can operate far more efficiently.
In my view, that distinction is where future research should be directed.

[optioncmdPR]

The first stage of the methodology is deliberately simple.

For each puzzle, identify....
...In my view, that distinction is where future research should be directed.

This outstanding observation is not only the most feasable approach I have seen , it also a phenominal thing to be sharing it.
Thank you, whoever you may be.

[NUCLEAR7.1]

but rather to clarify a misconception that has persisted within the Bitcoin Puzzle community.
There is no hidden pattern.
There is no statistical bias in the private keys.
There is no algorithm that directly predicts the solution.

A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic  wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.

What may exist, however, is an unintended mathematical structure arising from the deterministic masking process used to establish puzzle difficulty. If that interpretation is correct, then the objective is not to discover the private key itself, but to identify a smaller, more meaningful search domain—the golden search region—within which conventional computational methods can operate far more efficiently.
In my view, that distinction is where future research should be directed.

As I've said for the past 7 months, I've found the pattern. 

[detechs]

but rather to clarify a misconception that has persisted within the Bitcoin Puzzle community.
There is no hidden pattern.
There is no statistical bias in the private keys.
There is no algorithm that directly predicts the solution.

A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic  wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.

What may exist, however, is an unintended mathematical structure arising from the deterministic masking process used to establish puzzle difficulty. If that interpretation is correct, then the objective is not to discover the private key itself, but to identify a smaller, more meaningful search domain—the golden search region—within which conventional computational methods can operate far more efficiently.
In my view, that distinction is where future research should be directed.

As I've said for the past 7 months, I've found the pattern.  

you said the puzzle 71 transactions were "not from the Creator."

the sender was 1PWo3JgFsvVgZHLtBVTRA8rbZhWhTVecyv
its HASH-160: f6f5431dbb246d70b85f78f3ad00ee54055d5ed3

puzzle 71: 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU
its HASH-160: f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8

same 4-byte prefix: f6f5431d.
probability of random match: 1 / 2^32 = 1 in 4,294,967,296.

there are 6 verified sibling addresses on this prefix including the french message sender, the "just need 1" sender, and 1PWo3JeB9jrGwfJq, a 14-character lookalike 1 bit apart from puzzle 71. probability: 2 x 10^-23.

this is a BIP32 HD wallet. consecutive children from the same seed. the creator was responding on-chain.

i already at the last gate sounding genesis who wants to learn more? the currency isn't the fruit you want
retooroora
tuuunguuuruuutuuurotu

[NUCLEAR7.1]

but rather to clarify a misconception that has persisted within the Bitcoin Puzzle community.
There is no hidden pattern.
There is no statistical bias in the private keys.
There is no algorithm that directly predicts the solution.

A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic  wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.

What may exist, however, is an unintended mathematical structure arising from the deterministic masking process used to establish puzzle difficulty. If that interpretation is correct, then the objective is not to discover the private key itself, but to identify a smaller, more meaningful search domain—the golden search region—within which conventional computational methods can operate far more efficiently.
In my view, that distinction is where future research should be directed.

As I've said for the past 7 months, I've found the pattern.  

you said the puzzle 71 transactions were "not from the Creator."

the sender was 1PWo3JgFsvVgZHLtBVTRA8rbZhWhTVecyv
its HASH-160: f6f5431dbb246d70b85f78f3ad00ee54055d5ed3

puzzle 71: 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU
its HASH-160: f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8

same 4-byte prefix: f6f5431d.
probability of random match: 1 / 2^32 = 1 in 4,294,967,296.

there are 6 verified sibling addresses on this prefix including the french message sender, the "just need 1" sender, and 1PWo3JeB9jrGwfJq, a 14-character lookalike 1 bit apart from puzzle 71. probability: 2 x 10^-23.

this is a BIP32 HD wallet. consecutive children from the same seed. the creator was responding on-chain.

i already at the last gate sounding genesis who wants to learn more? the currency isn't the fruit you want

lol What I see is that you're overusing drugs.   We were talking about dust transactions, and you asked if those dust transactions were from the creator, and I told you Not from the creator  

There are thousands of people with a similar address.

[detechs]

look up the addresses on any block explorer
both exist on mainnet

HASH-160 of 1PWo3JgFsv:
f6f5431dbb246d70b85f78f3ad00ee54055d5ed3

HASH-160 of puzzle 71:
f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8

same 4-byte prefix: f6f5431d

the blockchain has ~460 million addresses ever created
the 4-byte HASH-160 prefix space is 2^32 = 4,294,967,296

expected random collisions with this prefix: zero point one

there are 6 verified addresses on this prefix
all from the same BIP32 wallet sent by the same entity on the same day

your claim of "thousands" requires 8.5 trillion addresses
that is 18,000 times more than have ever existed

anyone can compute the HASH-160 from the base58 address and verify
the math is public

just need 1 if you claim there's thousands, tell us one more

[NUCLEAR7.1]

look up the addresses on any block explorer
both exist on mainnet

HASH-160 of 1PWo3JgFsv:
f6f5431dbb246d70b85f78f3ad00ee54055d5ed3

HASH-160 of puzzle 71:
f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8

same 4-byte prefix: f6f5431d

the blockchain has ~460 million addresses ever created
the 4-byte HASH-160 prefix space is 2^32 = 4,294,967,296

expected random collisions with this prefix: zero point one

there are 6 verified addresses on this prefix
all from the same BIP32 wallet sent by the same entity on the same day

your claim of "thousands" requires 8.5 trillion addresses
that is 18,000 times more than have ever existed

anyone can compute the HASH-160 from the base58 address and verify
the math is public

just need 1 if you claim there's thousands, tell us one more

haha  

Hash160:f6f5431d263b08974e9c2e8d695d7a7328715bfc

(P2PKH): 1PWo3JeBZ13yxvPgqrtfJthwoPmKVrV9b7

Will this convince you to believe that I am the Creator, or will you say that you were wrong and leave?

[detechs]

sign a message with the private key for that address
spend from that address on chain
derive puzzle 66 key from seed + passphrase and post it
if you had the genesis seed phrase you could get my btc right now, i used it to create my wallet a couple days ago, from dust to....

[mumsidea]

If the community moves toward updating the tools, we could make significant progress.
Modern versions of Kangaroo and BitCrack with support for different search strategies would be extremely valuable. Not only the current random search approach, but also other modes, adaptive methods, and algorithms optimized for new hardware architectures.
Better compatibility with modern GPUs and reducing implementation issues would make a huge difference.
Right now, there is no known direct way to solve Puzzle #71. However, there are three possible approaches:
1. Full keyspace search
This is already happening across several platforms. Based on the information I have collected from different communities — Telegram, Discord, Reddit, and here — the total estimated progress on Puzzle #71 is around 11%.
This is verifiable from publicly shared information.
2. Luck, prefixes, and hash-related observations
This approach can work, but it requires a significant amount of luck. There is no guaranteed method here.
3. Searching high-probability ranges
The idea of “golden ranges” depends entirely on available data and whether useful information patterns are discovered.
The biggest problem is that the main tools have not received major updates for a long time. Many forks are also not actively maintained or significantly improved.
It would be great if developers and researchers pushed this area forward again.
For a long time, there has not been much new research shared. Someone needs to start publishing even small observations.
For example:
We know from analyzing 82 solved puzzles that the private keys were never located beyond 50% of their midpoint range.
Even a small observation like this can reduce the search space slightly.
Now imagine combining hundreds of small observations like this, creating multiple filters, and building a funnel-based search strategy.
Linear search will continue.
Random search and range-based approaches are also already being used, but much of the information and analysis is not publicly shared.
Instead of everyone searching alone, we should focus on finding better candidate ranges, sharing results, and building stronger methods together.
This does not mean there is a pattern or that the private key can be directly predicted.
The goal is not to break the randomness of Bitcoin keys.
The goal is to use probability, statistics, and publicly available data to improve search efficiency.

Sharing information creates better ideas.

[napros]

If the community moves toward updating the tools, we could make significant progress.
Modern versions of Kangaroo and BitCrack with support for different search strategies would be extremely valuable. Not only the current random search approach, but also other modes, adaptive methods, and algorithms optimized for new hardware architectures.
Better compatibility with modern GPUs and reducing implementation issues would make a huge difference.
Right now, there is no known direct way to solve Puzzle #71. However, there are three possible approaches:
1. Full keyspace search
This is already happening across several platforms. Based on the information I have collected from different communities — Telegram, Discord, Reddit, and here — the total estimated progress on Puzzle #71 is around 11%.
This is verifiable from publicly shared information.
2. Luck, prefixes, and hash-related observations
This approach can work, but it requires a significant amount of luck. There is no guaranteed method here.
3. Searching high-probability ranges
The idea of “golden ranges” depends entirely on available data and whether useful information patterns are discovered.
The biggest problem is that the main tools have not received major updates for a long time. Many forks are also not actively maintained or significantly improved.
It would be great if developers and researchers pushed this area forward again.
For a long time, there has not been much new research shared. Someone needs to start publishing even small observations.
For example:
We know from analyzing 82 solved puzzles that the private keys were never located beyond 50% of their midpoint range.
Even a small observation like this can reduce the search space slightly.
Now imagine combining hundreds of small observations like this, creating multiple filters, and building a funnel-based search strategy.
Linear search will continue.
Random search and range-based approaches are also already being used, but much of the information and analysis is not publicly shared.
Instead of everyone searching alone, we should focus on finding better candidate ranges, sharing results, and building stronger methods together.
This does not mean there is a pattern or that the private key can be directly predicted.
The goal is not to break the randomness of Bitcoin keys.
The goal is to use probability, statistics, and publicly available data to improve search efficiency.

Sharing information creates better ideas.

Sounds like a good idea, but as soon as someone posts or suggests an idea, they are treated like a complete idiot. there is little to no respect by 'some' on this forum, they carry on as if they are Gods and know everything and any suggest is rubbished straight away. So I agree, a lot of applications are old and need updates, and ideas on providing suggestions or insight is treated like spam and you get treated like scum. So I wont be one of those that would be posting much. Did it before, had some bright ideas (that I thought might work) was treated like scum of the Earth. So I wish you well, and maybe someone else might step up and assist.

[optioncmdPR]

look up the addresses on any block explorer
both exist on mainnet

HASH-160 of 1PWo3JgFsv:
f6f5431dbb246d70b85f78f3ad00ee54055d5ed3

HASH-160 of puzzle 71:
f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8

same 4-byte prefix: f6f5431d

the blockchain has ~460 million addresses ever created
the 4-byte HASH-160 prefix space is 2^32 = 4,294,967,296

expected random collisions with this prefix: zero point one

there are 6 verified addresses on this prefix
all from the same BIP32 wallet sent by the same entity on the same day

your claim of "thousands" requires 8.5 trillion addresses
that is 18,000 times more than have ever existed

anyone can compute the HASH-160 from the base58 address and verify
the math is public

just need 1 if you claim there's thousands, tell us one more

It is my understnding that what is going on is someone has created a custom wallet consisting of mined  vanity addresses all starting with puzzle 71 prefix . The reason for dust transactions is convolute  transaction history for the puzzle 71 address to hope that the solver of 71 makes a wallet mistake and sends a transaction to one the look alike addresses addresses out of inexperience or carelessnesss in scrutiny.

[NUCLEAR7.1]

It is my understnding that what is going on is someone has created a custom wallet consisting of mined  vanity addresses all starting with puzzle 71 prefix . The reason for dust transactions is convolute  transaction history for the puzzle 71 address to hope that the solver of 71 makes a wallet mistake and sends a transaction to one the look alike addresses addresses out of inexperience or carelessnesss in scrutiny.

But whoever solves the puzzle will not send to address similar to the puzzle's address because they will focus on the address that begins with bc1 not 1PWo3

[crypto_user_new]

Very interesting the Vanitysearch from Jean Luc. I added a new feature to check anywhere in the BTC address

VanitySearch_the_one
Contain search: added pattern '1*XXXXXXX*'
Search: 1*XXXXXXX* [Compressed]
Start Thu Jul 23 14:01:19 2026
Base Key: A624DAB6ED1C4E9E9BD51D83XXXXXXXXXXXXXXXX5147FDBCBCEF68283EB0B674
Number of CPU thread: 1024
GPU: GPU #1 NVIDIA GeForce RTX 5060 Ti (36x0 cores) Grid(2304x128)
[2452.89 Mkey/s][GPU 2452.89 Mkey/s][Total 2^36.46][Found 1]
=================================================================
  *** KEY FOUND ***
  PubAddress : 1Fb2oPsF9DpXJ9XXXXXXXLNmXXAaaMt5Bn
  Priv (WIF) : L2nfzLXSQLfUz7poehXXXXXXXXXXXXXXXXhTgWQUYXPLuCzRBDgC4
  Priv (HEX) : A624DAB6ED1C4E9E9BD51D83XXXXXXXXXXXXXXXX5147FDBCBCEF68283EB0B674
XXXX- is to protect the key found.

The speed is a little bit faster because i modified the algorithm that is doing the random(i created my own random algorithm based on PI number). The one that is already inside is a crap and you will never find because will skip the critical points. And the sequential mode was a garbage because was doing true sequential only on suffix and not in true order.

[kTimesG]

Very interesting the Vanitysearch from Jean Luc. I added a new feature to check anywhere in the BTC address

The speed is a little bit faster because

You are aware that searching for non-prefix base58 characters requires doing H160 to base58 conversions at every single step, right? Or are in the category that now wants congratulations for slowing down the entire search process by whatever factor and calling it "faster"?

[crypto_user_new]

If is slowing down this means JeanL is doing the same...i didn't do any magic there. If you read the code, you see that you can add a new search method and add similar to other flags as prefix, hash160, suffix or search anywhere in the BTC address. The only change is when the address is generated and read similar to prefix, you clone the principle and add a new logic...
Is that hard?
The new thing that i added is the new random logic and sequential in real order.
So we do not need to reinvent the wheel....
And i reached for 5060Ti GPU 2801 Mkey/s after final touch on the code.
If i search by prefix list until 500k entries i have 2801 Mkey/s, if i search by 10M entries in the file i have 1000 Mkey/s.

[Welsh]

This topic is such a hard read because some half good information, and some information which is complete fantasy land. I'm conflicted, because the puzzle is a very cool challenge to Bitcoiners. Yet we have users claiming to have found a pattern and to have broken it, which is just impossible. If you've found the pattern, and you believe that you can solve it (not randomly) within x amount of time, you've effectively broken Bitcoin which means this puzzle no longer means anything as its practically worth 0 the time that this pattern is known.

Unless claiming the original creator of the puzzle made a mistake on their end, which I also heavily doubt otherwise every transaction / wallet around that time, created in the same way would also be suspect to the same issue. They likely used commonly used software which was mass used around this time, which would effectively mean a ton of Bitcoin would be vulnerable.

[kTimesG]

If is slowing down this means JeanL is doing the same...

Oh, my bad. I thought this topic was about finding a specific H160, in which case base58 filtering is useless. A 5060 would probably go beyond 9Gk/s for this case. If you're bragging about revolutionary base58 "inner vanity" stuff where you like to divide big integers by the number 58 up to 31 times in a loop, you're in the wrong place.

[NUCLEAR7.1]

This topic is such a hard read because some half good information, and some information which is complete fantasy land. I'm conflicted, because the puzzle is a very cool challenge to Bitcoiners. Yet we have users claiming to have found a pattern and to have broken it, which is just impossible. If you've found the pattern, and you believe that you can solve it (not randomly) within x amount of time, you've effectively broken Bitcoin which means this puzzle no longer means anything as its practically worth 0 the time that this pattern is known.

Unless claiming the original creator of the puzzle made a mistake on their end, which I also heavily doubt otherwise every transaction / wallet around that time, created in the same way would also be suspect to the same issue. They likely used commonly used software which was mass used around this time, which would effectively mean a ton of Bitcoin would be vulnerable.

I think it's a mistake by the creator, but it's useless because the only puzzle that can be exploited is 71, as the cost will be less than the reward. The remaining puzzles, even with the pattern you discovered, won't be useful because the cost will far exceed the reward, and not all puzzles are predictable.  

you've effectively broken Bitcoin

My method does not rely on encryption breaking.

Honestly, I doubt it was a mistake on the part of the creator Meaning, not intentionally, and even unintentionally, because they might have been aware of it. It doesn't necessarily have to be their mistake, as it would simply be how his system works, not necessarily an mistake.