BIP-32 (HD Wallets)

What Is BIP-32?

BIP-32 (Bitcoin Improvement Proposal 32) is the specification that introduced hierarchical deterministic wallets to Bitcoin. Proposed by Pieter Wuille in February 2012, it defines a standard method for deriving a tree-structured hierarchy of private and public keys from a single master seed. Before BIP-32, Bitcoin wallets generated each key independently and at random, meaning users needed a new backup every time they created a new address.

With BIP-32, a wallet generates one master seed (typically encoded as a seed phrase via BIP-39) and derives every subsequent key deterministically. If you know the seed, you can regenerate every key and address the wallet has ever produced. This single-backup property transformed Bitcoin usability and became the standard adopted by virtually every wallet in use today.

The "hierarchical" part means keys are organized in a tree structure: a master key produces child keys, those children produce grandchildren, and so on. Each branch of the tree can be shared independently, enabling powerful patterns like account separation, department-level access controls, and watch-only monitoring without exposing spending authority.

How It Works

BIP-32 key derivation is built on two cryptographic primitives: HMAC-SHA512 for key derivation and secp256k1 elliptic curve math for key operations. The process begins with master key generation and extends through child key derivation at each level of the hierarchy.

Master Key Generation

Everything starts with a seed: a random byte sequence (128 to 512 bits). The wallet computes the master extended key by running:

I = HMAC-SHA512(Key = "Bitcoin seed", Data = seed)

// Split the 64-byte output:
master_private_key = I[0..31]   // left 32 bytes
master_chain_code  = I[32..63]  // right 32 bytes

The master private key and master chain code together form the master extended private key. The chain code acts as entropy for subsequent derivations: it ensures that knowing the key alone is not enough to derive children.

Child Key Derivation

Given a parent extended key (key + chain code) and a 32-bit index, BIP-32 derives a child key using HMAC-SHA512 keyed by the parent chain code. The input data depends on whether the derivation is normal or hardened:

// Normal (non-hardened) child derivation (index < 2^31)
I = HMAC-SHA512(
  Key  = parent_chain_code,
  Data = serialize_public(parent_key) || index
)

// Hardened child derivation (index >= 2^31)
I = HMAC-SHA512(
  Key  = parent_chain_code,
  Data = 0x00 || parent_private_key || index
)

// In both cases:
child_private_key = (parse256(I[0..31]) + parent_private_key) mod n
child_chain_code  = I[32..63]

The child key is the sum of the parent private key and a value derived from the HMAC output, taken modulo the curve order n. This additive relationship is what makes normal derivation compatible with public-key-only computation.

Hardened vs Normal Derivation

The distinction between hardened and normal derivation is central to BIP-32's security model:

Normal derivation uses the parent public key as HMAC input, which means the same computation can be performed with only the extended public key. This enables watch-only wallets and address generation on untrusted servers. However, it comes with a critical security caveat: if an attacker obtains both a child private key and the parent chain code, they can compute the parent private key and compromise the entire branch.

Hardened derivation uses the parent private key as input instead, breaking the mathematical link between parent public key and child keys. This provides security isolation: even complete compromise of a hardened child branch cannot propagate upward to the parent. The tradeoff is that hardened derivation requires the private key, so it cannot be performed from an xpub alone.

Extended Key Serialization

BIP-32 defines a 78-byte serialization format for extended keys, which is then Base58Check-encoded into the familiar xpub and xprv strings:

// 78-byte extended key structure:
[4 bytes]  version       // 0x0488B21E (xpub) or 0x0488ADE4 (xprv)
[1 byte]   depth         // 0x00 for master, 0x01 for depth-1, etc.
[4 bytes]  fingerprint   // first 4 bytes of parent key's Hash160
[4 bytes]  child number  // index used in derivation
[32 bytes] chain code    // required for further derivation
[33 bytes] key data      // compressed public key or 0x00 + private key

// Base58Check encoding produces:
// xpub661MyMwAqRbcF... (111 characters for public)
// xprv9s21ZrQH143K3... (111 characters for private)

