Bitcoin puzzle transaction ~32 BTC prize to who solves it

[bitstonps]

1PWo3JeB9jrpyPqE6SjTbwjLYKxKYUoJp5    7f92587dd9bd019205

1PWo3JeB9jmSowkWjitaLThLHAXpaaGyhK    63DB63922CCF61F212
1PWo3JeB9jqYnGF6zgup6YhFJqGU1DMD3E    7262E6459E9F509905

......

ok)
0x7494C99EB88E06F4AC   1PWo3Jeb9jrpwQZppPEo9vbMAEe6Cz4yTL
0x5140311810FA10ABBB   1PWo3JeB9jr2CWZ6F7FFx3F4hdHRGNaBnx

can you send me the software or the code plz1

Use this one from fixedPaul :

https://github.com/FixedPaul/VanitySearch/tree/master/Compiled-Ubuntu22.04-CUDA12

I recommend working on Linux (Full performance).. and there is also a version for windows.

Thank me later

[detechs]

If everybody is scanning by itself and is selfish , you will never have a chance to find anything...If everyone that was contributing here with an ideea was scanning a range and post it in group that no one will scan once again, until now everything wa solved until puzzle 100...
but in this rithmeveryone want to get the prize and not communicating with others...

You’re absolutely right. If everyone scans alone and keeps their ranges to themselves, we’re just wasting resources by overlapping and scanning the same keys again.

The only way a community effort can really work is through communication: post the range you’re scanning, mark it as completed, and make sure others don’t repeat it. If everyone contributes and coordinates properly, we can cover much more ground instead of competing against each other.

In the end, everyone wants to find the prize, but cooperation gives the whole group a much better chance than everyone working selfishly.

The problem to solve is, how does the community trust who is running it? How will anyone trust the person or people in charge? If we can solve this issue and somehow puzzles are distributed fairly and automatically with open source code to prove this happens. Then people will feel better to contribute. Currently all puzzle pool efforts are private and you have no idea if your just helping someone else to take it from you at the end. This is why no one shares, and why no one trusts each other. There is too much Bitcoin in the puzzles for any one person who group to need for many lifetimes... From my understanding of the puzzles, the patoshi wallets and the genesis block. The bitcoin puzzles were not created to be solved or brute forced by one person. That's the puzzle... It's to teach you about working together and by yourself you will get stuck at every layer.

The smart people have already been sharing knowledge and working together, strangers realising alone they cannot achieve their goals alone and freely sharing their own knowledge without fear. What comes around comes back around again, the rewards in life for those willing to share will come from Bitcoin rewards or some other reward they were not expecting to receive. Personally I have learned more from trying to solve Bitcoin than any puzzle reward could ever give me.

If you want to receive, you have to give first. That's how energy works... Equal and opposite reactions.

[toshisa_toshisa]

Congratulations again on solving Puzzle #135. It was an impressive technical achievement, and your dedication is undeniable.

That said, I have mixed feelings after reading that it took around **200 GPUs running for 5 months**. For many of us, that's simply impossible. Most enthusiasts have one GPU, maybe two if they're lucky. Competing against hundreds of GPUs makes these puzzles feel less like a test of skill and more like a contest of who has access to the biggest hardware budget.

I know the rules never promised an equal playing field, and you earned your success. But it's hard not to feel discouraged when the resources required are far beyond the reach of the average participant. It makes the challenge seem increasingly inaccessible to anyone without substantial computing power.

I hope future community challenges can find ways to reward creativity, optimization, and efficiency—not just raw hardware scale—so more people have a realistic chance to compete.

Congratulations again, and one small favor if you have a few minutes. I've been building a Bitcoin Puzzle research web app and I'm getting close to publishing it. Since you've spent years optimizing this field, I'd really value your feedback.

If you have time, could you please take a quick look and let me know what you think could be improved before I publish it?

https://btc-puzzle-solver-search-lab.ai.studio/

Any advice or criticism would be greatly appreciated. Thanks, and congratulations once again on your achievement.

I wrote this comment for RC why did u copypaste it?

[puzzle_72_worker]

The best ideea will be a platform that you can see only if you share ranges that you found.
So i think i will build a platform that you will gave access to scanned ranges only if you add daily or weekly an amount of ranges scanned that are not in database. I have a good ideea how to get rid of cheaters and peopke who do not want to share.
i will try to build this platform and invite only quality people devoted to the cause with share of prize.

[brainless]

1PWo3JeB9jrpyPqE6SjTbwjLYKxKYUoJp5    7f92587dd9bd019205

