The Stone Man case
Inside the Bitcoin Wallet Backup Problem That Lost 8,999 BTC
Stone Man followed advice to back up wallet.dat. One 1 BTC payment and a reboot revealed the flaw: the backup existed, but the key to the 8,999 BTC change output did not.
The blockchain never lost the coins.
The wallet lost the ability to spend those funds.
This distinction shifts the story from a faulty USB drive to wallet architecture. Early Bitcoin did not derive all future keys from one recoverable seed. A backup was merely a snapshot of keys present at the time.
Contents
The night of the loss
A careful backup, a 1 BTC payment to himself, and a restart with lasting consequences
Stone Man had amassed 9,000 BTC and loaded them into a Bitcoin client running from a Debian live CD. The live system ran in memory, so shutting down would erase the active wallet. He first copied wallet.dat to a flash drive.
- 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 transfers roughly 1 BTC to his own wallet
While waiting for another payment to confirm, Stone Man sends roughly 1 BTC to his own wallet. The transaction spends the entire 9,000 BTC output and quietly creates a new change key for the balance.
- 03
Erase
The live system shuts down
The in-memory wallet holding the new change key vanishes before the backup is updated.
- 04
Restore
The old backup returns
The blockchain records the transaction, but the restored wallet cannot spend the 8,999 BTC change output.
“I never imagined it could jeopardise my entire balance.”
What the forum tells us about Stone Man
Who was the user called Stone Man?
Stone Man's identity is still unknown. His BitcoinTalk account was number 288. He said he had bought 9,000 BTC over time, ran Bitcoin from a Debian live CD, and copied wallet.dat before switching off the computer.
We do not know his real name, where he lived, what work he did, or what happened after the thread. Later claims about his identity have not been proved.
Looking for the missing key
The search for the key started in 2010
Shortly after Stone Man requested assistance, another user volunteered to examine the old wallet. Insti then reconstructed the transaction using early Bitcoin tools developed by Gavin Andresen. For recovery to succeed, the saved wallet.dat needed to include the private key for the change address. The 2010 review indicated this was unlikely. Without that key, the blockchain could reveal the coins' location, but no one could spend them.
The first search for the key
Forum users checked both outputs, asked Stone Man to list the keys in his wallet, and found the missing change address. They explained the loss but could not find the key.
Another 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 address. They said details from Stone Man and his old wallet could narrow the search.
The transaction analysis
Why sending 1 BTC moved all 9,000 BTC
Bitcoin spends transaction outputs as whole units. Stone Man's wallet used one 9,000 BTC output, sent 1 BTC to his chosen address, and created a second output for the remaining 8,999 BTC. That second output was change, not a theft.
eb5b761c7380ed4c6adf688f9e5ab94953dcabeda47d9eeabd77261902fccccf167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHgThe hidden failure
wallet.dat was a snapshot, not a guarantee of future keys
The original Bitcoin wallet stored independently generated private keys. When a new change address was needed, it generated a fresh key after the backup. Restoring the older file restored old keys but could not recreate later random keys.
A blockchain rescan might rediscover the transaction and reveal where the 8,999 BTC went, but it cannot recreate the missing private key. Seeing is not controlling.
The warning came first
Stone Man was not the first caught out by change
On 14 July 2010, nearly a month before Stone Man's post, another user reported a similar failure on a smaller scale. They backed up a wallet with 1.21 BTC, donated 0.01 BTC, restored the old file, and saw the balance drop to zero.
By 21 July, users warned that an old backup might include the spent key but not the newly generated change key. The risk was known before 8,999 BTC made it unforgettable.
How Bitcoin evolved
From loose keys to a keypool, then to deterministic wallets
The solution did not come as a single fix. Bitcoin first introduced a safety buffer of future keys. Later wallet designs allowed entire key families to be recovered from one root seed.
-
Failure observed
A 1.20 BTC alert
A user restored an old wallet after a 0.01 BTC donation and lost access to the newly created change output.
-
Proposed design
Satoshi describes a queue of future keys
Pre-generated addresses allowed backups to include keys the wallet had not yet used.
-
Failure exacerbated
Stone Man loses the 8,999 BTC change key
This architectural weakness became impossible for the community to overlook.
-
Safety buffer implemented
Bitcoin 0.3.13.3 introduces a keypool
A default pool of 100 pre-generated keys offers backups a limited future coverage window.
-
Deterministic standard
BIP 32 defines a hierarchical tree of keys from a single seed
Wallets can derive future receiving and change keys from a recoverable root rather than storing unrelated random keys alone.
-
HD wallets by default
Bitcoin Core adopts deterministic key derivation
For newly created HD wallets, a single correct seed-backed backup can regenerate all derived keys.
103849419a9c014a69c76b6f96e48b66cbc838ca
The commit altered transaction creation to reserve change keys from a default pool of 100 pre-generated keys, rather than generating keys only during transaction building.
What this means today
Modern seeds altered recovery but did not eliminate the need for backups
Hierarchical deterministic wallets generate many keys from one seed, so Stone Man's exact failure should not happen if the correct seed and derivation info are restored. Bitcoin Core introduced HD wallets in version 0.13. However, imported keys, old non-HD wallets, unknown derivation paths, lost passphrases, damaged backups, and untested recovery methods can still cause lost funds.
Understand the type of backup you possess
Seed phrases, descriptor exports, wallet.dat files, hardware wallet backups, and imported private keys each restore differently.
Test recovery without transferring real funds
Verify the restored wallet derives expected receiving and change addresses before an emergency forces guesswork.
Treat imported keys as a distinct risk
Keys imported after the original seed or backup may require separate export and may not always be recoverable from the recovery phrase.
Migrate valuable legacy wallets with care
Create a new wallet from fresh recovery data, verify its backup, send a small test amount, then transfer the remaining balance.
The enduring lesson
A backup is only as comprehensive as the underlying key model
Stone Man's loss was not a cryptographic failure nor an unknown attacker draining the wallet. It was a recovery design flaw revealed by a routine transaction. The network kept the ledger intact; the old backup preserved the wrong state.
Primary sources and verification
Follow the forum discussion, transaction, and code
The historical claims above were verified against contemporary BitcoinTalk posts, the public transaction record, the original keypool commit, BIP 32, and current Bitcoin Core wallet documentation.
FAQs
Did Stone Man truly 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 the private key for the 8,999 BTC change address was missing from the restored backup, and the address had not spent any outputs when verified.
Why did Stone Man's wallet.dat backup fail to recover the coins?
The backup was made before the wallet generated the private key for the new change address. Early non-deterministic wallets could not regenerate that later random key from older keys or the blockchain.
Was the 8,999 BTC output a hack or a payment to an attacker?
No attacker is needed to explain the transaction. The 8,999 BTC was change from Stone Man's 1 BTC self-payment. The failure was losing the private key required to spend that change.
Can this wallet backup issue occur with a modern seed phrase?
A properly restored deterministic wallet can generate its expected receiving and change keys from the correct seed. Recovery may still fail if the seed is incorrect or incomplete, the derivation method is unknown, keys were imported separately, a passphrase is missing, or the backup was never tested.
What happened to Stone Man after the forum thread?
Stone Man asked the forum for help, confirmed that he still had the old wallet file, and answered technical questions. He later stopped posting. We do not know why, or whether he continued looking for the key privately.