Bitcoin puzzle transaction ~32 BTC prize to who solves it

[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

[FKamil5711]

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

Ah,at least now I can see why my efforts were doomed from the start, it is now glaringly obvious.

[kTimesG]

It is so funny how some people think that because two points look alike then its a hot zone worth to investigate, while some others think the complete opposite. And they're both right: you can indeed argue that you can get closer to a solution little by little (see genetic algorithms), and you can also argue that statistically the solution should be as far away as possible from any other similar solution.

It's a very good example of why they are both actually wrong, and the winner here is simple, his name is Random and it seems no one wants to accept its definition or his highly entropic personality. Random is very hated and bullied, and no one believes him or takes him for granted, because he has a really big problem: every time you look at him, there are high chances he may look completely different. Or maybe not. Or maybe just a little? But random has a girlfriend: Prime. Prime understands him and the two share a lot of common ground, but they have a secret relationship.

The curve equation and parameters are completely and intentionally devised and chosen in such a way to ruin all of these assumptions, hopes, and "I know better"s. No, there is no magic pattern, formula, neural network, simplification, reduction, statistical analysis anomalies, or other similar BS. There is no pattern in either decimal, hex, binary, ASCII art, Photoshop horoscope, or any other visual mapping from bits to representation that you can ever think of.

Also if one does not have a clue about what hex numbers mean, they should really not waste time on discovering fundamental knowledge (for themselves only) while trying to break something called Elliptic Curve Cryptography. Now, this doesn't mean they are stupid, it just means that someone may be able to understand black holes equations, but it doesn't mean they should ever touch programming.

[FKamil5711]

It is so funny how some people think that because two points look alike then its a hot zone worth to investigate, while some others think the complete opposite. And they're both right: you can indeed argue that you can get closer to a solution little by little (see genetic algorithms), and you can also argue that statistically the solution should be as far away as possible from any other similar solution.

It's a very good example of why they are both actually wrong, and the winner here is simple, his name is Random and it seems no one wants to accept its definition or his highly entropic personality. Random is very hated and bullied, and no one believes him or takes him for granted, because he has a really big problem: every time you look at him, there are high chances he may look completely different. Or maybe not. Or maybe just a little? But random has a girlfriend: Prime. Prime understands him and the two share a lot of common ground, but they have a secret relationship.

The curve equation and parameters are completely and intentionally devised and chosen in such a way to ruin all of these assumptions, hopes, and "I know better"s. No, there is no magic pattern, formula, neural network, simplification, reduction, statistical analysis anomalies, or other similar BS. There is no pattern in either decimal, hex, binary, ASCII art, Photoshop horoscope, or any other visual mapping from bits to representation that you can ever think of.

Also if one does not have a clue about what hex numbers mean, they should really not waste time on discovering fundamental knowledge (for themselves only) while trying to break something called Elliptic Curve Cryptography. Now, this doesn't mean they are stupid, it just means that someone may be able to understand black holes equations, but it doesn't mean they should ever touch programming.

It’s clear you have a strong understanding of elliptic curve cryptography, and your points about randomness and the intentional design of ECC are well taken. I completely agree that the parameters of the curve were chosen to defy patterns, and my attempt to find hot zones or meaningful clustering was based on flawed assumptions.

I think there’s still value in experimenting, I am a layman in cryptography after all, even when the outcome is almost certainly failure. I went into this knowing that without GPU acceleration or distributed systems, my chances of finding the key were practically zero. But for me, this was less about cracking ECC and more about learning and  challenging myself.

Even though the process didn’t lead to a solution, it gave me a deeper appreciation for the strength of ECC and how robust these systems are. I recognize now that randomness really is the "winner" here, and any clustering I thought I saw was more a product of my own misinterpretation than a meaningful signal.

I share this not to "reinvent the wheel" or to claim expertise, but because I found the process rewarding and hope others might learn from my mistakes or even just my curiosity. While I’ll be stepping away from this puzzle, I’ve gained a lot from the experience, and for me, that’s what matters most.

[invisibleecho]

I went into this knowing that without GPU acceleration or distributed systems, my chances of finding the key were practically zero. But for me, this was less about cracking ECC and more about learning and  challenging myself.

This is only partly true. The only thing a GPU is better at in this scenario is higher electricity costs.
GPUs can do insane amount of parallel work and thats because the Pollard Kangaroo algorithm is statistically faster than BSGS on a GPU, because the nature of the algorithm relies on collision delection and random walks. However, there is no garuantee that you find said solution in sqrt(k2-k1) steps.

BSGS on the other side, receives its performance due to a big precomputed baby step table. This means for every known public key in the table, you can reduce the number of ECC operations (which are known to be slow, even when optimized).
The only constraint here is available memory so in practise this means BSGS will most likely never achieve perfect runtime simply because there is not enough memory in the world. However, if you have high CPU cores and high RAM - it most likely performs better on CPU than on GPU due to more memory available.

Even though the process didn’t lead to a solution, it gave me a deeper appreciation for the strength of ECC and how robust these systems are. (...)
I share this not to "reinvent the wheel" or to claim expertise, but because I found the process rewarding and hope others might learn from my mistakes or even just my curiosity. While I’ll be stepping away from this puzzle, I’ve gained a lot from the experience, and for me, that’s what matters most.

Well, the fact that you realized how hard it is to crack the ECDLP - even when the problem is made much easier on purpose is valuable. That means you most likely understand now the main point of those puzzles.

[saatoshi_falling]

Bitcoin just hit 100k again. Time for some ChatGPT + Python + Crackpot theories and the enduring acceptance of defeat as I cook my ramen noodles.

[Denevron]

algorithms are of course good, but it seems to me that to find the same private key for the 135 puzzle, you just need luck and nothing more