1PWo3JeB9jmSowkWjitaLThLHAXpaaGyhK    63DB63922CCF61F212
1PWo3JeB9jqYnGF6zgup6YhFJqGU1DMD3E    7262E6459E9F509905

......

ok)
0x7494C99EB88E06F4AC   1PWo3Jeb9jrpwQZppPEo9vbMAEe6Cz4yTL
0x5140311810FA10ABBB   1PWo3JeB9jr2CWZ6F7FFx3F4hdHRGNaBnx

can you send me the software or the code plz1

Use this one from fixedPaul :

https://github.com/FixedPaul/VanitySearch/tree/master/Compiled-Ubuntu22.04-CUDA12

I recommend working on Linux (Full performance).. and there is also a version for windows.

Thank me later

Already tested bad product
Search 1PWo3J
With switch -m and -random too
You will see result prompt and analyze his randomness formula will never find anything

[kTimesG]

Your phrasing - "for a better k without sacrificing the speed" - implies the +33% is not mandatory. That is the part I cannot reconstruct from the source. Is the cheap add amortised into the batched inversion in a way the naive count misses, or is it a different construction than the one described in the v3.x notes?

I am not sure how you ended up with the 33%. Yeah, for SOTA+ there's always the cheap point overhead of 1M + 1S, but going from that to a 33% is a long shot, because theory != implementation, and not everything is just about the EC math in the loop (there's cycle detection, DP, answering "what direction is REALLY better to jump next?" and so on).

In other words, there are other practical benefits to always computing the cheap point, which are absent  when computing it conditionally, which translate in the end, to the 1M + 1S gap paying itself out to slightly faster solves overall, on average. Yes, things will run at a lower speed, but the expected lower k compensates.

The best ideea will be a platform that you can see only if you share ranges that you found.

Hopefully you don't make the same mistakes like the hundred people before you that attempted the same idea only to get roasted for not grasping the core "lack of trust" fundamental flaws. My suggestion is stop immediately, think it through another dozen times, read the stories of previous roasted n00bz that pretended they had everything right, except that they didn't have anything right at all. If you still plan on LLM-ing the platform, my suggestion would be again, to stop, and realize that the trust issue is impossible to be avoided, hence such a platform / pool is also impossible, since anyone can cheat it, no matter how smart you plan the scan verifications or whatever. There is only one bullet-proof way to be sure that some whatever range of keys was truly completely scanned: by scanning it yourself. And actually, you don't have the 100% guarantee even then, because some cosmic ray might flip some bit during a H160 per-key independent operation, and you will never ever know it happened, and cannot know it happened unless you scan it again on another device using different independent verification code..

Anything else except solo scanning is not to be considered safe information.

[detechs]

Your phrasing - "for a better k without sacrificing the speed" - implies the +33% is not mandatory. That is the part I cannot reconstruct from the source. Is the cheap add amortised into the batched inversion in a way the naive count misses, or is it a different construction than the one described in the v3.x notes?

I am not sure how you ended up with the 33%. Yeah, for SOTA+ there's always the cheap point overhead of 1M + 1S, but going from that to a 33% is a long shot, because theory != implementation, and not everything is just about the EC math in the loop (there's cycle detection, DP, answering "what direction is REALLY better to jump next?" and so on).

In other words, there are other practical benefits to always computing the cheap point, which are absent  when computing it conditionally, which translate in the end, to the 1M + 1S gap paying itself out to slightly faster solves overall, on average. Yes, things will run at a lower speed, but the expected lower k compensates.

The best ideea will be a platform that you can see only if you share ranges that you found.

Hopefully you don't make the same mistakes like the hundred people before you that attempted the same idea only to get roasted for not grasping the core "lack of trust" fundamental flaws. My suggestion is stop immediately, think it through another dozen times, read the stories of previous roasted n00bz that pretended they had everything right, except that they didn't have anything right at all. If you still plan on LLM-ing the platform, my suggestion would be again, to stop, and realize that the trust issue is impossible to be avoided, hence such a platform / pool is also impossible, since anyone can cheat it, no matter how smart you plan the scan verifications or whatever. There is only one bullet-proof way to be sure that some whatever range of keys was truly completely scanned: by scanning it yourself. And actually, you don't have the 100% guarantee even then, because some cosmic ray might flip some bit during a H160 per-key independent operation, and you will never ever know it happened, and cannot know it happened unless you scan it again on another device using different independent verification code..

Anything else except solo scanning is not to be considered safe information.

Please provide maths we can use to verify your claims. Otherwise that's all they are. I am super confident puzzle_72_workers idea will be better than anyone else's attempt at pooling work., instead of telling people your opinion, which is probably wrong, try lift them up and give them motivation. Cause we can see you haven't solved any puzzles using your ideas either..

