BIP32 combines every private or public key with a 256-bit chain code. HMAC-SHA512 and a numbered derivation path create child extended keys; non-hardened public children can be derived from an xpub, while hardened children require private material. That distinction enables useful delegation and also creates a precise compromise boundary.
Pieter Wuille authored BIP32, assigned on 11 February 2012. Earlier deterministic wallets could generate a sequence from one seed, but BIP32 added hierarchy: a parent can delegate an account or receiving branch without exposing unrelated branches. It is an application-level key standard, not a Bitcoin consensus rule. BIP32 says nothing about mnemonic word lists, user passphrases, script templates or address discovery; BIP39 and later path and descriptor standards fill separate layers. [BIP 32 — Hierarchical deterministic wallets] [BIP 39 — Mnemonic code for deterministic keys] [Bitcoin Developer Guide — Wallets]
A BIP32 extended private key is a secp256k1 scalar k paired with a 32-byte chain code c; its public form replaces k with point K = point(k) but keeps c. For a master node, HMAC-SHA512 uses key ‘Bitcoin seed’ and the seed bytes as data. The left 32 bytes become the candidate master scalar and the right 32 bytes the chain code. If the scalar is zero or at least the curve order n, the seed is invalid and software must not silently substitute another algorithm. [BIP 32 — Hierarchical deterministic wallets]
CKDpriv computes I = HMAC-SHA512(cpar, data), interprets IL as an integer and adds it modulo n to the parent scalar; IR becomes the child chain code. A normal child uses compressed serP(Kpar) || ser32(i), while a hardened child uses 0x00 || ser256(kpar) || ser32(i) with i at least 2^31. CKDpub can reproduce only normal public children by adding point(parse256(IL)) to Kpar. Child numbers are inputs: changing one index changes the entire descendant subtree. [BIP 32 — Hierarchical deterministic wallets]
Normal derivation is intentionally public: an xpub can generate every normal descendant public key. The dangerous corollary is explicit in BIP32: a parent xpub plus any leaked non-hardened descendant private key reveals the parent private key, after which sibling branches are exposed. Hardened derivation blocks public derivation across that boundary and prevents this specific reverse calculation. It does not make the seed theft-proof, repair weak randomness or protect a signing device from approving a malicious transaction. [BIP 32 — Hierarchical deterministic wallets]
The standard serialization is 78 bytes before Base58Check: 4 version bytes, 1 depth byte, 4-byte parent fingerprint, 4-byte child number, 32-byte chain code and 33-byte key data. Mainnet xprv/xpub use 0x0488ADE4/0x0488B21E and usually encode to 111 characters. The four-byte fingerprint is only a short identifier, not collision-proof authentication. Alternative ypub/zpub-style prefixes from SLIP132 signal intended script families to some software, but support is inconsistent and a prefix conversion cannot change the underlying key or reconstruct missing policy. [BIP 32 — Hierarchical deterministic wallets] [SLIP 132 — Registered HD version bytes]
BIP43 reserves a hardened first level as purpose. BIP44 popularized m / 44' / coin_type' / account' / change / address_index, with external branch 0, change branch 1 and an address gap limit of 20. BIP48 targets multisig; BIP84 uses purpose 84' for native SegWit and BIP86 uses 86' for single-key Taproot. These paths are wallet interoperability conventions, not facts visible in a seed or enforced by nodes. The apostrophe or h means index + 2^31, not punctuation that recovery software may ignore. [BIP 43 — Purpose field for deterministic wallets] [BIP 44 — Multi-account hierarchy] [BIP 48 — Multi-script hierarchy for multisig wallets] [BIP 84 — Native SegWit derivation] [BIP 86 — Single-key Taproot derivation]
A scoped xpub supports a watch-only wallet, address generation and accounting without signing power. Leaking it nevertheless reveals past and future addresses in that subtree, balances, timing and transaction links; sharing an account xpub is therefore a durable privacy disclosure. Giving a shop or server a narrower receiving branch can reduce scope, but a compromised host can still substitute its own address. Verify material receive addresses on a trusted signing device rather than trusting the host display alone. [BIP 32 — Hierarchical deterministic wallets] [Bitcoin Developer Guide — Wallets] [Trezor Learn — Hierarchical deterministic wallets]
An xpub describes keys, not the locking scripts built from them. A descriptor can bind key origin [fingerprint/path], the script wrapper such as wpkh(), multisig threshold and cosigners, wildcard branches and a checksum. Multipath descriptors can express receiving and change branches together. For multisig, the seed of one signer cannot reconstruct the other xpubs, key order or threshold. Backing up a tested descriptor or wallet export alongside separately protected secrets closes this metadata gap. [BIP 380 — Output script descriptors] [BIP 389 — Multipath descriptor key expressions] [Bitcoin Core — Output descriptors] [Bitcoin Optech — Output script descriptors]
A root seed can regenerate keys indefinitely, so ordinary address creation no longer requires a new secret backup. Recovery still needs the correct BIP39 passphrase if used, seed format, network, purpose/script family, coin type, account numbers, receiving/change branches, gap or look-ahead policy and multisig descriptor. An apparently empty wallet often means the software searched the wrong tree. Restore tests should prove both detection of historical UTXOs and signing, then be repeated after policy or cosigner changes without exposing live secrets to an online tool. [BIP 44 — Multi-account hierarchy] [BIP 380 — Output script descriptors] [Bitcoin Core — Output descriptors] [BIP 39 — Mnemonic code for deterministic keys]
Implementations must reject or skip the extremely rare child cases where parse256(IL) is at least n, the derived private scalar is zero or the public result is the point at infinity; BIP32 specifies moving to the next index. Compatibility failures are far more common: lost origin fingerprints, different account discovery, ypub/zpub interpretation, omitted change branch, unsupported Taproot or imported xpub at the wrong depth. Treat an xprv as spend authority, an xpub as sensitive financial metadata and a descriptor as a policy map; label their scope and test migration before retiring the original wallet. [BIP 32 — Hierarchical deterministic wallets] [BIP 380 — Output script descriptors] [SLIP 132 — Registered HD version bytes] [Bitcoin Core — Output descriptors]
For the clearest picture, read this entry together with Bitcoin wallet, Seed Phrase, Extended Public Key (xpub), Derivation Path, Gap Limit, Bitcoin. The reverse links also lead from Bitcoin address, BIP 39, Cold Storage, Watch-only Wallet.