BIP 39

Alice creates a wallet that uses BIP39 and safely records its recovery words as instructed. Later, her phone breaks. Her bitcoin has not disappeared from the network; she has lost the device that held the keys for signing her payments. On a trusted replacement device, she can use the recovery option in a compatible wallet. The same words in the same order, together with the same passphrase if she used one, produce the same seed. Further procedures recreate the required private keys from that seed, and the wallet finds the payments on the Bitcoin network. This is not an account login whose password a support team can reset. If Alice used a passphrase, she needs it too; her old phone's PIN is no substitute. A zero balance after recovery does not necessarily mean the coins are gone: as well as the words and passphrase, the correct account and recovery settings need checking. That is why it pays to verify the whole process before storing a larger amount. [1] [5] [13] [14]

Words are easier for people to copy and check than a long representation of computer data. Marek Palatinus, Pavol Rusnak, Aaron Voisine and Sean Bowe designed a way to turn computer-generated randomness into a form suitable for copying by hand. The proposal is dated 10 September 2013 and is marked Deployed in the specification. The words must come from a high-quality random input; you should not invent them from a favourite sentence. That would create a Brainwallet with a predictable human-chosen secret. Bitcoin nodes do not check BIP39: they validate transactions and blocks, not the method the wallet used to create its keys. [1]

A good written record only helps if you can use it to recover the wallet. Before storing significant funds, verify the recovery procedure recommended by the manufacturer on a trusted device. Alongside the exact word order, preserve the required passphrase, wallet information and any derivation or signing configuration. In an ordinary single-signature wallet, someone with the complete backup and the required passphrase can derive the keys without the original device. For Multisig, any additional key requirements and signing rules still need to be met. Photos, cloud copies, printers or clipboard history can expose secrets to other people and services. Paper and metal have different physical limitations; no material alone prevents theft. [9] [13] [14]

For compatibility, BIP39 strongly recommends the English wordlist: many wallets do not support other lists. Translating a backup does not preserve the original wallet because the sentence itself is used in derivation. Other systems also require care. Electrum uses its own versioning procedure for native backups; similar-looking words do not automatically make them BIP39. SLIP39 is a different format with its own list of 1,024 words and rules for how many shares are needed for recovery. It is not simply a BIP39 backup cut into pieces. Dividing 24 words among several envelopes does not create Shamir Secret Sharing and may weaken both protection and recoverability. You always need to know the actual backup format. [1] [11] [12]

The starting point is entropy: random data of length ENT = 128, 160, 192, 224 or 256 bits. A checksum is added: the first CS = ENT/32 bits of the SHA-256 result for the original data. The combined data is divided into groups of 11 bits, each selecting one word. The relation MS = (ENT+CS)/11 therefore gives exactly 12, 15, 18, 21 or 24 words. Twelve words represent 128 bits of randomness and 4 checksum bits; the full 132 bits are therefore not independent secret material. For 24 words, the split is 256+8 bits. Trust in a backup begins with the randomness generator, not with how unusual the words look. [1]

Each 11-bit group selects an item from an ordered list of 2,048 words. The first word is therefore not the first private key: together, all the words encode the original data and its checksum. In the English list, the first four letters are enough to distinguish the words. This is not a general rule for every language or permission to shorten a backup arbitrarily during recovery. Changing the order, substituting a synonym or translating the words changes the input data. Sometimes this produces an invalid checksum, sometimes another valid backup; both the wording and the order must therefore be preserved exactly. [1] [2]

A computer needs to know which characters it actually received. BIP39 specifies Unicode NFKD normalization followed by UTF-8 encoding for both the recovery sentence and the passphrase. NFKD makes some differently written characters equivalent, for example by decomposing certain accented letters. Two different written forms may therefore produce the same result after normalization; visual similarity alone does not guarantee this. Word order, spaces and passphrase characters still matter. A different normalization procedure may derive a different seed during recovery. The reference implementation and public test vectors help check that a program follows the specified procedure. [1] [3] [4]

PBKDF2 receives two separate inputs. The password input consists of the actual recovery words. The second input is called the salt, additional data used in the cryptographic calculation. Here, it is the literal text “mnemonic”, immediately followed by the passphrase, with no separator. The recovery words themselves are not inserted again here. Both inputs are normalized using NFKD and encoded in UTF-8. BIP39 specifies HMAC-SHA512, 2,048 iterations and an output of 512 bits, or 64 bytes. Without a passphrase, the salt remains “mnemonic”; only the passphrase is empty. The calculation does not decrypt the words or create new independent randomness. If the words are exposed, the iterations alone will therefore not protect an easily guessed passphrase. [1] [10]

BIP39 ends with a 64-byte seed. Another standard, BIP32, usually uses HMAC-SHA512 with the fixed key “Bitcoin seed” to derive a master private key and a 32-byte chain code from it. The chain code is additional data used together with a key to derive further keys. These two values are the starting point for the tree of keys. Rules such as BIP44, BIP49, BIP84 and BIP86 specify different derivation paths and script types. During recovery, you may enter the correct words and passphrase yet see a zero balance if the program looks for a different account, branch or address type. The gap limit also matters: it is the number of consecutive unused addresses the program allows for during its search. The name of the original wallet, account details, derivation paths or an Output Descriptor can supply information that the words alone do not contain. [5] [6] [7] [8] [9] [14]

A passphrase is an additional secret input to seed derivation. It is not the device PIN, and BIP39 cannot tell you that you entered the wrong one: it calculates a result for another value too. A typo that changes the normalized input generally leads to a different wallet where you will not see your funds. Different written forms with the same NFKD result, on the other hand, derive the same seed. Anyone who obtains the recovery words and information that identifies the intended wallet can try passphrase candidates offline. If you use a passphrase, it needs sufficient strength, a trusted way to enter it and a reliable backup of its own. Separate storage should reduce the risk of both secrets being stolen together; it should not turn the passphrase into a secret that disappears with you. [1] [13]

The checksum helps catch typing errors, but it does not prove who owns a backup or whether it was created safely. It has 4 bits for 12 words and 8 bits for 24 words. A uniformly random sequence of words from the given list therefore passes the check with probability 1/16 or 1/256, respectively. Many errors are caught, but not all; the checksum does not fix them either. An attacker can construct another backup with a valid checksum. The specification requires a warning when the checksum does not match and distinguishes checking the words from deriving the seed itself. An invalid checksum should therefore be investigated using the original wallet and its format, not by entering a real backup into an online checker. [1]