Corrupted Encrypted wallet.dat Recovered via Partition-Level Recovery
SurvivedHardware device was lost or destroyed — an independent backup existed and access was restored.
In March 2016, a Bitcoin Core user discovered their only backup of an encrypted wallet.dat file had become corrupted, likely due to improper shutdown of Bitcoin-Qt during the backup process. The file structure was partially intact — hex inspection revealed recognizable wallet structures including mkey and approximately 117 ckey entries — but both Bitcoin-Qt's built-in salvage function and the pywallet tool's standard wallet parsing failed with corruption errors. Initial recovery attempts using pywallet without special flags returned only file-open errors.
The user then discovered that pywallet included a dedicated recovery mode designed to scan raw storage devices for wallet fragments. They created a 1 GB FAT32 partition on a USB flash drive, copied the corrupted wallet.dat file to it, and invoked pywallet with the --recover flag, specifying the device path and partition size. The tool successfully scanned the filesystem, located and decrypted encrypted private keys, and identified change addresses containing the user's Bitcoin holdings.
This case illustrates a critical distinction: while Bitcoin Core's integrated salvage function operates on wallet file level, specialized recovery tools can operate at the partition and block level, reconstructing metadata from filesystem remnants. The technique was successful only because the encryption key material and key metadata remained present despite file corruption, and because a tool existed that could operate below the filesystem abstraction layer.
| Stress condition | Device loss |
| Custody system | Software wallet |
| Outcome | Survived |
| Documentation | Present and interpretable |
| Year observed | 2016 |
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