How Mnemonic Phrases Become Private Keys: BIP-39 and HD Wallets

This article has three layers:

1. Layer 1: The Intuition: A key tree
2. Layer 2: Real-World Use: Why "balance is 0 after import," the role of a passphrase, and the risks of xpub leakage
3. Layer 3: Principles and Engineering Key points: BIP-39 encoding and checksum, PBKDF2, BIP-32 derivation, derivation paths, including a standard test vector

Layer 1: The Intuition

1.1 A Key Tree

Early Bitcoin wallets had to back up a new private key every time a new address was generated, which was very cumbersome. HD (Hierarchical Deterministic) wallets introduced a different approach:

1. Generate only one root secret (the recovery phrase);
2. Use fixed mathematical rules to "grow" branches and leaves from the root, where each leaf is a private key;
3. With the same root and the same rules, the same tree is always grown.

Thus, by backing up the recovery phrase just once, the entire tree can be fully recovered in any wallet software.

1.2 Why Words

A 128-bit random number written in hexadecimal is 32 characters long; miscopying a single character ruins everything. BIP-39 splits it into 11-bit segments, where each segment corresponds to a word (a wordlist of $2^{11} = 2048$ words), and includes a checksum so the wallet can detect if a word is miscopied (similar to how the last digit of an ID card works in the Luhn algorithm and checksums).

Layer 2: Real-World Use

• "Balance is 0 after import": With the same recovery phrase, different wallets might use different default derivation paths, resulting in different addresses. The money isn't lost; it has just "grown" on a different leaf. Switching to the correct path will reveal it.
• passphrase (the 25th word): BIP-39 allows adding an extra passphrase outside the recovery phrase; a different passphrase results in a completely different seed. It can prevent "recovery phrase slips being seen" and can be used for "decoy wallets" (different passphrases corresponding to different wallets). The cost is: if you forget the passphrase, the money is truly gone.
• xpub leakage risk: An extended public key (xpub) can derive all child public keys, and is often given to accounting software for read-only viewing. However, it exposes the balances and transaction history of all your addresses (privacy); more dangerously, an xpub combined with any non-hardened child private key can be used to reverse-engineer the parent private key, which in turn allows deriving all sibling private keys.
• Multi-chain compatibility: The same recovery phrase can derive private keys for various chains like Bitcoin, Ethereum, Solana, etc., according to different paths.

Layer 3: Principles and Engineering

3.1 BIP-39: Entropy → Words

The checksum takes the first $\text{entropy bits}/32$ bits of $\mathrm{SHA256}(\text{entropy})$ and is appended to the entropy, then every 11 bits, a word is looked up in the wordlist.

In a 12-word phrase, only part of the bits in the last word are entropy, while the rest is the checksum. Therefore, if you write 12 words at random, there is only about a $1/16$ probability of passing the checksum.

3.2 Words → Seed: PBKDF2

$$\text{seed} = \mathrm{PBKDF2\text{-}HMAC\text{-}SHA512}\big(\text{mnemonic},\ \text{salt} = \texttt{"mnemonic"} + \text{passphrase},\ 2048 \text{ iterations}\big)$$

2048 iterations represent key stretching: making each passphrase guess take a little more time. However, for 128-bit random entropy, stretching is actually not strictly necessary; it primarily protects the user-defined passphrase.

3.3 Seed → Tree: BIP-32

Root node: $\mathrm{HMAC\text{-}SHA512}(\texttt{"Bitcoin seed"},\ \text{seed})$, where the left 256 bits are the master private key and the right 256 bits are the "chain code."

Each child node is calculated via HMAC-SHA512 using the parent's key, chain code, and child index $i$:

In normal derivation, child private key $=$ parent private key $+ \text{tweak}$ (modulo curve order $n$), while the tweak only depends on the public xpub. Therefore, "xpub + one child private key" can subtract out the parent private key. This is why the upper layers of the path must use hardened derivation.

3.4 Derivation Paths

BIP-44 specifies: m / purpose' / coin_type' / account' / change / address_index

3.5 Engineering details

• The recovery phrase must only be generated by a trusted random number generator (see "Wallets with bad randomness"), not "thought up" by oneself;
• Do not take photos, do not store in the cloud, and do not paste into any webpage or chat;
• When distributed storage is needed, use SLIP-39 (Shamir's Secret Sharing, see "Shamir's Secret Sharing"), rather than splitting the 12 words in half (each half would leak half of the entropy);
• When using xpub for read-only monitoring, ensure the counterparty is trusted and understand that it will expose the entire transaction history.

Summary