HD Wallet

Alice opens the receive screen and her wallet shows an address. She receives 10,000 satoshis, the small units of bitcoin, at that address. For the next payment, the app offers a different address, which receives 20,000 satoshis. If these are her only unspent receipts, the wallet shows a total of 30,000 satoshis. The new address did not create a separate account, and the earlier funds did not automatically move anywhere. The app manages the keys for both receipts. An HD Wallet makes this practical. HD means Hierarchical Deterministic: hierarchical because the keys form a branching structure, and deterministic because the same seed and path produce the same keys, including during recovery. A path is a sequence of numbers specifying which branch and key the program should calculate. Alice rarely needs to deal with it when receiving a payment, but recovery requires the wallet to use the right paths. One backup of the starting secret can therefore cover future addresses too; the wallet settings still need preserving. Fresh addresses help avoid address reuse, but do not by themselves guarantee anonymity. [1] [12]

An extended public key, commonly called an xpub, allows public keys for part of this structure to be calculated. It does not contain the private keys needed to sign a payment. An xpub alone therefore cannot spend funds; to create specific addresses, the app also needs to know their format. A watch-only wallet with a suitable xpub can generate addresses and monitor payments without signing keys. Leaking the xpub can nevertheless link past and future addresses in that branch, balances and transactions. Share only the branch needed. Even a correct xpub cannot stop a compromised computer displaying somebody else's address. Verify the receiving address on a trusted signing device that knows the wallet. [1] [12] [14]

A shop can create a different address for each order. Its website needs the addresses, but should not hold the keys that spend the proceeds. BIP32 separates that receiving branch from the rest of the wallet. Pieter Wuille wrote the proposal, assigned on 11 February 2012. It is a wallet standard, not a consensus rule. BIP39 backup words, script types and the complete recovery procedure belong to other layers. [1] [11] [12]

BIP32 adds a 256-bit chain code to a key: 32 bytes for further derivation. The private form consists of a secp256k1 scalar k and chain code c; the public form uses K = point(k) and the same c. Master key generation uses HMAC-SHA512 with the exact string “Bitcoin seed” as its key and the seed as data. The left 32 bytes are the candidate private key; the right 32 bytes are the chain code. Zero or a value at least equal to the curve order n makes the master key invalid. [1]

Derivation is a calculation, not a lookup in a stored list. There are normal and hardened forms of derivation. Normal derivation can calculate further public keys from the parent extended public key; a hardened step requires the parent extended private key. CKDpriv computes I = HMAC-SHA512(cpar, data), splits it into IL and IR, and adds parse256(IL) to the parent private key modulo n. IR is the new chain code. Normal derivation uses serP(Kpar) || ser32(i); hardened derivation uses 0x00 || ser256(kpar) || ser32(i), where i ≥ 2^31. CKDpub handles only normal public branches, adding point(parse256(IL)) to Kpar. A different branch number changes subsequent derived keys. [1]

An xpub can derive public keys as long as the path does not cross a hardened step. There is an important tradeoff: a parent xpub together with a leaked private key of its normal child allows the parent private key to be calculated. Its other branches are then also at risk. Hardened derivation blocks this reverse calculation. It does not protect against a stolen seed, weak randomness or approval of a malicious transaction. [1]

On mainnet, the standard public encoding starts with xpub and the private one with xprv; their versions are 0x0488B21E and 0x0488ADE4. Before Base58Check encoding, the record has 78 bytes: version 4, depth 1, parent fingerprint 4, child number 4, chain code 32 and key data 33. The result has 111 characters. The short fingerprint helps match keys; it is not proof of identity. SLIP132 prefixes such as ypub/zpub sometimes indicate a script type. Changing the prefix alone changes neither the keys nor the wallet rules. [1] [9]

BIP43 reserved the first hardened level for purpose. BIP44 uses m / 44' / coin_type' / account' / change / address_index. After the account comes branch 0 for receiving or 1 for change, followed by the address number. An apostrophe or h denotes an index increased by 2^31. BIP44 discovery uses a gap limit of 20: it stops after 20 consecutive unused receiving addresses. BIP48 describes Multisig, BIP84 purpose 84' for native SegWit, and BIP86 purpose 86' for single-key Taproot. These conventions are neither stored in the seed itself nor enforced by nodes. [2] [3] [4] [5] [6]

Keys alone do not specify the script protecting the coins. An Output Descriptor can record key origins, paths, a construction such as wpkh(), the required signature count, other Multisig participants and a checksum. A multipath descriptor can combine receiving and change branches. One participant's seed cannot reconstruct the other xpubs or shared rules. Back up a verified public descriptor or configuration export too, and protect its privacy. If an export contains private keys, treat it as a secret. [7] [8] [10] [13]

The seed can derive the keys again, but the application needs the seed format, any BIP39 passphrase, network, script type, coin type, accounts, both branches and search range. Multisig also needs the shared configuration. A zero balance after recovery need not mean lost coins; the cause may be a different path. A safe test on a trusted device should find the correct UTXOs, the transaction outputs that remain unspent, and verify signing. Never enter a real seed or backup words into a web tool or an ordinary online computer. [3] [7] [10] [11]

BIP32 also covers rare invalid results: parse256(IL) ≥ n, a derived private key of zero or a public point at infinity. For such a child, the next index is tried. Recovery more often fails because of a missing path, change branch or supported script type. Before switching applications, verify coin discovery and a small test transfer. Keep the original backup and configuration until the new procedure works. An xprv provides the keys needed for signing, an xpub exposes financial relationships, and a descriptor explains how to construct the wallet. [1] [7] [9] [10]