BIP-32 (Hierarchical Deterministic Wallets)

The entire HD wallet is derived from a single master seed, typically a 12-24 word mnemonic. This seed generates a master extended private key (xprv) and a master extended public key (xpub). The 'extended' prefix means the key contains the private/public key plus an extra 256-bit chain code, which is used in subsequent derivations to ensure child keys are cryptographically unlinkable without the parent.

Keys are derived in a tree structure using a standardized notation called a derivation path (e.g., m/44'/0'/0'/0/5). Each level is separated by a slash (/). The m denotes the master node. Apostrophes (') indicate hardened derivation, which requires the parent's private key, enhancing security for account-level keys. Non-hardened derivation uses only the parent's public key, allowing for watch-only wallets.

A core feature is the ability to derive a sequence of public keys from a parent extended public key (xpub) without access to any private keys. This enables the creation of watch-only wallets that can generate all future public addresses for receiving funds and monitor balances, while the private keys remain securely offline in cold storage.

All keys are deterministically generated from the original seed. This means:

• The same seed will always produce the same sequence of keys on any compatible wallet software.
• A single backup (the mnemonic phrase) can recover the entire wallet hierarchy, including all derived accounts and addresses, eliminating the need for multiple backups.

The hierarchy allows logical organization of keys. Standard paths (defined in BIP-44) use the structure: purpose' / coin_type' / account' / change / address_index.

• coin_type: Differentiates between networks (e.g., 0 for Bitcoin, 60 for Ethereum).
• account: Allows separate wallets for different users or purposes.
• change: 0 for receiving addresses, 1 for change addresses. This creates a scalable structure for managing multiple assets and accounts.

BIP-32 defines two derivation types with different security properties:

• Hardened Derivation (i'): Uses the parent's private key and chain code. A compromised child key cannot compromise the parent or siblings. Used for high-value account keys.
• Non-Hardened Derivation (i): Uses the parent's public key and chain code. Allows public key derivation but carries a risk: if a child private key and its parent extended public key are compromised, the parent private key can be calculated.

A Hierarchical Deterministic (HD) wallet starts from a single, cryptographically random master seed (often represented as a 12-24 word mnemonic). From this seed, the wallet deterministically generates a master private key and a master chain code. Using the CKD (Child Key Derivation) function, it can then create an infinite hierarchy of child keys. This process uses HMAC-SHA512 to combine the parent key and chain code with an index number, ensuring keys are derived in a repeatable, non-reversible manner.

A critical innovation of BIP-32 is hardened and non-hardened (normal) derivation paths. Non-hardened derivation allows a parent public key and chain code to derive a sequence of child public keys, without exposing the parent private key. This enables:

• Watch-only wallets that can generate all public addresses for monitoring.
• Secure key generation on an offline device, while an online device holds only the public parent key to derive new receiving addresses. Hardened derivation (using the parent private key) is used for accounts that hold large sums, preventing a compromise of a child key from revealing the parent.

BIP-32's flexibility led to the need for a standard structure. BIP-44 defines a universal HD wallet structure using the derivation path format: m/purpose'/coin_type'/account'/change/address_index. This organizes keys into:

• purpose': Always 44' for BIP-44.
• coin_type': A registered number (e.g., 0' for Bitcoin, 60' for Ethereum).
• account': User-defined accounts (e.g., Savings, Checking).
• change: 0 for external (receiving) addresses, 1 for internal (change) addresses. This allows a single seed to manage multiple cryptocurrencies and accounts across different wallets (Ledger, Trezor, MetaMask) interoperably.

The entire HD wallet tree is backed up by a single mnemonic seed phrase, standardized by BIP-39. This human-readable phrase (e.g., 12 or 24 words) is converted into the binary seed used by BIP-32. The security model is absolute:

• Lose the seed phrase, and all derived keys and funds are permanently lost.
• Possess the seed phrase, and you can fully restore the wallet on any compatible software, regenerating every address and private key in the correct order. This eliminates the need for backing up individual private keys and simplifies recovery from device loss or failure.

BIP-32 is not a feature but an infrastructure standard. Its adoption is near-universal:

• All major hardware wallets (Ledger, Trezor) and software wallets (Electrum, MetaMask, Trust Wallet) are HD wallets.
• Multi-signature setups and institutional custody solutions use HD trees to manage complex key hierarchies.
• Lightning Network payment channels use deterministic key derivation for commitment transactions. It is the silent, foundational layer that makes modern, user-friendly cryptocurrency management possible, separating wallet interface from key generation.

The entire wallet hierarchy is derived from a single master seed (or mnemonic phrase). Compromise of this seed grants an attacker access to all derived keys and addresses across all accounts and chains. This makes secure, offline storage of the seed phrase the paramount security requirement. Best practices include:

• Using a hardware wallet for seed generation and storage.
• Never storing the seed digitally (no photos, cloud storage, or plaintext files).
• Using physical backup methods like steel plates stored in secure locations.

The standard BIP-44 derivation path structure (e.g., m/44'/0'/0') reveals the coin type and account index. While the private keys themselves remain secure, exposing full paths can leak metadata about wallet structure and usage patterns. For enhanced privacy, some implementations use non-standard or hardened paths. It's critical that the derivation logic in wallet software is bug-free, as an error can lead to generating incorrect or insecure keys.

BIP-32 defines two types of child key derivation: normal and hardened. Using hardened derivation (indicated by an apostrophe, e.g., m/44'/0') is crucial for security. It prevents a compromise of a child private key and its parent chain code from being used to derive sibling keys or the parent private key. For the master seed's immediate children (account level), hardened derivation is non-negotiable. Normal derivation is typically reserved for deriving public keys for watch-only wallets.

An extended public key (xpub) allows derivation of all public addresses in a branch without the private key, enabling watch-only wallets. However, if an xpub is exposed, anyone can:

• See all past and future transaction history for that branch.
• Derive all public addresses, compromising privacy.
• In combination with a later-compromised child private key (if normal derivation was used), potentially derive other private keys. Therefore, treat xpubs with similar caution to public addresses from a privacy perspective.

Security depends entirely on the quality of the implementation. Critical risks include:

• Weak Entropy Source: If the initial seed is not generated with sufficient cryptographic randomness (e.g., a flawed RNG), the entire key space is predictable.
• Faulty Derivation: Bugs in the HMAC-SHA512 derivation logic can produce incorrect keys, leading to loss of funds.
• Side-Channel Attacks: Physical attacks on hardware wallets targeting the derivation process. Always use well-audited, open-source libraries from reputable providers.

The serialized format for BIP-32 keys, which includes the key data plus chain code and metadata. An extended private key (xprv) can derive child keys, while an extended public key (xpub) can derive only child public keys.

• xpub can be shared to generate receiving addresses without exposing private keys.
• Essential for creating watch-only wallets and merchant payment systems.
• The chain code ensures derived keys are cryptographically linked.

A string that specifies the precise location of a key within a BIP-32 hierarchical tree. It is a sequence of indices that the parent key uses with its chain code to generate a specific child key.

• Paths use notation like m/44'/0'/0'/0/5.
• Apostrophes (') denote hardened derivation, which requires the parent private key.
• Non-hardened derivation allows an xpub to derive child public keys.

Two child key derivation methods defined in BIP-32 with different security properties.

• Hardened Derivation: Uses the parent private key and index > 2³¹. A compromised parent public key cannot expose hardened child keys. Used for deriving account-level keys.
• Non-Hardened (Normal) Derivation: Uses the parent public key. Allows an xpub to generate all child public keys, enabling watch-only wallets. If the parent private key and a child private key are leaked, the chain code can be compromised.