BIP 32 Hierarchical Deterministic Wallets made simple. See what the proposal changes, its current status and what it means for Bitcoin users and operators.
This guide explains BIP 32 hierarchical deterministic wallets in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
BIP 32 hierarchical deterministic wallets: An extended key serialises a version, depth, parent fingerprint, child number, chain code and key data. Extended private keys contain private key material.
A node operator is checking BIP 32 hierarchical deterministic wallets. BIP 32 begins with one master secret and chain code, then derives child nodes identified by indexes.
Older wallets generated many unrelated private keys and needed repeated backups as the pool changed. BIP 32 begins with one master secret and chain code, then derives child nodes identified by indexes. A backed-up root can reproduce the defined tree, provided the wallet also knows which paths, scripts, accounts and scan ranges were used.
An extended key serialises a version, depth, parent fingerprint, child number, chain code and key data. Extended private keys contain private key material; extended public keys contain a public point. Network-specific prefixes help display, but software must validate the full payload and intended network rather than trusting familiar first characters.
Normal child derivation allows an extended public key to derive public descendants, enabling watch-only address generation. Hardened derivation uses the parent private key and cannot be reproduced from the parent xpub. This boundary is central to account structures. A leaked parent xpub plus a corresponding non-hardened child private key can compromise the parent branch.
An xpub cannot normally sign, but it can reveal every address and transaction in its derivable branch. Sharing it with a shop server, explorer or accountant links activity that separate addresses were meant to keep apart. Store xpubs as sensitive financial data, scope branches narrowly and document every system that receives them.
A seed or master extended private key may reproduce keys, yet funds remain hard to find if the wallet forgets derivation paths, script type, account boundaries and gap limits. Output descriptors capture that policy more precisely. Recovery documentation should include network, receive and change branches, birthday and supported address formats without exposing secrets unnecessarily.
Multisignature wallets can combine independently derived cosigner keys at matching paths. Key order, origin fingerprints, hardened boundaries and script policy must agree. One cosigner xpub is not a full backup of the wallet. Every participant needs the complete public policy and enough independent private backups to satisfy the intended recovery quorum.
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
BIP 32 hierarchical deterministic wallets: An extended key serialises a version, depth, parent fingerprint, child number, chain code and key data.
Older wallets generated many unrelated private keys and needed repeated backups as the pool changed.
An extended key serialises a version, depth, parent fingerprint, child number, chain code and key data.
Normal child derivation allows an extended public key to derive public descendants, enabling watch-only address generation.
BIP 32 made reproducible wallet trees and watch-only branches practical, but it concentrates authority and privacy in extended keys. Safe use requires explicit derivation paths, hardened boundaries, descriptors, protected xpubs and rehearsed recovery.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 450 guide to Draft Formosa themed mnemonic stories, entropy and checksum mapping, theme JSON, BIP39 conversion, passphrases and recovery safety.
BIP 393 guide to Draft descriptor annotations for birth height, gap limit and Silent Payment max label, checksum rules, parsing and recovery safety.
BIP 392 guide to Draft sp() descriptors, spscan and spspend encodings, watch-only and full-wallet forms, key origins, recovery and validation.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.