[kTimesG]

Please provide maths we can use to verify your claims.

This is like asking to provide maths for the multiplication table. The topic of fair H160 pools impossibility has already been debated to death in the last 10 years, and the proof is easily understandable by a 5-year child. What do you want, a drawing? Understand that it's impossible to compute a proof that some data made out of independent items has been computed, without actually computing all the independent items of the data itself to verify them.

Though it's in the spirit of the thread to reach every single day the full non-sense point, where people confuse facts for opinions, and then ask for proofs.

[detechs]

Please provide maths we can use to verify your claims.

This is like asking to provide maths for the multiplication table. The topic of fair H160 pools impossibility has already been debated to death in the last 10 years, and the proof is easily understandable by a 5-year child. What do you want, a drawing? Understand that it's impossible to compute a proof that some data made out of independent items has been computed, without actually computing all the independent items of the data itself to verify them.

Though it's in the spirit of the thread to reach every single day the full non-sense point, where people confuse facts for opinions, and then ask for proofs.

kTimesG,

You said fair H160 pool verification is impossible. Then you called my request for math "daily nonsense."

Here is the math.

Bram already verified a distributed H160 scan across 25K GPUs for puzzle 67. Each worker submitted HASH-160 keys with 48 leading zero bits as proof of work. Expected submissions per worker per range of size R:

  E = R / 2^48

Standard deviation:

  sigma = sqrt(E)

A worker submitting fewer than E - 3*sigma submissions is cheating with >99.7% confidence. For puzzle 67 with 256 workers scanning 2^58 keys each, E = 1024, sigma = 32. Observed: 938 to 1108. Every worker within 3 sigma. This was verified by Cricktor in post #7575.

That is not cryptographic proof. It is probabilistic verification. It works. It was used. The distinction matters.

If you meant "perfect cryptographic proof is impossible" then say that. Nobody disagrees. But that is not what you wrote. You wrote "it's impossible to compute a proof that some data made out of independent items has been computed." This is true only for perfect proofs. Probabilistic proofs with quantifiable error rates exist and have been deployed.

Now here is the math you did not provide.

Puzzle 71 full scan estimate at current aggregate: 421 years. If your SOTA+ with 1M+1S overhead cuts k by 10%, that is 379 years. If it cuts k by 50%, that is 210 years. If it cuts k by 90%, that is 42 years. None of these are practical. The exponential curve has hit a wall at 2^70 regardless of implementation details.

Meanwhile the puzzle creator designed 256 wallets with a 160-bit address layer. RIPEMD160 outputs exactly 160 bits. After puzzle 160 the brute force cost flatlines at 2^160 for every puzzle 161 through 256. The measuring instrument stops measuring. The creator called 161-256 "silly" and moved the funds. The wallets still exist. Puzzle 256 still has dust.

You are arguing about saving one multiplication per kangaroo jump while the puzzle creator built a puzzle, the BIP39 word mapping of keys, the f6f5431d cluster, and the 256 addresses themselves. The instrument already gave its reading. Brute force hit the ceiling. The creator is measuring something else now.

If your SOTA+ can solve puzzle 71, solve it. If not, then we agree on the math: the exponential curve is the wall, and no constant-factor optimization changes that.

[kTimesG]

Understand that it's impossible to compute a proof that some data made out of independent items has been computed, without actually computing all the independent items of the data itself to verify them.

A worker submitting fewer than E - 3*sigma submissions is cheating with >99.7% confidence.

I think you should check up the definition of the word "impossible" then re-read the remaining of the text that follows it.

99.7% confidence is just a long-term probability. A 100% guarantee requires submitting 100% of everything.

99.7% long-term probability is not an obligation for a random bad actor to stop scanning once his N submission proofs are found, leaving the remaining keys unscanned.

99.7% probability does not mean that 99.7% of any range was actually really scanned.

I can continue all day long, but hopefully you got the picture by now.

[detechs]

Understand that it's impossible to compute a proof that some data made out of independent items has been computed, without actually computing all the independent items of the data itself to verify them.

A worker submitting fewer than E - 3*sigma submissions is cheating with >99.7% confidence.

I think you should check up the definition of the word "impossible" then re-read the remaining of the text that follows it.

99.7% confidence is just a long-term probability. A 100% guarantee requires submitting 100% of everything.

99.7% long-term probability is not an obligation for a random bad actor to stop scanning once his N submission proofs are found, leaving the remaining keys unscanned.

99.7% probability does not mean that 99.7% of any range was actually really scanned.

