HD wallets (BIP32, BIP44, BIP84, BIP86)

Wonder

1. How can a single seed generate an effectively unlimited number of unique, recoverable private keys?
2. Why can one leaked child private key, together with the parent’s extended public key, expose every key in a non-hardened branch?
3. What structural difference separates a legacy P2PKH address from a native SegWit or Taproot address in terms of fee efficiency?

Explore

1. Before BIP32, introduced by Pieter Wuille in 2012, wallets generated random key pairs for each new address. Backing up the wallet meant storing every single private key individually; losing one backup file meant those specific funds were unrecoverable. BIP32 changed this model by deriving a deterministic tree of keys from a single master seed. The entire financial history is now anchored to that single seed, usually created from 128 or 256 bits of entropy and written down as 12 or 24 words.
2. The derivation path follows the structure defined in BIP44 (2014): `m / purpose’ / coin_type’ / account’ / change / index`. The apostrophe denotes hardened derivation. This is a critical security mechanism. In non-hardened derivation, if an attacker obtains both the parent extended public key (xpub) and any single child private key, they can mathematically compute the parent private key. Hardened derivation breaks this link; a leaked child private key combined with the xpub reveals nothing about the parent’s secret.
3. BIP44 standardized the first three levels to enable multi-currency support within a single hierarchy. The `purpose’` level identifies the standard (e.g., 44 for BIP44, 84 for BIP84). The `coin_type’` level distinguishes assets; Bitcoin is index 0. This allows one seed to manage different cryptocurrencies without mixing their keys. The `account’` level organizes funds into separate accounts, each with its own change chain. Extended public keys (xpubs) are typically derived at this depth.
4. BIP84 updated the standard for native SegWit addresses starting with `bc1q`. It sets the purpose to 84. These addresses are more efficient than legacy formats because their witness data is discounted in the transaction weight calculation, reducing fees. The derivation path becomes `m / 84’ / 0’ / account’ / change / index`. For instance, the first external address of Account 0 is derived at `m/84’/0’/0’/0/0`. This structure allows servers to generate receiving addresses from an xpub without ever touching a private key.
5. BIP86, a separate derivation standard written by Ava Chow in 2021 for Taproot, sets the purpose to 86 and derives single-key Taproot addresses starting with `bc1p`. BIP86 covers single-key Taproot outputs with no script tree. Because a Taproot key path can also hold an aggregated key, such as a MuSig2 key, a multi-party wallet’s outputs can look exactly like these single-key ones on-chain.
6. Wallets scan ahead to detect used addresses, typically stopping after a ‘gap limit’ of 20 consecutive unused addresses on a chain. If no transactions are found in that range, the wallet assumes it has discovered all existing keys for that account. To verify this mechanism, open any modern HD wallet and locate its derivation path settings. Identify each level: purpose, coin type, account, change, and index. Derive two different paths from the same seed to confirm they produce distinct keys while remaining fully recoverable from the original mnemonic.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• P. Wuille, BIP32: Hierarchical Deterministic Wallets (2012)
• M. Palatinus & P. Rusnak, BIP44: Multi-Account Hierarchy for Deterministic Wallets (2014)
• P. Rusnak, BIP84: Derivation scheme for P2WPKH based accounts (2017)
• A. Chow, BIP86: Key Derivation for Single Key P2TR Outputs (2021)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 5