Bitcoin puzzle transaction ~32 BTC prize to who solves it

[kTimesG]

perfect fit, no prediction

You'll get the exact same results / curve / fit if your inputs are randomly generated in their respective intervals. The only correct result is that 67 is somewhere between the start and the end of its respective range, with 100% confidence, and you don't need a graph for that. Anything else is pure speculation, usually futile.

[zahid888]

Dedicated to all the newbies ☟

To anyone considering stepping into these puzzle games, let me be absolutely clear: this is a black hole. It will pull you in, drain everything you have, and leave you empty-handed.
It doesn’t matter how smart you are, how lucky you think you might be, or how much effort you put in—there’s no way to escape its grip.

I stand here as proof of this harsh truth. I’ve lost not only my Bitcoin but also years of my life chasing shadows.
My advice to anyone new or hopeful is simple: turn back now. Don’t be fooled by the false promise of quick wealth.
I’ve learned the hard way that these puzzles are nothing but a relentless grind. They drain your time, your resources, and your hope, leaving you with nothing but regret.

Engaging with these puzzle games is akin to launching a process that immediately forks into an infinite loop, consuming 100% of your system resources while producing zero meaningful output. It’s a blockchain-backed black hole, an entropy vortex designed to maximize grind while minimizing ROI (Return on Investment).

Your intelligence? Irrelevant. RNG luck factor? Ineffectual. Effort? Cute, but futile. Once you enter this closed loop, you’ll find that all inputs - time, mental energy, and yes, even your precious Bitcoin - are siphoned off into the great digital void, leaving nothing but an irrecoverable stack overflow of regret.

Solving puzzles with social engineering is like trying to decrypt an avocado with a VPN -confusing, messy, and guaranteed to leave you questioning your life choices.

 Save your RAM, your energy, and your soul—run while you still have bandwidth.

Well said, and your analogy is spot-on!

You captures the essence of this trap perfectly. My hope is that others see posts like yours and mine and decide to avoid this endless recursion before it’s too late.
The worst part is how deeply they prey on human curiosity and tenacity. Once you're hooked, it feels impossible to walk away because the sunk-cost fallacy kicks in hard.
You think, ‘Just a little more effort, a bit more time,’ but it’s all for nothing.

[mcdouglasx]

Dedicated to all the newbies ☟

To anyone considering stepping into these puzzle games, let me be absolutely clear: this is a black hole. It will pull you in, drain everything you have, and leave you empty-handed.
It doesn’t matter how smart you are, how lucky you think you might be, or how much effort you put in—there’s no way to escape its grip.

I stand here as proof of this harsh truth. I’ve lost not only my Bitcoin but also years of my life chasing shadows.
My advice to anyone new or hopeful is simple: turn back now. Don’t be fooled by the false promise of quick wealth.
I’ve learned the hard way that these puzzles are nothing but a relentless grind. They drain your time, your resources, and your hope, leaving you with nothing but regret.

Engaging with these puzzle games is akin to launching a process that immediately forks into an infinite loop, consuming 100% of your system resources while producing zero meaningful output. It’s a blockchain-backed black hole, an entropy vortex designed to maximize grind while minimizing ROI (Return on Investment).

Your intelligence? Irrelevant. RNG luck factor? Ineffectual. Effort? Cute, but futile. Once you enter this closed loop, you’ll find that all inputs - time, mental energy, and yes, even your precious Bitcoin - are siphoned off into the great digital void, leaving nothing but an irrecoverable stack overflow of regret.

Solving puzzles with social engineering is like trying to decrypt an avocado with a VPN -confusing, messy, and guaranteed to leave you questioning your life choices.

 Save your RAM, your energy, and your soul—run while you still have bandwidth.

Well said, and your analogy is spot-on!

You captures the essence of this trap perfectly. My hope is that others see posts like yours and mine and decide to avoid this endless recursion before it’s too late.
The worst part is how deeply they prey on human curiosity and tenacity. Once you're hooked, it feels impossible to walk away because the sunk-cost fallacy kicks in hard.
You think, ‘Just a little more effort, a bit more time,’ but it’s all for nothing.

