BIP 39

Marek Palatinus, Pavol Rusnak, Aaron Voisine and Sean Bowe authored BIP39; it was assigned on 10 September 2013 and is now marked Deployed. Its purpose is to carry computer-generated randomness in a form people can transcribe. The specification explicitly rejects turning a user-invented sentence into a wallet: a memorable quotation has human-scale entropy and is a brainwallet, even if every word appears in the official list. BIP39 is an application convention; nodes do not validate it and Bitcoin transactions contain no mnemonic. [BIP 39 — Mnemonic code for generating deterministic keys]

Let ENT be 128, 160, 192, 224 or 256 bits. BIP39 appends CS = ENT/32 leading bits of SHA256(entropy), then divides ENT+CS into 11-bit values; MS = (ENT+CS)/11 therefore yields exactly 12, 15, 18, 21 or 24 words. A 12-word sentence carries 128 entropy bits plus 4 checksum bits, not 132 bits of secret randomness; a 24-word sentence carries 256 plus 8. Security begins with the random-number generator that produced ENT, not with how obscure the resulting words sound. [BIP 39 — Mnemonic code for generating deterministic keys]

Each 11-bit value selects one entry from an ordered list of exactly 2,048 words. Words are a lossless display encoding of one bitstream: the first word is not one private key, and replacing a synonym changes several underlying bits. Official list design makes the first four letters sufficient to identify each word within that list and avoids confusing pairs. Order is cryptographic data. Sorting the words, translating them or reconstructing them from memory produces a different bitstream, usually an invalid checksum and sometimes another valid mnemonic. [BIP 39 — Mnemonic code for generating deterministic keys] [BIP 39 official wordlists]

The mnemonic and passphrase are encoded as UTF-8 and normalized with Unicode NFKD before seed derivation. That rule decomposes some accented or compatibility characters, so two strings that look similar in an interface are not safely assumed equivalent unless the implementation normalizes exactly as specified. Spaces, character case, word order and every passphrase character matter. The Japanese vectors deliberately exercise heavily normalized text. A recovery tool that silently applies another Unicode form can derive a valid but entirely different wallet. [BIP 39 — Mnemonic code for generating deterministic keys] [Trezor python-mnemonic reference implementation] [BIP 39 official test vectors]

The normalized mnemonic is PBKDF2's password; the salt is the ASCII prefix ‘mnemonic’ followed by the normalized passphrase. BIP39 fixes HMAC-SHA512, 2,048 iterations and a 512-bit (64-byte) output. No passphrase means an empty suffix, not omission of the salt. PBKDF2 does not ‘decrypt’ words and the seed cannot be used to reconstruct the original entropy by reversing the function. The fixed 2,048-round cost is modest by modern password-hardening standards, so it does not rescue a weak, guessable passphrase after the mnemonic leaks. [BIP 39 — Mnemonic code for generating deterministic keys] [RFC 8018 — PBKDF2]

BIP39 stops at the 64-byte seed. BIP32 commonly computes HMAC-SHA512 with key ‘Bitcoin seed’ to obtain a master private key and 32-byte chain code, then derives a tree. BIP44, BIP49, BIP84 and BIP86 choose different purpose paths and script families. Thus correct words and passphrase can still show an empty balance when the recovery software searches the wrong coin type, account, change branch, gap limit or script type. An output descriptor or documented wallet name, path and account structure supplies information BIP39 never encoded. [BIP 32 — Hierarchical deterministic wallets] [BIP 44 — Multi-account hierarchy] [BIP 84 — Native SegWit derivation] [BIP 86 — Single-key Taproot derivation] [BIP 380 — Output script descriptors] [Bitcoin Core — Output descriptors]

Every passphrase string produces a deterministic 512-bit seed, so there is no protocol-level ‘wrong passphrase’ response. This enables separate or decoy wallets, but a typo, different capitalization or forgotten Unicode character also opens a valid empty wallet. If an attacker obtains the mnemonic, they can test candidate passphrases offline by deriving wallets and checking public blockchain activity; 2,048 PBKDF2 rounds make short phrases poor protection. The passphrase must therefore be high entropy, entered on a trusted device where possible, and backed up separately enough to reduce joint theft without creating a single forgotten secret. [BIP 39 — Mnemonic code for generating deterministic keys] [Trezor — passphrases and hidden wallets]

For a generated sentence, the checksum is only 4 bits at 12 words and 8 bits at 24 words. A uniformly random 12-word sequence has a 1-in-16 chance of passing; a 24-word sequence has a 1-in-256 chance. It detects many accidental substitutions or reorderings but neither corrects them nor authenticates the creator: an attacker can deliberately compute a valid replacement. Software should warn about a checksum mismatch, yet rejecting every nonconforming historical import can also strand wallets made by other schemes. Never type secret words into an online checksum website. [BIP 39 — Mnemonic code for generating deterministic keys]

A backup is complete only if recovery is rehearsed on trusted hardware or offline software before material funds depend on it. Record the words in exact order, the existence and exact spelling of any passphrase, the originating wallet, relevant derivation/script type and multisignature or descriptor policy. Protect against photography, cloud sync, printers, cameras and clipboard logs; anyone with the complete mnemonic and required passphrase can spend without the device. Paper handles electronics failure but not fire or water; metal handles some physical hazards but not theft. Geographic separation must not turn one secret into casually exposed fragments. [BIP 380 — Output script descriptors] [Trezor — passphrases and hidden wallets] [Bitcoin Core — Output descriptors]

The specification strongly discourages generating non-English mnemonics because many wallets support only the English list; translating words necessarily changes the seed because the sentence itself enters PBKDF2. Electrum's native seed-version system is not BIP39 even when its words resemble a mnemonic, so import mode matters. BIP39 has no version field and does not encode an address format. SLIP39 is a distinct, mostly incompatible threshold-sharing format with its own 1,024-word list and group/member rules; merely dividing 24 BIP39 words among locations is not Shamir sharing and can reduce both security and recoverability. [BIP 39 — Mnemonic code for generating deterministic keys] [Electrum documentation — seed version system] [SLIP 39 — Shamir's Secret-Sharing for Mnemonic Codes]