BIP 32 Explained: Hierarchical Deterministic Wallets

BIP 32 is the Bitcoin standard for hierarchical deterministic (HD) wallets: it derives a whole tree of private and public keys from one seed, so a single backup restores every address a wallet has used or will use. Pieter Wuille wrote it in 2012, and nearly every wallet with a seed phrase relies on it: BIP39 turns the phrase into a seed, BIP 32 turns the seed into keys, and BIP 44 and its successors decide which branch of the tree each coin and account uses.

BIP 32 at a Glance

What Problem Did BIP 32 Solve?

Early Bitcoin wallets gave every address its own random private key. To avoid a new backup after every transaction, the reference client created 100 keys in advance, so a backup covered only the keys that existed when it was made: coins received on a key created later were lost with the device. Deterministic wallets fixed the backup problem by computing all keys from one seed, but the early designs produced a single chain of keys, which could only be shared all or nothing.

BIP 32 arranges the keys in a tree instead. Every branch can be handed to another system on its own, with or without the power to spend. The specification’s example is a web shop: its server needs a fresh address for every order but no access to the merchant’s change addresses or private keys, so it gets the public key of one branch and nothing else.

• Before BIP 32: 50 payments meant 50 random keys, and a backup that had to be repeated as new keys were created.
• With BIP 32: the same 50 addresses come from one seed, and the backup made on day one restores all of them.

How Does BIP 32 Derive Keys From a Seed?

Every key in the tree comes with a 32-byte chain code, extra secret data that keeps a child from depending on the parent key alone. A key plus its chain code is an extended key. The specification builds the tree from two operations, both based on HMAC-SHA512:

Master key
  I = HMAC-SHA512(key = "Bitcoin seed", data = seed)
  private key = left 32 bytes of I, chain code = right 32 bytes

Child number i (4 bytes)
  normal   (i < 2^31):  data = parent public key || i
  hardened (i ≥ 2^31):  data = 0x00 || parent private key || i
  I = HMAC-SHA512(key = parent chain code, data)
  child private key = parent private key + left 32 bytes of I   (mod n, the curve order)
  child chain code  = right 32 bytes of I

Each child is again an extended key, so the same step repeats level after level. A path such as m/44'/0'/0'/0/0 lists the child numbers from the master key m down to one address key; our guide to derivation paths explains what each number means. The steps run in one direction only: from a child extended private key and its index, BIP 32 says, finding the parent private key is no easier than a 2²⁵⁶ brute-force search.

Hardened vs Normal Derivation: What Is the Difference?

Every extended key has 2³¹ normal children (indexes 0 to 2,147,483,647) and 2³¹ hardened ones (2,147,483,648 to 4,294,967,295). Paths write a hardened index with an apostrophe or an h, so 0' stands for 2³¹ + 0.

The second row is what makes watch-only wallets possible: anyone holding an account’s extended public key can compute every normal child public key, and so every receiving address, without any private key. The last row is the catch the specification warns about: an xpub plus any private key from a normal branch below it reveals the parent’s private key, and with it every key under that parent. That is why wallets harden the levels above the account: a leak inside one account cannot reach the master key or the other accounts.

We checked these properties with @scure/bip32 1.7 and the public test phrase abandon abandon … about. Its account xpub at m/44'/0'/0' produced the first address, 1LqBGSKuX5yYUonjxT5qGfpUsXKYYWeabA, without any private key, refused to derive a hardened child, and, combined with the private key of its normal child 5, gave back the account’s private key.

What Are Extended Keys (xprv and xpub)?

An extended private key is a private key with its chain code; an extended public key is the matching public key with the same chain code. BIP 32 serializes either one in 78 bytes:

With a checksum and Base58 encoding, the result is a 111-character string. The specification’s first test vector starts from the 16-byte seed 000102030405060708090a0b0c0d0e0f and gives the master public key xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8, which our script reproduced. A key’s fingerprint, the first 4 bytes of the HASH160 of its public key, is what wallets and descriptors show as the master fingerprint: 73c5da0a for the test phrase above.

An xpub cannot spend, but it reveals every address and the whole history of its branch, so share it only with software that needs to watch. Wallets also write the same 78 bytes with other prefixes, such as zpub for native SegWit accounts; see xpub, ypub and zpub.

How Do BIP39, BIP 32 and BIP 44 Fit Together?

BIP 32 does not define words or paths. It takes a seed, whatever produced it, and defines how keys are derived and written. The layers around it come from other standards:

1. BIP39 turns 12 to 24 words, plus an optional passphrase, into a 512-bit seed.
2. BIP 32 turns the seed into the master key m and derives its children.
3. BIP 43 reserves the first level for a purpose number, and BIP 44, BIP 49, BIP 84 and BIP 86 fix the rest of the path for each address type.

BIP 32 itself suggested a simpler layout, m/i'/0/k for the receiving addresses and m/i'/1/k for the change addresses of account i; BIP 44 later added purpose and coin type levels in front. Our comparison of BIP39 vs BIP32 vs BIP44 shows the three layers side by side. The derivation is defined for secp256k1, the curve of Bitcoin and Ethereum; networks on ed25519, such as Solana, use the SLIP-10 variant with hardened steps only (see seed phrase formats by network).

What Can You Do With a BIP 32 Wallet?

The specification lists use cases that most wallets now take for granted:

• Restore everything from one backup. Lose the phone, install a wallet, enter the seed phrase, and every account comes back.
• Watch without spending. A phone app, an accountant or a payment server gets an account xpub and sees or creates addresses, but cannot move funds. The specification’s audit case shares every account xpub.
• Keep keys on a device. A hardware wallet keeps the private keys and gives its companion app only xpubs, from which the app builds addresses and the transactions the device signs.
• Coordinate multisig. Each cosigner contributes an xpub, so a multisig wallet can derive matching keys for every address.
• Separate purposes. Accounts, or whole branches for different offices, live under one master key. BIP85 goes further and derives separate seed phrases from one master.

A business can combine these: the master key stays offline, accounting gets read-only xpubs, a server generates invoice addresses from one of them, and spending needs the offline device, so no employee ever handles a private key.

To see the tree for yourself, paste the public test phrase into the seed phrase to private key converter: it shows the BIP32 root key, the account extended keys and the addresses along any path.

Frequently Asked Questions

Is BIP 32 the same as BIP39?

No. BIP39 turns words into a seed; BIP 32 turns a seed into keys. A wallet can use BIP 32 with a seed from another source: Electrum’s own seed phrases, for example, feed BIP 32 derivation without following BIP39 (see Electrum seed vs BIP39).

Can someone spend my bitcoin with my xpub?

No. An xpub contains no private key, so it cannot sign. It does reveal every address and the balance of its account, and it becomes dangerous only together with a leaked private key from a normal branch below it.

What does the apostrophe in m/44’/0’/0’ mean?

It marks a hardened step: the index plus 2³¹. Hardened children can only be derived with the parent’s private key.

Do all coins use BIP 32?

Coins on the secp256k1 curve, such as Bitcoin, Ethereum, Litecoin and TRON, use BIP 32 directly, each with its own coin type in the path. Networks on ed25519, such as Solana and Stellar, use SLIP-10 instead, and a few coins have schemes of their own.

Explore the BIP series: What are Bitcoin Improvement Proposals? · BIP-39: The Seed Phrase Standard · BIP-44: Multi-Account Hierarchy · BIP-110 (BIP-444): Reduced Data Temporary Softfork · BIP-157: Client-Side Block Filtering · BIP39 vs BIP32 vs BIP44 compared