I totally disagree with that, it's your personal experience, you waste time if you limit yourself to using what is already written without trying to go further, but the exploration of scientific topics that seem impossible have always been solved sooner or later, sometimes even without wanting to find it!.

An example:
Heinrich Hertz, never saw the practical use of radio waves. Decades later wireless communication signals were invented,
we should never give up on something, theorems have been solved even centuries later.
Just because you can't doesn't mean that nobody else will ever do it!

[brainless]

Some one know gpu based program
For hex char combination to check priv key for address
Example
File 1 = 1 hex char
File 2 = 5 hex char
File 3 = 5 hex char


Example command
./prog-run file1.txt file2.txt file3.txt -i input-file-address.txt -o result.txt

Pythone easy but no speed
Looking gpu based, if someone already have or know git repo
Thankx

[zahid888]

I totally disagree with that, it's your personal experience, you waste time if you limit yourself to using what is already written without trying to go further, but the exploration of scientific topics that seem impossible have always been solved sooner or later, sometimes even without wanting to find it!.

An example:
Heinrich Hertz, never saw the practical use of radio waves. Decades later wireless communication signals were invented,
we should never give up on something, theorems have been solved even centuries later.
Just because you can't doesn't mean that nobody else will ever do it!

I’ve shared many things here, but as you, Nomachines, or others might think, some of them might seem like ‘cute’ or futile attempts.
However, that doesn’t mean this thread captures the full depth of my efforts or experiments—there are still many scientific tricks and insights I haven’t shared yet.

Anyway, my post is specifically aimed at newbies—those who often enter these challenges with minimal effort and high expectations, hoping for quick success.
Even many of them don’t even take the time to read older posts, study the groundwork, or fully grasp the complexity of these puzzles.

This isn’t about discouraging genuine curiosity or scientific exploration—it’s about setting realistic expectations for those who might be diving in without the preparation or perseverance needed to even begin unraveling such a relentless riddle.

[cctv5go]

I found that solving puzzles by searching for WiF private keys is rarely used here.

[brainless]

I found that solving puzzles by searching for WiF private keys is rarely used here.

Your found puzzles list addresses ?

[b0dre]

I found that solving puzzles by searching for WiF private keys is rarely used here.

This is because, instead of trying to solve puzzles by searching for WiF private keys, which is an extremely inefficient and impractical process (with a complexity of 10^58), it is much better and more effective to directly search for private keys and convert them into addresses or hash160(Ripemd160). This way, it is easier to identify the target address, as it significantly reduces the number of characters and the complexity of the process.

[gygy]

Hello,

I am a programmer specializing in creating unique solutions for cryptographic puzzles. Recently, I developed a custom code designed to search for private keys specifically for Puzzle #67. If you're interested in purchasing it, feel free to contact me via email at vita.to@yahoo.com. The price for this solution is $200.

Additionally, if you require custom code for other puzzles or challenges, I am available to create tailored solutions based on your needs. I look forward to receiving your messages and collaborating with you on exciting projects.

Hello a programmer,

You can make it public and you can get even more than $200 in donations. OR you can run it yourself and claim the reward yourself.

I hope I could help you with this.

Best regards

[invisibleecho]

Hello,

I am a programmer specializing in creating unique solutions for cryptographic puzzles. Recently, I developed a custom code designed to search for private keys specifically for Puzzle #67. If you're interested in purchasing it, feel free to contact me via email at vita.to@yahoo.com. The price for this solution is $200.

Additionally, if you require custom code for other puzzles or challenges, I am available to create tailored solutions based on your needs. I look forward to receiving your messages and collaborating with you on exciting projects.

Thank you for your suggestion. Is this feasible? Can I receive a donation by sharing the code in this topic?

Most likely not. I even wonder how you were thinking that anyone would pay $200 for a program which is said to find the solution of btc puzzle 67 which in return is, around $600k. My alarm bell would ring hard.
If it's a shitty python script then don't even waste your computational resources with it. If it's just generating random addresses from any private key within the range begin and range end - also don't waste your time due to the birthday paradox.

