Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Bram24732]

I suggest we stop engaging with McDouglas.
We took enough time and created enough resources for anyone with half a brain to understand why prefix theory is flawed. We’re just polluting the thread for other people at this point.

[nomachine]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

You aren’t fighting the entire 2²⁵⁶ universe—just a 2⁶⁹ keyspace.

My approach:

Instead of using secp256k1 for key derivation, I propose:

Generating all possible uncompressed Wallet Import Formats (WIFs) within the 69-bit keyspace (specifically, from 0x10000000000000000 to 0x1FFFFFFFFFFFFFFFF).

Optimizing the process using warpseeding—a custom acceleration method combining SHA-256 hashing and Base58 encoding for faster WIF generation.

Checking each WIF against the Puzzle #69 address to identify the correct private key.

Bypassing curve operations entirely

P.S. Converting each WIF to a Bitcoin address (which does require secp256k1, but only after filtering).

[Akito S. M. Hosana]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

You aren’t fighting the entire 2²⁵⁶ universe—just a 2⁶⁹ keyspace.

My approach:

Instead of using secp256k1 for key derivation, I propose:

Generating all possible uncompressed Wallet Import Formats (WIFs) within the 69-bit keyspace (specifically, from 0x10000000000000000 to 0x1FFFFFFFFFFFFFFFF).

Optimizing the process using warpseeding—a custom acceleration method combining SHA-256 hashing and Base58 encoding for faster WIF generation.

Checking each WIF against the Puzzle #69 address to identify the correct private key.

Bypassing curve operations entirely

P.S. Converting each WIF to a Bitcoin address (which does require secp256k1, but only after filtering).

How do you filter characters after "5HpHagT65TZzG1PH3CSu63k8DbpvD8s5i" ? 

[nomachine]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

You aren’t fighting the entire 2²⁵⁶ universe—just a 2⁶⁹ keyspace.

My approach:

Instead of using secp256k1 for key derivation, I propose:

Generating all possible uncompressed Wallet Import Formats (WIFs) within the 69-bit keyspace (specifically, from 0x10000000000000000 to 0x1FFFFFFFFFFFFFFFF).

Optimizing the process using warpseeding—a custom acceleration method combining SHA-256 hashing and Base58 encoding for faster WIF generation.

Checking each WIF against the Puzzle #69 address to identify the correct private key.

Bypassing curve operations entirely

P.S. Converting each WIF to a Bitcoin address (which does require secp256k1, but only after filtering).

How do you filter characters after "5HpHagT65TZzG1PH3CSu63k8DbpvD8s5i" ? 

You just have to know everything, don’t you?   

[Akito S. M. Hosana]

🔮 Curvature in Bitcoin's key space?
In physics, the curvature of space-time allows a ship (hypothetically) to take a shortcut, like in a warp drive. In Bitcoin's key space (a space of 2²⁵⁶ possible private keys), finding a specific key is like searching for a grain of sand in an entire universe. But... what if we could "curve" that space somehow? A lot of Netflix, right?

You aren’t fighting the entire 2²⁵⁶ universe—just a 2⁶⁹ keyspace.

My approach:

Instead of using secp256k1 for key derivation, I propose:

Generating all possible uncompressed Wallet Import Formats (WIFs) within the 69-bit keyspace (specifically, from 0x10000000000000000 to 0x1FFFFFFFFFFFFFFFF).

Optimizing the process using warpseeding—a custom acceleration method combining SHA-256 hashing and Base58 encoding for faster WIF generation.

Checking each WIF against the Puzzle #69 address to identify the correct private key.

Bypassing curve operations entirely

P.S. Converting each WIF to a Bitcoin address (which does require secp256k1, but only after filtering).

How do you filter characters after "5HpHagT65TZzG1PH3CSu63k8DbpvD8s5i" ?  

You just have to know everything, don’t you?  

Well, I’m just asking because it’s impossible to break through the 51 – 33 = 18 missing Base58 characters—unless there’s some trick. If the missing characters follow a predictable structure (e.g., repeated segments, checksums, or known prefixes/suffixes), then maybe. But there is no pattern here—only the first 33 characters are repeated. Checksum + segments = lol?  

5HpHagT65TZzG1PH3CSu63k8DbpvD8s5iq4NLznbSoMvfzUuhdh
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ipfXCoMnmssNNsN77qV
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ipGvCSgayELk4Uxq4ZA

I've been staring at last 10 WIFs for 20 minutes now.

[0x1FFFFFF]

You need the fastest hashlib and Base58 implementation in the world,
Warp-level
I’ve worked on this and developed a solution

holy moly

Wait, we don't need a public key here? BTC address?

