BitcoinMachine
TECHNICAL_DOC // KEYS / HD-WALLETS
HD
WALLETS
A Hierarchical Deterministic (HD) wallet (BIP 32) generates an entire tree of keys from a single seed. From one master key, an unlimited number of child keys can be derived deterministically — backing up the seed once backs up every past and future address. HD wallets enable address rotation, account separation, and watch-only deployment via extended public keys (xpub).
MASTER_KEY_GENERATION
FROM SEED TO MASTER KEY
Input: 64-byte BIP39 seed (from mnemonic + passphrase) Step 1: HMAC-SHA512 with key "Bitcoin seed" I = HMAC-SHA512(key="Bitcoin seed", data=seed) I is 64 bytes Step 2: Split master_privkey = I[0:32] (left half) master_chain = I[32:64] (right half — chain code) The master key is the root of the tree: m ← master node ├─ m/0 ← first child ├─ m/1 ← second child ├─ m/0/0 ← grandchild ... A node has: - 32-byte private key (or pubkey for watch-only) - 32-byte chain code (extra entropy for derivation)
Child Key Derivation (CKD)
DERIVATION
Each child key is computed via hmac-sha512/">HMAC-SHA512 from the parent's chain code, parent key, and child index. Two modes: non-hardened (allows xpub derivation) and hardened (requires private key).
Non-hardened (index < 2³¹): data = compressed_parent_pubkey || index_be32 I = HMAC-SHA512(key=parent_chain, data) child_priv = (parent_priv + I[0:32]) mod n child_chain = I[32:64] Property: derivable from parent xpub alone (no privkey needed → watch-only wallets) Hardened (index ≥ 2³¹, written 0' or 0h): data = 0x00 || parent_priv || index_be32 I = HMAC-SHA512(key=parent_chain, data) child_priv = (parent_priv + I[0:32]) mod n child_chain = I[32:64] Property: requires parent private key xpub leak does NOT compromise hardened children Standard practice: hardened above the account level m / purpose' / coin' / account' / change / index
Why HD Wallets — Single Backup Property
BACKUP MODEL
Pre-HD wallets generated each key independently and required wallet.dat backup after every new address. HD wallets need only one backup ever.
Pre-BIP32 (e.g. early Bitcoin Core): Each new address → new random key Backup required after every transaction Lost backup → lost funds for keys generated after BIP 32 HD: One seed → entire infinite tree Generate millions of addresses, no new backup needed Restore on any wallet → all addresses recovered Other benefits: xpub watch-only: Hand the xpub to a server/explorer Server can derive all receive addresses Server CANNOT spend (no privkeys) Account separation: m/84'/0'/0' = personal funds m/84'/0'/1' = business funds Compromise of one account does not affect others Address rotation: m/84'/0'/0'/0/0, /0/1, /0/2, ... Each tx can use a fresh address (privacy)
xpub Derivation (Watch-Only)
PUBLIC TREE
Extended public keys allow address generation without exposing private keys. The same chain code that lets you derive child privkeys also derives child pubkeys.
From parent xpub (pubkey + chain code): For each non-hardened child index i: data = compressed_parent_pubkey || index_be32 I = HMAC-SHA512(key=parent_chain, data) child_pubkey = parent_pubkey + I[0:32]·G child_chain = I[32:64] Now you can: Generate addresses for receiving funds Watch the blockchain for incoming UTXOs Display balances You cannot: Sign transactions (no privkeys) Derive hardened children Use cases: Online merchant accepting payments Read-only mobile companion to a hardware wallet Block explorers indexing user activity
TERMINOLOGY_INDEX
BIP 32
Specification for hierarchical deterministic wallets. Defines master key derivation and CKD functions.
Master Seed
The 64-byte BIP39 seed at the root of the tree. Single backup that generates all keys.
Chain Code
32-byte extra entropy stored with each node. Required for child derivation.
Hardened Key
Child whose index ≥ 2³¹. Notation: i' or ih. Cannot be derived from xpub — protects parent if xpub leaks.
xpub / xprv
Extended public/private key. 78-byte structure encoded as Base58Check. Encodes a tree node.
INTERACTIVE — TRY IT YOURSELF
BIP32 / HD WALLETS
HD Wallets
BIP32 HD wallets derive an unlimited tree of keys from a single 512-bit seed using HMAC-SHA512. Each child key is derived from its parent key plus a 32-bit index. Indices 0–2³¹−1 are normal (derivable from parent xpub alone). Indices 2³¹–2³²−1 are hardened (require parent private key — can't be derived from xpub).
MASTER KEY DERIVATION
Feed the 512-bit seed into HMAC-SHA512 with key "Bitcoin seed". Left 32 bytes = master private key. Right 32 bytes = master chain code. The chain code is entropy that makes child derivation independent of the key alone.
SEED → MASTER KEYSpaste 64-byte seed hex
CHILD KEY DERIVATION (CKD)
Normal child: HMAC-SHA512(chain_code, pubkey || index_LE). Hardened child: HMAC-SHA512(chain_code, 0x00 || privkey || index_LE). Left 32 bytes added (mod n) to parent key = child key. Right 32 bytes = child chain code. The child's public key equals (IL + parent_privkey)·G.
CKD EXPLORER — DERIVE CHILDRENderive from master or any parent
HARDENED vs NORMAL — SECURITY MODEL
DERIVATION COMPARISON
HARDENED (index ≥ 2³¹)
Requires parent private key
Cannot derive from xpub alone
Compromise of child key ≠ compromise of siblings
Used for account levels (m/44'/0'/0')
Notation: 44' or 44ₕ
NORMAL (index < 2³¹)
Derivable from parent public key
xpub can generate child addresses
Compromise of child private key + parent xpub → parent private key!
Used for address indices (m/.../0/0)
Notation: 0 (no apostrophe)
The xpub watch-only risk: If an attacker knows your extended public key (xpub) AND a single normal child private key (e.g. from a signing device compromise), they can compute your master private key. This is why account-level paths use hardened derivation — it severs the mathematical link between xpub and the private key derivation chain.