Five Old Blockchain.info Wallets Inaccessible: Non-Standard Recovery Phrases Beyond Recovery Tools
IndeterminateCustodial platform became inaccessible — whether funds were recovered is not documented.
In July 2020, forum user gbola reported discovering five old Blockchain.info recovery phrases originating from approximately 2014, when the user's family were early Bitcoin adopters. The user had retained only the recovery phrases after deleting wallet credentials (wallet IDs and passwords). The fundamental problem: these phrases do not conform to BIP39 standards. They contain non-standard words absent from the official BIP39 word list and use variable lengths (14, 17, or 19 words) rather than the standard 12 or 24 words.
Crucially, early Blockchain.info recovery phrases functioned as account recovery codes—mechanisms to decrypt and restore wallet IDs and passwords—not as direct key derivation material. They bore no relationship to the private keys themselves, making them incompatible with modern wallet recovery tools. The user attempted recovery through two official channels: the modern BIP39 recovery endpoint (https://login.blockchain.com/#/recover), which rejected the input as invalid, and the legacy recovery endpoint (https://login.blockchain.com/wallet/recover-wallet), which rejected the input due to invalid checksum and non-standard vocabulary.
Blockchain.info provided no backup export service in 2014—no wallet.dat or aes.json downloads were available—and did not require email attachment to accounts, eliminating a potential recovery vector. Blockchain.info support did not respond to recovery requests. Community experts including pooya87, o_e_l_e_o, and Lucius confirmed that recovery required either direct Blockchain.info developer intervention, access to a historical aes.json file the platform may have emailed in early years, or control of the original email account if one was later associated. The exact Bitcoin holdings remain unknown. As of July 4, 2020, the outcome was indeterminate, with practical acceptance of loss the likely scenario absent institutional support.
| Stress condition | Vendor lockout |
| Custody system | Exchange custody |
| Outcome | Indeterminate |
| Documentation | Partial |
| Year observed | 2020 |
Why custodial Bitcoin fails differently than self-custody
Exchange custody transfers the custody problem from the holder to the institution. The holder no longer needs to manage seed phrases, maintain hardware, or understand cryptographic concepts. They need only to maintain their account. This simplicity has a cost: the holder no longer controls the private keys. Access depends entirely on the continued operational, financial, and regulatory health of the exchange.
Cases in this archive show that exchange failures cluster around specific event types: bankruptcy and insolvency, regulatory seizure, geographic sanctions, and account-level access failures (lost 2FA, forgotten email credentials). Each event type has a different recovery path and a different timeline. Bankruptcy proceedings typically take 6-24 months and produce partial recovery. Regulatory seizure timelines depend on legal process. Account access failures may be resolvable through platform support or may not.
The distinguishing feature of vendor lockout cases is that recovery — when it occurs — happens through processes the holder did not design and cannot control. They become claimants in a process rather than holders of an asset.
The primary protection against vendor lockout is not using a vendor for custody beyond what is needed operationally. Holdings intended to be stored long-term are most exposed to institutional risk. Exchange custody is well-suited for active trading and conversion; it is poorly suited for long-term storage of significant value. Moving Bitcoin off exchange into self-custody eliminates platform dependency at the cost of taking on personal custody responsibility.
Translate