Hi NoMachine, I test your WIF roulette, but Wif speed key doesnt show up ? only spinning wheel animation

[nomachine]

Hi NoMachine, I test your WIF roulette, but Wif speed key doesnt show up ? only spinning wheel animation

No, the output is filtered in the Python script to avoid potential errors when the subprocess writes to a pipe. You can test the speed directly by running ./WIFRoulette.

[7^k*G]

Another test simulating mining, infinite possibilities and solutions.

your method does not guarantee a 100% match. the algorithm does not iterate hashes inside subblocks starting from matching the first bits to the block boundary. with a difficult of 16 bits (as in the example) for some reason you are sure that the prefix will not be repeated in less than 5000 steps, and this is not a correct assumption. two prefixes can go either one after another or not repeat for a large number of iterations. If you are unlucky, you will go through the entire 68th range and will not find the desired hash.

[kTimesG]

Presenting the Scooby Doo method

... also called "Where are you? Whoo Whoo!" - because we all love animals inhere: from kangaroos to cats writing better code then most here, when walking over our keyboard.

Besides, we all have something in common: we don't know where Scooby is! I mean, the random key... uhm.

Prerequisites:

1. Clone any of the prefix theory magic scripts, in whatever language you wish.
2. Make sure the programming language is not rigged (what can we even trust these days, right? Even the AI became unreliable when writing high quality enterprise-level code).
3. Patch the bastard:

Code:

>>> Remove this!
            if not found_prefix and h.startswith(prefix_hash):
>>> Replace with this:            
            if random.randint(0, 5000) == 0:    // critical magic update

4. Run and watch the magic happen! Wins wins wins WINS !!!11

The Scooby Doo method relies on the following optimizations:

- replaces deprecated prefix search with a better heuristic method - efficiency, baby!
- removes reliance on any pre-existing useless information, such as "what are we even looking for anyway?"
- finds stuff faster! Why? Who are you, the police? It just works.
- leaves any sequential method far behind. Let's get rid of that sucker and switch to the Scooby Doo method TODAY!

Caveats and known issues

1. Please don't show this to your math teacher - they may lose their night's sleep trying to figure out if you broke reality.

2. It is forbidden to shuffle the block order when comparing the Scooby Doo method with other methods.

3. If you are comparing the Scooby Doo method with any other method - please make sure to use the same block order, so that we have a fair comparison of the same initial conditions.

4. Do not dare to ever disclose the Scooby Doo method to a statistician. They will terrorize you with all sorts of graphs showing cumulative probabilities, survival functions integration areas, and all sorts of voodoo that no one who cares about their mental sanity would ever understand.

Disclaimer

The Scooby Doo method might be dangerous and present a high risk factor of working slower than expected in some circumstances, but life is dangerous anyway.

Using the Scooby Doo method is not a cryptographical advice. Use at your own discretion.

[kTimesG]

Wonderful technical application, congratulations! It will be very useful for the thread.

1. It works better than your original.
2. It does the same thing, but better.
3. It always works, did you even try it? I think you don't understand the script...
4. It's explained at the same technical level as all of your explanations. Just improves on them.

I'm out of this, need to shift focus on the Scooby Doo method. I suggest everyone to make the upgrade - better at the same thing.

[Bram24732]

Wonderful technical application, congratulations! It will be very useful for the thread.

1. It works better than your original.
2. It does the same thing, but better.
3. It always works, did you even try it? I think you don't understand the script...
4. It's explained at the same technical level as all of your explanations. Just improves on them.

I'm out of this, need to shift focus on the Scooby Doo method. I suggest everyone to make the upgrade - better at the same thing.

I know I said we should stop engaging, but the ScoobyDoo method was too good to ignore. Loved it.

[fantom06]

Presenting the Scooby Doo method

... also called "Where are you? Whoo Whoo!" - because we all love animals inhere: from kangaroos to cats writing better code then most here, when walking over our keyboard.

Besides, we all have something in common: we don't know where Scooby is! I mean, the random key... uhm.

Prerequisites:

1. Clone any of the prefix theory magic scripts, in whatever language you wish.
2. Make sure the programming language is not rigged (what can we even trust these days, right? Even the AI became unreliable when writing high quality enterprise-level code).
3. Patch the bastard:

Code:

>>> Remove this!
            if not found_prefix and h.startswith(prefix_hash):
>>> Replace with this:            
            if random.randint(0, 5000) == 0:    // critical magic update

4. Run and watch the magic happen! Wins wins wins WINS !!!11

The Scooby Doo method relies on the following optimizations:

- replaces deprecated prefix search with a better heuristic method - efficiency, baby!
- removes reliance on any pre-existing useless information, such as "what are we even looking for anyway?"
- finds stuff faster! Why? Who are you, the police? It just works.
- leaves any sequential method far behind. Let's get rid of that sucker and switch to the Scooby Doo method TODAY!

