Wallet.dat Recovery Failure After Premature Bitcoin-Qt Reinstall
BlockedHardware device was lost or destroyed, and no independent seed phrase backup existed.
In mid-2013, a Bitcoin user operating under the handle spoonbender encountered a custody access failure rooted in device loss and procedural error during recovery. The user possessed wallet.dat files on an aging computer but had not immediately secured them. Months later, when attempting to recover the Bitcoin, spoonbender made a critical sequencing mistake: reinstalling Bitcoin-Qt on the original machine before properly locating and restoring the wallet.dat backup from the Windows AppData folder. This premature reinstall generated a new empty wallet, overwriting the conditions necessary for successful recovery.
The user had created multiple physical backups of the wallet.dat file—one on desktop and one on flash drive—suggesting awareness of custody risk. However, when attempting to restore these backups by copying the 88KB wallet.dat file into the AppData folder on a new computer, Bitcoin-Qt failed to recognize or display any balance or addresses. The client showed only an empty wallet despite the recovered file being 8KB larger than a freshly-installed wallet (88KB versus 80KB), indicating retained data structure but inaccessible funds.
Spoonbender attempted recovery using the BtToMt tool without success. Following community advice, the user ran File Scavenger to locate deleted file versions, but recovered only the same 88KB file already in use. By November 2013, when posting the incident to the Bitcoin Forum, spoonbender concluded the Bitcoin was 'gone for good.' The exact amount of BTC involved was never disclosed. A parallel case emerged in the same thread when bitcoinminer11794591 described nearly suffering identical loss after deleting and reinstalling Multi-Bit but managed successful restoration, suggesting technical recovery was theoretically possible under correct sequencing. No follow-up posts from spoonbender indicated successful recovery.
| Stress condition | Device loss |
| Custody system | Software wallet |
| Outcome | Blocked |
| Documentation | Partial |
| Year observed | 2013 |
What determines whether device loss is permanent
When a device fails, burns, floods, or disappears, the Bitcoin remains on the blockchain, unchanged. What changes is whether any path to authorized access still exists. A seed phrase stored separately from the device preserves that path. A seed phrase stored with the device — or never recorded at all — eliminates it permanently.
The pattern observed across cases in this archive is consistent: recovery is possible when the seed phrase survived the event that took the device. It is not possible when it did not. The type of device, its cost, its brand, its security features — none of these factors determine the outcome. The seed phrase backup does.
Most device loss cases that result in permanent loss involve one of three failure modes: the seed phrase was never recorded at setup, the seed phrase was stored physically alongside the device and lost with it, or the seed phrase was stored in a location that became inaccessible during the same event (flood, fire, relocation). All three are detectable in advance. A backup test — confirming that the seed phrase can restore the wallet on a separate device — would have revealed the gap before the loss event.
A device loss case becomes unrecoverable the moment the backup path is also broken. The preventive action is simple in concept: record the seed phrase at setup, store it independently from the device, and test that it works. Most cases in this archive involved none of these three steps.
Translate