Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
FKamil5711
on 06/01/2025, 06:08:57 UTC
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.