Wallet.dat Corruption: BerkeleyDB Environment LSN Mismatch After File Migration
BlockedHardware device was lost or destroyed, and no independent seed phrase backup existed.
A user attempted to restore an old wallet.dat file by placing it in their .bitcoin directory and running bitcoind. The wallet file itself appeared structurally intact, but the Bitcoin Core client immediately detected and flagged environment data corruption.
The error logs revealed a critical mismatch: the wallet.dat file contained references to log sequence numbers (LSNs) from a different database environment—specifically LSN 1/151495 when the current log only extended to LSN 1/28. This condition arose because the wallet had been moved from one machine or environment to another without clearing the associated BerkeleyDB log files. BerkeleyDB, the embedded database library used by Bitcoin Core at that time, maintains strict log consistency requirements; moving a database file without its corresponding log environment or clearing environment state causes the library to reject the file as corrupt.
When bitcoind attempted automatic salvage recovery, it failed to extract any usable records from the backup copy it created (wallet.dat.1560276842.bak), resulting in total access denial.
The user had no seed phrase backup, no alternative access method, and no way to export private keys. This case exemplifies a common failure mode in legacy Bitcoin Core self-custody: users who maintain only wallet.dat backups without understanding the file's environmental dependencies face complete loss when relocation or system migration occurs. Recovery would have required either restoring the original .
bitcoin directory structure intact, or maintaining a separate seed phrase or key export.
| Stress condition | Device loss |
| Custody system | Software wallet |
| Outcome | Blocked |
| Documentation | Partial |
| Year observed | 2019 |
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