Caveats and known issues

1. Please don't show this to your math teacher - they may lose their night's sleep trying to figure out if you broke reality.

2. It is forbidden to shuffle the block order when comparing the Scooby Doo method with other methods.

3. If you are comparing the Scooby Doo method with any other method - please make sure to use the same block order, so that we have a fair comparison of the same initial conditions.

4. Do not dare to ever disclose the Scooby Doo method to a statistician. They will terrorize you with all sorts of graphs showing cumulative probabilities, survival functions integration areas, and all sorts of voodoo that no one who cares about their mental sanity would ever understand.

Disclaimer

The Scooby Doo method might be dangerous and present a high risk factor of working slower than expected in some circumstances, but life is dangerous anyway.

Using the Scooby Doo method is not a cryptographical advice. Use at your own discretion.

I'm intrigued by this method and want to try it out.

[kTimesG]

Presenting the Scooby Doo method

I'm intrigued by this method and want to try it out.

That's the spirit! Letting everyone freely test remarkable advancements in the field of cryptography.

Meanwhile, the first 5-year old benchmarks of the ScoobyDoo method are now out. After letting it whoo! whoo! for 15.000 simulations, here's how the data looks like.

Yes, this picture was drawn by a cat while playing with the mouse. Go figure, right? I mean, literally, here's a figure.



I can't really make heads or tails out of this. Since the Scooby Doo revolution has just begun, I believe we need some experts in the field of dream interpretation cartoons here.

Until then, let's celebrate - the Scooby Doo method wins in over 63% of the time.

Not sure what's up with the bottom left thing though - IS THAT A SNAIL OR WHAT? Are we getting into too much zoology? Help!

[fixedpaul]

Presenting the Scooby Doo method

Can't post images using [img]

[Bram24732]

No need to act like a pack of Twitter bullies.

To be fair we explained stuff in a friendly way for 20 pages before giving up and starting making fun of you.
Maybe, just maybe, your behaviour caused this ?

Also, don’t worry. Many geniuses have been mocked during their lifetime.

[Bram24732]

No need to act like a pack of Twitter bullies.

To be fair we explained stuff in a friendly way for 20 pages before giving up and starting making fun of you.
Maybe, just maybe, your behaviour caused this ?

Also, don’t worry. Many geniuses have been mocked during their lifetime.

don’t worry, I'm 100% sure that I'm right.

Who might be interested.
Probabilistic search of prefixes vs random+sequential

Idk why when we say something we’re idiots who don’t get maths but when RC says the same thing it’s gospel.
Glad we have a dedicated post for this though !

[White hat hacker]

1. Does the method guarantee finding the target?

Random Method:
No, the random method does not guarantee that the target will be found. Since the selection is random, there's always a chance the correct key may never be hit, even after billions of attempts.

Sequential Method:
Yes, the sequential method does guarantee that the target will be found—eventually. It walks through the entire keyspace in a defined order, ensuring the target is reached if it exists within the range.

2. Memory usage and performance

Random Method:
One major downfall of the random method is that you need to store every point that has already been calculated.
Why? Because there's a high chance the algorithm will hit the same key multiple times.
To avoid repeating calculations, you’d need to store and check against all previously visited keys, which requires a huge amount of memory.
This not only slows down performance due to frequent memory lookups but also increases the complexity of the implementation.

Sequential Method:
In contrast, with the sequential method, you don’t need to store every key.
You only need to track the last key calculated. There's no duplication, and memory usage remains minimal.
This makes the sequential method faster, more memory-efficient, and easier to manage.

Conclusion
While the random method might give the illusion of better performance in short experiments due to lucky hits, it comes with significant drawbacks: lack of guarantee, heavy memory use, and slower performance over time. The sequential method is predictable, memory-efficient, and guaranteed to succeed, making it a more reliable and scalable solution in the long run.

[Bram24732]

1. Does the method guarantee finding the target?

Random Method:
No, the random method does not guarantee that the target will be found. Since the selection is random, there's always a chance the correct key may never be hit, even after billions of attempts.

Sequential Method:
Yes, the sequential method does guarantee that the target will be found—eventually. It walks through the entire keyspace in a defined order, ensuring the target is reached if it exists within the range.

2. Memory usage and performance

Random Method:
One major downfall of the random method is that you need to store every point that has already been calculated.
Why? Because there's a high chance the algorithm will hit the same key multiple times.
To avoid repeating calculations, you’d need to store and check against all previously visited keys, which requires a huge amount of memory.
This not only slows down performance due to frequent memory lookups but also increases the complexity of the implementation.

