The Stone Man case
Inside the Bitcoin Wallet Backup Problem That Lost 8,999 BTC
Stone Man did what careful users were told to do: back up wallet.dat. Then one 1 BTC payment and one reboot exposed the flaw. The backup existed. The key to the 8,999 BTC change output did not.
The blockchain never lost the coins.
The wallet lost the ability to spend them.
That distinction turns this from a story about a bad USB drive into a story about wallet architecture. Early Bitcoin did not derive every future key from one recoverable seed. A backup was only a snapshot of the keys that existed when it was copied.
Table of Content
The night of the loss
A careful backup, a 1 BTC self-payment, and one restart with lasting consequences
Stone Man had accumulated 9,000 BTC and moved them into a Bitcoin client running from a Debian live CD. The live system lived in memory, so shutting it down would erase the active wallet. He copied wallet.dat to a flash drive first.
- 01
Protect
The wallet is backed up
The 9,000 BTC wallet.dat is copied from the live system to a flash drive.
- 02
Self-payment
Stone Man sends about 1 BTC to himself
While checking when another payment would confirm, Stone Man sends about 1 BTC to himself. The wallet spends the full 9,000 BTC output and quietly creates a new change key for the remainder.
- 03
Erase
The live system shuts down
The in-memory wallet containing the new change key disappears before the backup is refreshed.
- 04
Restore
The old backup returns
The blockchain shows the transaction, but the restored wallet cannot spend the 8,999 BTC change output.
“I never dreamed it could compromise my whole balance.”
What we know about Stone Man
Who was Stone Man?
Stone Man's real identity is unknown. His BitcoinTalk profile was account 288. In the forum, he said he had bought 9,000 BTC over time, used Bitcoin on a Debian live CD, and saved a copy of wallet.dat before shutting the computer down.
We do not know his real name, where he lived, what he did for work, or what happened after the thread. Later claims about his identity have not been proven.
Searching for the missing key
People started looking for the key in 2010
Minutes after Stone Man asked for help, another user offered to check the old wallet. Insti then rebuilt the transaction with early Bitcoin tools from Gavin Andresen. A successful recovery required the saved wallet.dat to contain the private key for the change address. The 2010 analysis suggested that it probably did not. Without that key, the blockchain could show where the coins were, but no one could move them.
The first attempt to recover the key
Forum users followed both transaction outputs, asked Stone Man to list the keys in his wallet, and found the missing change address. They could explain the loss, but they could not recover the key.
A new search in 2026
In 2026, an anonymous forum user said they had tested more than 6.5 million possible keys with a GPU. None matched the missing address. They said they would need details from Stone Man and his old wallet to make the search smaller.
The transaction autopsy
Why sending 1 BTC moved all 9,000 BTC
Bitcoin spends transaction outputs as whole units. Stone Man's wallet consumed one 9,000 BTC output, returned 1 BTC to the address he chose, and created a second output for the remaining 8,999 BTC. That second output was change, not a theft payment.
eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHgThe hidden failure
wallet.dat was a snapshot, not a promise about future keys
The original Bitcoin wallet stored independently generated private keys. When it needed a fresh change address, it could generate a fresh key after the backup had been made. Restoring the older file restored the old keys, but it could not recreate a later random key.
A blockchain rescan could rediscover the transaction. It could show where the 8,999 BTC went. It still could not manufacture the missing private key. Visibility is not control.
The warning came first
Stone Man was not the first person caught by change
On 14 July 2010, almost a month before Stone Man's post, another user described the same shape of failure on a smaller scale. They backed up a wallet holding 1.21 BTC, donated 0.01 BTC, restored the old file, and watched the balance fall to zero.
By 21 July, users were explicitly warning that an old backup might contain the spent key but not the newly generated change key. The danger was public before 8,999 BTC made it unforgettable.
How Bitcoin changed
From loose keys to a keypool, then to deterministic wallets
The response did not arrive as one perfect fix. Bitcoin first created a safety buffer of future keys. Later wallet designs made entire families of keys recoverable from one root seed.
-
Failure observed
A 1.20 BTC warning
A user restores an old wallet after a 0.01 BTC donation and loses access to the newly created change output.
-
Design proposed
Satoshi describes a queue of future keys
Pre-generated addresses would let a backup contain keys that the wallet had not used yet.
-
Failure amplified
Stone Man loses the 8,999 BTC change key
The same architectural weakness becomes impossible for the community to ignore.
-
Safety buffer shipped
Bitcoin 0.3.13.3 gains a keypool
A default pool of 100 pre-generated keys gives backups a limited window of future coverage.
-
Deterministic standard
BIP 32 defines a tree of keys from one seed
Wallets can derive future receiving and change keys from a recoverable root instead of storing unrelated random keys only.
-
HD by default
Bitcoin Core adopts deterministic key derivation
For newly created HD wallets, one correct seed-backed wallet backup can regenerate the wallet's derived keys.
103849419a9c014a69c76b6f96e48b66cbc838ca
The commit changed transaction creation to reserve change keys from a default pool of 100 pre-generated keys instead of generating the key only when the transaction was built.
What this means today
Modern seeds changed recovery, but they did not make backups optional
Hierarchical deterministic wallets derive many keys from one seed, so the exact Stone Man failure should not occur when the correct seed and derivation information are restored. Bitcoin Core introduced HD wallets in version 0.13. But imported keys, old non-HD wallets, unknown derivation paths, lost passphrases, damaged backups, and untested recovery procedures can still strand funds.
Know what kind of backup you have
A seed phrase, descriptor export, wallet.dat file, hardware-wallet backup, and imported private key do not restore in the same way.
Test recovery without moving real funds
Verify that the restored wallet derives expected receiving and change addresses before an emergency forces you to guess.
Treat imported keys as a separate risk
Keys imported after the original seed or backup may need their own export and cannot always be regenerated from the recovery phrase.
Migrate valuable legacy wallets carefully
Create a current wallet from fresh recovery material, verify its backup, send a small test amount, and only then move the remaining balance.
The lasting lesson
A backup is only as complete as the key model behind it
Stone Man's loss was not a break in Bitcoin's cryptography and not an unknown attacker draining a wallet. It was a recovery design failure made visible by an ordinary transaction. The network preserved the ledger perfectly; the old backup preserved the wrong moment in time.
Primary sources and verification
Follow the forum record, transaction, and code
The historical claims above were checked against contemporary BitcoinTalk posts, the public transaction record, the original keypool commit, BIP 32, and current Bitcoin Core wallet documentation.
FAQ
Did Stone Man really lose 8,999 BTC?
The public transaction spent one 9,000 BTC output and created outputs of 1 BTC and 8,999 BTC. Stone Man reported that the private key for the 8,999 BTC change address was absent from the restored backup, and the address had not spent any outputs when this article was verified.
Why did Stone Man's wallet.dat backup not recover the coins?
The backup was created before the wallet generated the private key for the new change address. Early non-deterministic wallets could not recreate that later random key from older keys or from the blockchain.
Was the 8,999 BTC output a hack or a payment to an attacker?
No attacker is required to explain the transaction. The 8,999 BTC was the change output from Stone Man's 1 BTC self-payment. The failure was losing the private key needed to spend that change.
Can the same wallet backup problem happen with a modern seed phrase?
A correctly restored deterministic wallet can derive its expected receiving and change keys from the right seed. Recovery can still fail if the seed is wrong or incomplete, the derivation setup is unknown, keys were imported separately, a passphrase is missing, or the backup was never tested.
Do we know what happened to Stone Man?
Stone Man asked the forum for help, said he still had the old wallet file, and answered technical questions. He later stopped posting. We do not know why or whether he continued trying to recover the key in private.