The version bytes determine the prefix of the encoded string: xpub for mainnet public keys, xprv for mainnet private keys. Later BIPs introduced additional version bytes (ypub, zpub) to indicate SegWit address types, though the underlying BIP-32 derivation mechanism remains identical.

Derivation Paths

BIP-32 defines the tree structure, but leaves the organization of that tree to the implementer. In practice, the community has standardized specific derivation paths through subsequent BIPs:

• BIP-44 defines the path m/44'/coin'/account'/change/index for legacy addresses
• BIP-49 uses m/49'/coin'/account'/change/index for P2SH-wrapped SegWit
• BIP-84 uses m/84'/coin'/account'/change/index for native SegWit (bech32)
• BIP-86 uses m/86'/coin'/account'/change/index for Taproot (bech32m)

In each of these paths, the first three levels use hardened derivation (indicated by the apostrophe) to isolate accounts from each other. The final two levels use normal derivation so that an xpub at the account level can generate all receiving addresses without access to any private key. For a deeper look at how Bitcoin addresses map to these paths, see the research article on Bitcoin address types from P2PKH to Taproot.

Use Cases

Watch-Only Wallets

One of BIP-32's most practical features is enabling watch-only wallets. By exporting an account-level xpub, a user can monitor all incoming transactions and generate new receiving addresses on a separate device (or server) that never holds private keys. The spending keys remain in cold storage, while the xpub handles day-to-day address generation and balance tracking.

Account Separation

BIP-32's tree structure lets a single seed manage logically separate accounts. A business might use one branch for payroll, another for vendor payments, and a third for customer deposits. Each branch operates independently, and hardened derivation at the account level ensures that compromise of one branch does not expose others.

Multi-Device Coordination

Because key derivation is deterministic, multiple devices initialized with the same seed will produce identical key trees. A mobile wallet and a desktop wallet can independently derive the same addresses and detect the same transactions without any communication between them. This same property powers wallet recovery: restoring a seed phrase on any BIP-32-compatible wallet regenerates the full key hierarchy.

Payment Processing

Merchants and payment processors use xpubs to generate a unique address per transaction without exposing private keys to their web servers. The server derives addresses from the xpub, while the private keys remain offline. This pattern is essential for any service handling Bitcoin payments at scale. Layer-2 solutions like Spark build on these same key derivation primitives to enable self-custodial wallet infrastructure.

Relationship to Other BIPs

BIP-32 is part of a family of proposals that together define the modern wallet experience:

• BIP-39 converts a mnemonic seed phrase into the binary seed that BIP-32 uses as input
• BIP-43 proposes a "purpose" field as the first level of the derivation path, allowing wallets to signal which address format they use
• BIP-44 standardizes the full derivation path structure for multi-account, multi-coin wallets

Together, these proposals mean that a 12- or 24-word seed phrase can reconstruct an entire wallet across any compliant software or hardware device. For more on how wallets manage these keys in practice, see the research article on Bitcoin custody solutions compared.

Risks and Considerations

Extended Public Key Exposure

Sharing an xpub reveals all current and future addresses derived under that branch. Anyone with the xpub can trace every transaction associated with those addresses, eliminating financial privacy. Treat xpubs as sensitive data: share them only with trusted systems that need address generation capability.

Normal Derivation Key Leakage

The most critical security property to understand: if an attacker obtains both a non-hardened child private key and the parent chain code (which is embedded in the xpub), they can compute the parent private key. From there, they can derive every sibling key in the branch. This is why account-level derivation always uses hardened paths: it provides a security firewall between accounts.

Gap Limit

When recovering a wallet from a seed, the software must scan the blockchain for used addresses. It does this sequentially, stopping after a certain number of consecutive unused addresses (the gap limit, typically 20). If a user skips indices when generating addresses, the wallet may fail to discover funds beyond the gap. This is a practical concern when restoring wallets that were used with non-standard software.

No Native Multi-Signature Support

BIP-32 derives single-key hierarchies. It does not natively handle threshold signatures or multi-party key generation. Protocols like FROST and MuSig2 extend the concept to multi-party settings, but they operate alongside BIP-32 rather than within it.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.