Non-Standard Recovery Phrase Recovery: Blockchain.info 2013 Wallet with Double Encryption
SurvivedNo documentation described the custody setup — but a recovery path was eventually found.
In June 2017, a user attempted to recover Bitcoin stored in a blockchain.info wallet opened in December 2013, approximately four years prior. Access to the account itself was successful, but the wallet containing the coins remained locked behind a private key requirement. The user possessed two recovery artifacts: multiple .
aes.json encrypted wallet files and a handwritten note containing two sets of words—one with 29 words and one with 13 words. Neither format aligned with the BIP39 standard of 12 or 24 words that had become dominant by 2017. No official blockchain.
info documentation existed for the 29-word recovery phrase format, leaving the user uncertain whether the phrases were authentic recovery seeds or alternative backup mechanisms. Initial attempts to import the .aes.json files using wallet-key-tool failed across multiple password candidates, suggesting either incorrect passwords or format incompatibility.
Unable to locate command-line tools for targeted brute-force decryption, the user adapted a third-party GitHub script designed for password dictionary attacks against AES-encrypted files. The wallet structure proved to be double-encrypted, requiring sequential decryption. After the first layer yielded to brute-force attack against a wordlist of several hundred thousand candidates, wallet-key-tool successfully processed the remaining encryption layer, granting access to the private key. The user confirmed successful recovery through a follow-up comment but did not disclose the final balance or provide technical specifics about the non-standard phrase format.
| Stress condition | Documentation absent |
| Custody system | Exchange custody |
| Outcome | Survived |
| Documentation | Partial |
| Year observed | 2017 |
What the absence of documentation actually removes
What documentation provides is a starting point. Without it, heirs face three unknowns before they face any access problem: does the Bitcoin exist, where is it held, and what is needed to access it. Most of this information cannot be reconstructed after the owner dies or becomes incapacitated. Educated guesses, blockchain searches, and device inventories occasionally locate wallets — but without credentials, finding the wallet does not help.
Cases in this archive where documentation was absent but recovery succeeded typically involved one of two factors: an exchange account where the heir knew the email address and could navigate the account recovery process, or a designated person who had been given credentials informally and could act. Self-custody without any documentation or designated knowledge-holder is consistently the worst combination.
The content of documentation matters as much as its existence. A note that says "my Bitcoin is in a hardware wallet in the safe" is better than nothing but insufficient. Effective documentation specifies: what type of wallet, where the seed phrase is stored, whether a passphrase exists and where it is documented, and any exchange accounts and the email addresses used. It should be tested — the executor should be able to confirm the information is accurate before it is needed.
Documentation does not need to expose credentials to be useful. A document that describes the custody structure, points to where credentials are stored, and names a person who has been briefed can be stored without security risk. The goal is not to put the seed phrase in a filing cabinet — it is to ensure the executor has a map, not a blank wall.