Looking for “Stone Man” — Bitcointalk user from August 2010

Looking for “Stone Man” — Bitcointalk user from
August 2010
TL;DR: I’ve spent the past 18 months analyzing the change-address bug in Bitcoin 0.3.2 that caused the loss of 8,900 BTC by Bitcointalk user #288 (“Stone Man”) on August 9, 2010. I believe these coins can be recovered if the original owner can be found and is willing to share a few technical details. The coins remain his — I’m not asking for anything except to help return them.
Background
On August 9, 2010, a forum user posted about losing 8,900 BTC due to the notorious
“change-address bug” in the Bitcoin 0.3.2 wallet. He had restored an older wallet.dat and
made a 1 BTC self-send; the change went to a newly-generated address whose private key was lost when his Live USB system was rebooted. The transaction is on-chain:
Tx: eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf
Block 73272, August 9, 2010, 21:35:11 UTC
Output[1]: 8,899 BTC → 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg (unspent for 15+ years)
The user’s last message ended with “gone for good” and he never returned to the forum.
What I’ve found
The wallet’s private-key generation in this environment depends on a chain of weak entropy
sources I’ve been able to model in detail:
Linux 2.6.26 kernel seed)
random.c boot-time pool seeding (Live USB, no persistent random-
OpenSSL 0.9.8g-15 (Debian Lenny patched) md_rand state machine, bit-for-bit
Bitcoin 0.3.2’s RAND_add and RAND_bytes call sequence in CreateTransaction
I’ve built a CUDA implementation that searches the parameter space at ~2M keys/sec on a single laptop GPU. Without specific hardware/timing information from the original user, the
search space is too large (~10^16 to 10^22). With his cooperation — confirming utsname, hardware, boot timing, network state, and a few session details — the search space shrinks by roughly 10 orders of magnitude. With his old wallet.dat (or the sender address private key alone), the search becomes nearly instantaneous:
minutes on a laptop.
The key reason cooperation is so leveraged: the same PRNG state that produced the change-address private key also produced the ECDSA signing nonce used in the transaction. If the sender’s private key is known (it’s in his old wallet.dat anyway), the nonce
can be derived from the on-chain signature, providing a powerful verification channel that eliminates the most expensive part of the search.
Why I’m doing this
I have no claim on these coins. They belong to the original user. My goal is to return them. If a small thank-you is offered after a successful recovery, I’d accept — but it’s not a condition.
What I need
Just to talk. If you are this person, or you know who is, please reach out.
I can run the entire recovery on your computer using your wallet.dat without it ever leaving your hands. You don’t need to trust me with anything sensitive — only confirm a few
non-sensitive details about the original setup.
Verification
To filter out impersonators, real correspondence will include questions that only the original
user would know. Please reach out via:
reply to this thread / DM.
This is a serious 18-month research effort. Happy to share the technical write-up with anyone qualified to evaluate it, including security researchers who can vouch for the
methodology. The full analysis (CUDA code, kernel/OpenSSL state machine modeling, blockchain forensics) is available on request.