MultiBit USB Wallet: 1 BTC Unspendable After Metadata Loss During Data Recovery
BlockedHardware device was lost or destroyed, and no independent seed phrase backup existed.
A Bitcoin user created a new address in MultiBit version 0.5.18, a desktop software wallet popular in the early-to-mid 2010s, and transferred 1 BTC to it. The wallet files were stored on a USB drive encrypted using OS X FileVault, Apple's built-in full-disk encryption. The drive became inaccessible at some point thereafter.
When the user attempted recovery, they employed data recovery tools to extract files from the damaged or inaccessible drive. The recovery process succeeded in retrieving file content, but the recovered files arrived without directory structure or original filenames—metadata essential to identifying wallet files had been stripped away.
The user retained the OS X FileVault password used to encrypt the USB drive, expecting this to be sufficient for recovery. They attempted to decrypt the recovered files using OpenSSL with the known password, but the operation failed repeatedly with "bad magic number" errors. This indicated either corruption of the files during recovery, incompatibility between the recovery tool's output format and OpenSSL's expected FileVault format, or fundamental damage to encryption metadata that FileVault requires to initialize decryption.
The 1 BTC remained visible and unspent on the blockchain at the address to which it had been sent—a permanent public record of inaccessibility. Without the private key corresponding to that address, the funds were effectively unspendable. The user offered a 20% recovery bounty to anyone who could decrypt the files and restore access, indicating both the value at stake and the genuine technical impasse.
This case illustrates a critical failure mode in early software wallet practices: reliance on filesystem-level encryption rather than wallet-internal key derivation. MultiBit's design meant that loss of filesystem metadata rendered the encryption password—the only remaining secret—insufficient for recovery.
| Stress condition | Device loss |
| Custody system | Software wallet |
| Outcome | Blocked |
| Documentation | Partial |
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