Sequential Method:
In contrast, with the sequential method, you don’t need to store every key.
You only need to track the last key calculated. There's no duplication, and memory usage remains minimal.
This makes the sequential method faster, more memory-efficient, and easier to manage.

Conclusion
While the random method might give the illusion of better performance in short experiments due to lucky hits, it comes with significant drawbacks: lack of guarantee, heavy memory use, and slower performance over time. The sequential method is predictable, memory-efficient, and guaranteed to succeed, making it a more reliable and scalable solution in the long run.

Let’s quit the AI stuff.
Both method find the solution 100% of the time. This wasn’t the debate

No need to act like a pack of Twitter bullies.

To be fair we explained stuff in a friendly way for 20 pages before giving up and starting making fun of you.
Maybe, just maybe, your behaviour caused this ?

Also, don’t worry. Many geniuses have been mocked during their lifetime.

don’t worry, I'm 100% sure that I'm right.

Who might be interested.
Probabilistic search of prefixes vs random+sequential

Idk why when we say something we’re idiots who don’t get maths but when RC says the same thing it’s gospel.
Glad we have a dedicated post for this though !

I haven't mentioned Rc, but since you bring it up, I wasn’t sure about their Sota method until I tested it. As a result, I publicly acknowledged it in their thread. I'm not going to debate something I know I'm wrong about just out of ego. If I haven’t accepted yours explanations, it’s not because of ego—it’s because if checks/simulations are relatively equal in each method, the only way to determine which one is better is by relying on the average number of victories, which is the truly important point here. Since the overall average does not interfere, it balances out proportionally.

Sota is not their method, it’s… well it’s sota.
I think they mentioned the additional improvements over it are theirs though.(I.e unpublished)
No method is better than the other. They just have different variances.
Prefix is high risk high reward and linear is medium risk medium reward. It’s not that complicated.

Also, it’s not about ego. There is no right or wrong here.

[kTimesG]

it’s not because of ego—it’s because if checks/simulations are relatively equal in each method, the only way to determine which one is better is by relying on the average number of victories, which is the truly important point here. Since the overall average does not interfere, it balances out proportionally.

Avg checks / wins = X checks / win.

You see X going down, which is great.
You also see wins go up, which is even greater.

However the cost is the same (and I mean identical), because what we have is:

X * win_rate = average cost

But your important points are to have a very small X with a very high win_rate.
So what you did, is to compare a very amplified winner with a very diminished less winner.

Now - why not apply the same logic for the losses to see who loses more?

Avg checks / losses = X checks / loss.

We're still interested to have a low X even if we lost.

Now the bad news: precise loses more here: it has a much higher X then sequential's X.

So you only see the half of the water glass that you want to look at.

When in fact, if the costs are identical, it has zero relevance who won more, or who lost more, or what the number of ties even was. Those are not metrics, they are betting gambles.

Because, on average, they both do the exact same thing, in the exact same time.

And the best part: it happens even without actually checking for a prefix. The graphs clearly show this:

- when prefix wins: it wins by a very very little difference (differences histogram on the prefix wins are concentraded towards 0)

- when prefix loses: it loses by a very high difference (a lot of very higher value differences going away to the left from zero)

Now, here's the conclusion: you are right.

[WanderingPhilospher]

Whilst a few members have been arguing into a large void...others have been analyzing data, running tests, recording results, tweaking results, re-analyzing, re-doing everything lol.

Here is what I know, which is public data from my Puzzle Prefix channel...I have came up with good results on finding the next 48+ bit, matching h160 (leading).

Yesterday I was able to:

Find, 33 each, minimum of 48 leading h160 bits, using a single 5090, a single 4090, and 256 CPU cores, averaging about 2 MK/s, all in a 14 hour period. Seems pretty decent.

Earlier today I was able to:

Find eight, 48+ bit prefixes, in a little over 1.5 hours, with only 264 CPU cores. Yeah, you do the math on that one.

Currently I am testing a combo method, and then I will test one more method, and either use some hybrid method or single method.

Does it mean I will find the key first, no. If I had the same power as Bram, would I find it before him? I dunno, but I would like my chances.

Five more 48+ found in the last 1.5 hours. Let's do the math on this one real quick, which may be off, but you get the idea, I think:

(2^48 * 5) / 5400 = 260,624,978,435 average speed normally needed to find five 48+ prefixes no? (I mean unless you are one of the ones who say they could all be in a row, lol).
My actual speed = 264 CPU cores averaging 2.5ish MK/s = 660,000,000

Anywho, nothing really to write home about, but something to write about here.

Data used: Bram's data from 67 and my data from 64, 67, 68, and some of the current 69.