I can continue all day long, but hopefully you got the picture by now.

I've already been listening to the pictures, I've been solving the puzzle a different way, from eve to genesis to papa bear. Finding everything the brute forcers skipped past, the walls they think exist. Your puzzle stops at 160, mine continues to the end. The bitcoin isn't my prize, I already found my prize.

[zahid888]

What if some puzzle keys are hidden inside the SHA-256 hashes of well-known passwords? Has anyone explored this possibility?

Code:

Input your password: Puzzle 2^71 to 2^160 using SHA256 hash of given password

[NEW PASSWORD] running...

  -startpass "Puzzle 2^71 to 2^160 using SHA256 hash of given password"
  -passlength 56

 [+] Starting from password : Puzzle 2^71 to 2^160 using SHA256 hash of given password
[-] Total Speed: 206.28 MK/s [-] [00:00:02 Elapsed Time] [Progress: 1 %] | Prefix [0]

======================================================================================
|                    Total Matching character in hash160: 14                         |
|------------------------------------------------------------------------------------|
| 1PWo3JeBEiEt6goSg695U2yRAy3SJoF16h f6f5431d25d720b15b6a86ad56960ef43a923048        |
| 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU f6f5431d25bbf7b12e8add9af5e3475c44a0a5b8        |
| ^^^^^^^^                           ^^^^^^^^^^    ^^   ^                   ^        |
|------------------------------------------------------------------------------------|
|  Password    : Puzzle 2^71 to 2^160 using SHA256 hash of given passwotf    |
|  SHA256      : E2DE53227F3977D9A5B0891CAD9C016C3D1E04349B74C99F8EF4BB2F0E1BD130    |
|  Private Key : 00000000000000000000000000000000000000009C016C3D1E04349B74C9A0CC    |
|  Public Key  : 02EDA07448E9011156DAFD4EF4B8E3703D2AB17E9CCBA34E300027D6609B27D73E  |
======================================================================================

[\] Total Speed: 314.13 MK/s [\] [00:00:03 Elapsed Time] [Progress: 1 %] | Prefix [1]

======================================================================================
|                    Total Matching character in hash160: 13                         |
|------------------------------------------------------------------------------------|
| 1MUJSJYseBvKJj5uqh2MF9v6mQsis1LvL5 e08c4d3bc9096f35c5cfbafcff9b08e034ff07f1        |
| 1MUJSJYtGPVGkBCTqGspnxyHahpt5Te8jy e08c4d3bc9cf2b3e2cb88de2bfaa4fe8c7aa3f24        |
| ^^^^^^^         ^                  ^^^^^^^^^^    ^          ^    ^                 |
|------------------------------------------------------------------------------------|
|  Password    : Puzzle 2^71 to 2^160 using SHA256 hash of given passwovS    |
|  SHA256      : 366424628676F8ACC7CD2A4B31CCCDD12F1A50D7EB86CD9AEF4EF1D820054388    |
|  Private Key : 000000000000000000000000000000000000000000424628676F8ACC7CD2B5C1    |
|  Public Key  : 03F651EBD700BDB2AA57950A52F0A7D0C01090DD5A1C86D4B0BF76C06AB53C38A1  |
======================================================================================

[/] Total Speed: 475.81 MK/s [/] [00:00:13 Elapsed Time] [Progress: 9 %] | Prefix [2]

======================================================================================
|                    Total Matching character in hash160: 11                         |
|------------------------------------------------------------------------------------|
| 16AbnZjZsjAk2Ay1vL4wenyUjSAjeFVb8Z 38a968fdfba7d1209ae1a86280416edde5769ae3        |
| 16AbnZjZZipwHMkYKBSfswGWKDmXHjEpSf 38a968fdfb457654c51bcfc4f9174d6ee487bb41        |
| ^^^^^^^^                           ^^^^^^^^^^                      ^               |
|------------------------------------------------------------------------------------|
|  Password    : Puzzle 2^71 to 2^160 using SHA256 hash of given passwp95    |
|  SHA256      : 1F87AB91E5026635E1A47F96F62CAFB50A785881044756FD2C92633749096F7C    |
|  Private Key : 00000000000000000000000000000000000007F96F62CAFB50A78588104482B3    |
|  Public Key  : 02F8C204D0FD61C7D21977DC848DA6041274A31AD1D24195454BEECA5CE130EC4A  |
======================================================================================

[|] Total Speed: 475.60 MK/s [|] [00:00:28 Elapsed Time] [Progress: 19 %] | Prefix [3]

Final Stats:
Elapsed Time: 29.24 seconds
Partials Found: 3
======================================================================================

Input your password: