Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 4. (Read 245966 times)

Maybe you're right! But you don't have sufficient evidence.

In my opinion, this is not a quiz but a business selling solutions from the organizer and it is not known whether the winners are from the organizer or not

Because illogical thinking cannot manifest itself as working software? At some point a logical contradiction occurs (unless you like software that includes intentional bugs), and it may be spotted even before attempting to touch a keyboard. Otherwise, the lesson is learned the hard way, but with no doubt that moment occurs sooner or later. But what stops you from giving it a shot, if you believe it's not a waste of time (or life); what are your results, besides spreading around your own beliefs, backed by nothing and impossible to prove or test?

Now that you have written these, there are software developers here who will immediately attack you.

They will say things like, you don't know ECC, you don't understand crypto, bla bla.

I am also someone who believes that all of these can be solved mathematically.

But why don't those who understand software use their codes in non-standard mathematical operations?

Why do they always think of formulas like A = B - C (x.y) with ready-made logic?

Even the A - B - C - x - y that is currently being written is mathematics.

A nice saying,
Every brave man eats yogurt differently.

Lucky or unlucky, it's not subject
Subject is Ecc
And sha256, where claim one-way working
But these all from hex to wif or pubkey then pubkey to address, there are some conversation process, and same creating tx also based on conversation,
These all process are based on math calculation
Add multiplayer substraction division, all used
If you write python, c or use bsgs or kangaroo, all based math,
Universe law is what ever step taken have footprint, which can be reversed, now see ECC
Start from 1 and end at N (....4141)
N also called 0
Mean before N-1 is called 1 = -1 same pubkey with direction of y
Now understand it's game of 0 to 1 and 1 to 0
Definitely reverse or footprint available, inside math
Example proof, when universe created, scientist send jamesweb telescope to find footprint of universe, definitely it's available
Ecc is very small portion, by math you can find, no need gpu only CPU could work,
First math based kangaroo used at CPU and take 100 bit rewards
But don't stick your mind with gpu, use math in other form at CPU definitely 160th pubkey rewards could be yours
BrainLess

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

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

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.


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.

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.

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.

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

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

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


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:



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:

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.

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.

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

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).

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


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.

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.


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.


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 ...

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

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?