I wonder why people always come up with such stupid statements and I'm so sick and tired of it.
We are talking about the 67 bitcoin puzzle which has approx. 73 quintillion possible solutions. ECC operations are slow, even if optimized.
I'm a rust developer and I optimized every possible ECC operation, yet my programs don't match the speed of albertos keyhunt (even though I'm using optimization techniques like point addition rather than scalar multiplication).
There is no shortcut to iterate over the entire keyspace faster. You only can reduce the needed steps to find the solution if you can make use of some algorithms like BSGS or Pollard Rho - However, currently we can only use those algorithms on known public keys due to the nature of these algorithms (so 135 and above).

I'm sorry if this came out rude - but my code is likely faster than your program and I would never think about to sell it for even 1 cent. That's because it's far more likely to get hit by lightning rather than finding a needle in a haystack of 73 quintillion keys with the current computational limit of home PCs.

[Jorge54PT]

Hello,

I am a programmer specializing in creating unique solutions for cryptographic puzzles. Recently, I developed a custom code designed to search for private keys specifically for Puzzle #67. If you're interested in purchasing it, feel free to contact me via email at vita.to@yahoo.com. The price for this solution is $200.

Additionally, if you require custom code for other puzzles or challenges, I am available to create tailored solutions based on your needs. I look forward to receiving your messages and collaborating with you on exciting projects.

Thank you for your suggestion. Is this feasible? Can I receive a donation by sharing the code in this topic?

Most likely not. I even wonder how you were thinking that anyone would pay $200 for a program which is said to find the solution of btc puzzle 67 which in return is, around $600k. My alarm bell would ring hard.
If it's a shitty python script then don't even waste your computational resources with it. If it's just generating random addresses from any private key within the range begin and range end - also don't waste your time due to the birthday paradox.

I wonder why people always come up with such stupid statements and I'm so sick and tired of it.
We are talking about the 67 bitcoin puzzle which has approx. 73 quintillion possible solutions. ECC operations are slow, even if optimized.
I'm a rust developer and I optimized every possible ECC operation, yet my programs don't match the speed of albertos keyhunt (even though I'm using optimization techniques like point addition rather than scalar multiplication).
There is no shortcut to iterate over the entire keyspace faster. You only can reduce the needed steps to find the solution if you can make use of some algorithms like BSGS or Pollard Rho - However, currently we can only use those algorithms on known public keys due to the nature of these algorithms (so 135 and above).

I'm sorry if this came out rude - but my code is likely faster than your program and I would never think about to sell it for even 1 cent. That's because it's far more likely to get hit by lightning rather than finding a needle in a haystack of 73 quintillion keys with the current computational limit of home PCs.

I agree and say the following: Renting a GPU as I see on the privatekeys website etc, is good for those who rent, but it must be very bad for GPU owners to find puzzles

[sdhgfdsjfgsiujdgf]

Looking for more information about puzzle 66 transaction issue and how to prevent such situation. What does it mean for us, which puzzles are still secure from such outcome?
For how long a transaction can be blocked by the processing party?

[invisibleecho]

Looking for more information about puzzle 66 transaction issue and how to prevent such situation. What does it mean for us, which puzzles are still secure from such outcome?
For how long a transaction can be blocked by the processing party?

I guess it's still mostly speculation of what exactly has happened to puzzle 66.
But in short, let's assume you got really really lucky, and manage to find the private key of puzzle 67, convert the hex private key to wif, login via Electron and start a spending transaction.
As soon as there is a confirmation on the blockchain, the corresponding public key of said wallet is exposed to the public and it's not really hard to write a bot which checks the latest transaction history from any wallet.
That means, if some bot manages to get the public key in time, bruteforcing the private key via bsgs or kangaroo algorithm is not very hard and on any modern gpu would not take longer than a couple of seconds to minutes.
So any stealer can then replace your transaction with higher sats which means the blockchain will prioritize those transactions and you receive nothing.

So to answer your question of "For how long a transaction can be blocked by the processing party":
Just imagine 100 bots attempting to replace the transaction with a slightly higher fee. The will continue so unless no money is to be made. Remember, only the transaction with the highest fee will be processed.

To answer your question of which puzzles are "safe": Any puzzle with high enough entropy which cannot be solved via bsgs/pollard rho/pollard kangaroo within 10 minutes is a safe bet.
However, keep in mind that each time a puzzle is solved, the next one essentially doubles in difficulty, that's why it currently makes little sense to attempt to solve puzzle 68, 69, 70, etc. or 160 via kangaroo.
Stick with either puzzle 67 (normal bruteforcing) or puzzle 135 (kangaroo, not BSGS because BSGS is useless here).

What to really do if you manage to solve low-entropy puzzles
Again, highly speculative but as far as timing goes right - each block is mined approx. every 10 minutes. So if you get your timing right, you should be able to do the spending transaction and the next block is mined within the next seconds which should in theory increase your odds of claiming the reward.
Apart from that, I would likely try to get my timing right and combine it with Mara's slipstream, which I personally have never used, but will when I manage to find some private keys.

In any case, document anything carefully with evidence that YOU found the private key of said wallet which could be viewed at later on if anything goes wrong.

Best regards

[Cricktor]

~~~

This has been posted here or in the other topic about the Bitcoin puzzle challenge. You don't like searching, do you?

I can only estimate and maybe RetiredCoder or someone else wrote something about it, but likely all unclaimed puzzles below ~100 have to be withdrawn by a solution finder non-publicly. Otherwise the finder risks a "RBF war" and loosing the puzzle price either to some bot and/or being "converted" to transaction fee (you know what I'm talking about if you know how Full-RBF works).

To my knowledge the only public service to mine a transaction non-publicly is slipstream.mara.com.

We will yet have to see, if slipstream.mara.com can be trusted to handle a low entropy private key puzzle withdrawal transaction confidentially.

I tend to say that the solution finder for puzzle #67 would be stupid to publish his withdrawal transaction in public mempool.
The finder should document properly that he knows the public key because he found the private key at a certain point in time. Hash this message with SHA-256 or SHA-512, make the message hash public and submit his transaction to slipstream.mara.com.

I don't know if a finder could find a safe agreement with a larger mining pool offering a substantial transaction fee and having his transaction mined non-publicly by such a larger mining pool without risking being ripped off. May only work if he has a message hash published that documents his agreement with the larger mining pool. But this is not fool-proof, obviously.

As soon as there is a confirmation on the blockchain, the corresponding public key of said wallet is exposed to the public and it's not really hard to write a bot which checks the latest transaction history from any wallet.

No, this is wrong, you don't need to wait for a confirmation. As soon as a low entropy puzzle withdrawal transaction is in public mempool, still unconfirmed, the public key is revealed and bots can make advantage of that.

Apart from that, I would likely try to get my timing right and combine it with Mara's slipstream, which I personally have never used, but will when I manage to find some private keys.

How does "timing" help you when you don't know when Mara pool will find a valid block? Statistically Mara pool finds approx. every 200min one block (on average with an observance window of 1 week). And all block intervalls are only statistically average every about 10min with an observance window of 2016 blocks. You can be unlucky, like the intervall between blocks 878012 and 878013 or blocks 877956 and 877957 or ...

[invisibleecho]

As soon as there is a confirmation on the blockchain, the corresponding public key of said wallet is exposed to the public and it's not really hard to write a bot which checks the latest transaction history from any wallet.

No, this is wrong, you don't need to wait for a confirmation. As soon as a low entropy puzzle withdrawal transaction is in public mempool, still unconfirmed, the public key is revealed and bots can make advantage of that.

Ah right my bad, you're 100% correct. As soon as the transaction is broadcasted to the network it becomes publicly visible.

Apart from that, I would likely try to get my timing right and combine it with Mara's slipstream, which I personally have never used, but will when I manage to find some private keys.

How does "timing" help you when you don't know when Mara pool will find a valid block? And block intervalls are only statistically average every about 10min with an observance window of 2016 blocks. You can be unlucky, like the intervall between blocks 878012 and 878013 or blocks 877956 and 877957 or ...

The closer your transaction is to being mined (i.e., the shorter the remaining time in the current block cycle), the less time the attacker has to act.
My idea was to reduce the time any potential attacker has. Maybe I'm wrong though, still learning about blockchain
In the end, it doesn't really matter until anyone finds a low entropy private key.

[Cricktor]

~~~

For public broadcasting your transaction you would need to predict when a new block is mined within seconds (and your transaction has reached the mining pool's mempool and has been properly processed to be included in the next block). This is impossible.

For slipstream.mara.com it doesn't really matter when you submit your transaction to them. If their claim is to be trusted that a submitted transaction will be mined by Mara pool non-publicly and the pool doesn't exploit your transaction you could submit it at any time (maybe 90min after Mara's last block).

[sdhgfdsjfgsiujdgf]

~~~

For public broadcasting your transaction you would need to predict when a new block is mined within seconds (and your transaction has reached the mining pool's mempool and has been properly processed to be included in the next block). This is impossible.

For slipstream.mara.com it doesn't really matter when you submit your transaction to them. If their claim is to be trusted that a submitted transaction will be mined by Mara pool non-publicly and the pool doesn't exploit your transaction you could submit it at any time (maybe 90min after Mara's last block).

What if the key finder will post the transaction with a very large fee, like 10K, will this somehow affect the timings?

[Cricktor]

~~~

The amount of transaction fee has no influence how fast the next block is found. Finding a valid blockhash is a random process, the more and faster miners try, the quicker they statistically find a valid blockhash.

To get a transaction in the very next block it needs to have a competitive enough fee (or more), so that every mining pool has a financial benefit to include your transaction, because your transaction competes with other transaction for block space.

Since quite some time there are usually more transactions pending to be mined in a block than fit in the next block, so naturally there is competition for block space. Miners normally choose transactions based on fee rate, starting with highest paying until the block space for transaction is used up (this is very simplified).

It may work to wave with a $100 bill for a taxi to get it faster, but a Bitcoin block won't be mined quicker if your pending transaction has an overly high fee.

[FKamil5711]

My Attempt at Finding the Private Key for Wallet #145

Hello everyone,

This is my attempt at finding the private key for Wallet #145. Please note that I’m not a programmer or mathematician, I’m just someone who became fascinated by cryptography and stumbled across this puzzle. I might be completely wrong here. I'm happy to learn and would love to hear where I went astray if that’s the case.


Background

This script ran on a Hetzner EX44 server and my old HP G4 Chromebook running Arch Linux. From the start, I knew brute-forcing or even attempting BSGS without GPU acceleration was an almost impossible task. However, it was all I could afford, and I didn't want to invest too much in building a dedicated rig.

Eventually, I had to stop after my Chromebook gave out.I learned a lot during the process, and I wanted to share my findings with you.


Leading Zeros

By analyzing previously found private keys for earlier wallets, I noticed a pattern in the number of leading zeros. Based on this, I estimated that the private key for Wallet #145 might have 30–32 leading zeros. Here’s how I came to that conclusion:

Known Keys

Code:

Key #110: 00000000000000000000000000000000000035c0... (38 leading zeros)
Key #115: 00000000000000000000000000000000000060f4... (38 leading zeros)
Key #120: 00000000000000000000000000000000000b10f... (37 leading zeros)
Key #125: 0000000000000000000000000000000001c533... (36 leading zeros)

Pattern Analysis

There is a consistent loss of approximately 1 leading zero every 5 positions.

Between Key #125 and Key #145, there are 20 positions, meaning about 4 leading zeros are likely lost in this interval.

Starting from 36 leading zeros at Key #125, I subtracted 4, leaving me with an estimate of 32 leading zeros for Key #145.


Near Misses and Hot Zones

What is a Near Miss?

A near miss occurs when part of the public key derived from a guessed private key matches part of the target public key. The more bytes that match, the closer the guessed private key is likely to be to the target key on the elliptic curve.

Here’s an example:

Code:

Target Public Key:
03afdda497369e219a2c1c369954a930e4d3740968e5e4352475bcffce3140dae5

Guessed Public Key:
03afdda497369e219a2c1c369954a930e4d3a4936821b5458756bf12afc3412c87

Matching Bytes:
03afdda497369e219a2c1c36 (5 bytes matched)

What Are Hot Zones?

Hot zones are specific subranges within the private key space that are more likely to contain the target private key. They are identified by analyzing clusters of near misses. If multiple near misses occur in a particular range, it becomes a hot zone worth focusing on.

Example Hot Zones

Based on my analysis, here are some identified hot zones:

Code:

Range 0x4: (0x4c000000, 0x4dffffff)

Range 0x5:

Primary: (0x52000000, 0x53ffffff)

Secondary: (0x59000000, 0x5affffff)


Range 0x7: (0x75000000, 0x76ffffff)

For instance, if near misses cluster in the range 0x52000000–0x53ffffff, this subrange becomes a primary hot zone within the larger 0x5 range.


How Does This Process Work?

1. Run a Search:
The script uses BSGS to search the keyspace and logs all near misses, including the guessed private key and match details.


2. Analyze Near Misses:
Clustering is analyzed to define hot zones, which are subranges where matches are more likely.


3. Refine the Search:
Resources are dynamically reallocated to focus on promising hot zones, while continuing some exploration in less-likely areas to avoid missing the target key.




Challenges and Limitations

1. Bias:
If early near misses disproportionately influence the weights or hot zones, the search might ignore other valid ranges, leading to a self-reinforcing bias.


2. Sparse Data:
With too few near misses, it’s difficult to establish meaningful clustering or confidently define hot zones.


3. Random Noise:
Some near misses occur randomly, creating false hotspots if not carefully analyzed.


Final Thoughts

While I ultimately didn’t succeed in finding the private key for Wallet #145, I learned a lot about cryptography, elliptic curve mechanics, and computational optimization. I’d love to hear your thoughts or suggestions on my approach. If you see any glaring mistakes or areas for improvement, please don’t hesitate to point them out—I’m here to learn.

Thank you for reading, and I hope this helps others interested in cryptography or keyspace searching!


Feel free to share your thoughts, corrections, or suggestions. If you have insights on hot zones, leading zeros, or better search strategies, I’d love to hear them. I also read RetiredCoder's Rckangaroo script, which is much better than my code. I haven't fully read the thread yet but it seems like his solution is the best for the time being. Here’s the file for Hexplorer, my attempt at finding Key #145. https://drive.google.com/drive/folders/1P-94tGIjwhbvItMPlLqZPzsHSLfbLMYi

> Note: This is an older save, so if you try to run it, double-check it first. I really don’t want to give myself a brain aneurysm trying to code on my phone, typing this fried my brain. Also to the mods let me know if I'm breaking any rules.

[iceland2k14]

By analyzing previously found private keys for earlier wallets, I noticed a pattern in the number of leading zeros. Based on this, I estimated that the private key for Wallet #145 might have 30–32 leading zeros.

A near miss occurs when part of the public key derived from a guessed private key matches part of the target public key. The more bytes that match, the closer the guessed private key is likely to be to the target key on the elliptic curve.

Unfortunately both of your assumptions you need to revise.
1. If looking for Puzzle 145 then it is certain to be contained in the bit range given by pow(2, 144) to pow(2, 145) - 1. Which means in the the Hex range of 0000000000000000000000000001000000000000000000000000000000000000   to  0000000000000000000000000001ffffffffffffffffffffffffffffffffffff

2. On Elliptic curve math, the distance is not measured like ordinary math. You can't say by looking even the public Key with the actual distance of 1. See there is no matching pattern between the bytes of these two.

Private_Key     Public_Key
1                    0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
2                    02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5