Armory Cold Wallet Restoration Created Unencrypted Wallet With Plaintext Private Keys
IndeterminateHardware device was lost or destroyed — whether access was recovered is not documented.
KillerTank maintained Bitcoin in offline cold storage on an air-gapped Raspberry Pi with an 18-word paper backup consisting of 4 random letters per set. In December 2017, the USB micro connector on the Raspberry Pi became physically damaged, rendering the device unusable. Rather than attempt immediate repair, the user opted to restore the wallet on a new Windows machine using the paper backup, expecting to regain access to the funds and claim Bitcoin Cash forked from the same private keys.
The wallet restoration appeared successful: the correct Bitcoin balance displayed on the dashboard, and the interface showed an encrypted wallet state. However, critical problems emerged during operational testing. When attempting to unlock the wallet to view private keys for the Bitcoin Cash claim, the system rejected the passphrase despite the user's confidence in its accuracy—they reported using the same mnemonic passphrase for this wallet for years. Separately, attempts to send Bitcoin generated a 'cannot connect to socket' error rather than a passphrase prompt, suggesting the wallet was not functioning as expected.
Armory lead developer goatpig clarified the root cause: the paper backup itself is unencrypted, containing only the seed data. When restoring from paper without explicitly setting a new password during the restoration process, Armory creates an unencrypted wallet with plaintext private keys—a critical security failure masked by the dashboard's encrypted-wallet display. The developer immediately advised moving all coins off the compromised wallet. KillerTank attempted to re-import the backup using Armory's merge function as documented in official restoration videos, but reported no result. The user ultimately decided to attempt resoldering the original Raspberry Pi's USB connector as potentially simpler than resolving the Armory restoration issue. The device was located in an area without internet service, limiting exposure during troubleshooting. The incident remained unresolved in the forum thread, and the final Bitcoin amount was never disclosed.
| Stress condition | Device loss |
| Custody system | Hardware wallet (single key) |
| Outcome | Indeterminate |
| Documentation | Present but ambiguous |
| Year observed | 2017 |
| Country | unknown |
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