BIP32 (Hierarchical Deterministic Wallets)

BIP32 defines hierarchical deterministic (HD) wallets, the architecture behind nearly every modern Bitcoin wallet. Instead of generating and separately backing up unrelated private keys, an HD wallet derives a whole tree of keys from one master seed. The seed (128-512 bits of entropy) is run through HMAC-SHA512 with the key string "Bitcoin seed" to produce a master private key and a 256-bit chain code. From that root, child keys descend in a structured tree, each addressable by a path such as m/0/1.

Why a single backup is enough

Because every key is reproducible from the seed, you only need to back up that seed once (commonly as a BIP39 mnemonic). Restore the seed into any compatible wallet and it regenerates the same addresses, balances, and spending keys. This is what makes a 12- or 24-word phrase a complete wallet backup rather than just one key among many.

The chain code and extension

Each key is "extended" with the chain code, giving 256 extra bits of entropy that feed the derivation of children. An extended private key can derive both child private and public keys; an extended public key (the xpub) can derive child public keys only, which enables watch-only and receive-only setups without exposing spending authority.

BIP32 is the foundation for path conventions like BIP44 and for extended public keys (xpub), and it underpins the hardened derivation safeguards that protect a parent key from a leaked child. We treat correct HD-wallet handling as core to self-custody hygiene for sovereign Bitcoiners.

Hardened Versus Normal Derivation

BIP32 defines two ways to derive a child, and the difference carries real security weight. Normal derivation lets an extended public key derive child public keys on its own — the property that makes watch-only wallets possible. But it has a sharp edge: anyone holding the xpub plus any single child private key can compute the parent private key, and with it every sibling. Hardened derivation (indices from 2³¹ up, written with an apostrophe, as in m/84'/0'/0') requires the parent private key to derive children, severing that linkage — a leaked child key compromises nothing above it. Convention therefore hardens the upper levels of the tree (purpose, coin, account) and uses normal derivation only at the bottom, where address-generating xpubs need to work.

Paths in Practice: The BIP44 Family

Raw BIP32 allows any tree shape, so follow-on standards fixed a convention: m / purpose' / coin' / account' / change / index. The purpose field encodes the address type — 44' for legacy, 49' for wrapped SegWit, 84' for native SegWit, 86' for Taproot — so a modern native-SegWit wallet derives its first receive address at m/84'/0'/0'/0/0, and the change branch (…/1/…) keeps change addresses separate from receive addresses. This shared map is why a seed created in one wallet generally restores in another: both sides agree on where in the tree the coins live. The seed itself is usually stored as a mnemonic — see seed phrase — with BIP39 defining how words become the BIP32 root.

Recovery Pitfalls That Actually Bite

Most “lost coins” panics after a restore are derivation mismatches, not lost keys. A wallet restored under the wrong purpose (84' coins searched at 44' paths), a nonstandard account index, or a forgotten BIP39 passphrase — which silently derives a completely different tree from the same words — all present as a valid-looking wallet with a zero balance. The funds are untouched; the wallet is looking in the wrong branch. Recording the derivation paths and script types alongside a backup costs one line of ink and defuses the entire class of problem. This is core hygiene for self-custody: a backup you have never test-restored, paths included, is a hypothesis rather than a backup.