HD Wallets (BIP32)

Early Bitcoin wallets were a bag of unrelated random keys. Every fresh address meant a new secret to back up, and a backup taken on Monday was already stale by Tuesday. BIP32 Hierarchical Deterministic (HD) wallets fixed this with one elegant move: derive every key, forever, from a single starting secret. Back up the seed once and you’ve backed up an infinite tree. This page builds that tree from the root down.

The core idea: deterministic from one seed

“Deterministic” means no randomness after the seed. Given the same seed, the derivation always produces the exact same sequence of keys, on any wallet software, anywhere. So:

ONE seed  ──BIP32──►  an unlimited, reproducible tree of keypairs

This is what makes a 12- or 24-word backup possible: the words encode the seed (covered in seed phrases), and the seed deterministically regenerates the whole tree. You never back up individual keys again — they’re all recomputable.

Parent → child derivation

BIP32 defines a function that takes a parent key plus an index and produces a child key. Each key in the tree actually carries two pieces: the key itself and a 32-byte chain code (extra entropy that flavors derivation so the tree isn’t predictable from the key alone). Together they form an extended key.

parent extended key  +  index i  ──HMAC-SHA512──►  child extended key

Run that repeatedly and you get a tree:

                          m  (master / root)
                          │
            ┌─────────────┼─────────────┐
          m/0           m/1           m/2          ...  (children)
            │
      ┌─────┼─────┐
   m/0/0  m/0/1  m/0/2   ...                       (grandchildren)

m is the master node derived straight from the seed. Every position in the tree has a path like m/0/1 — a series of indexes telling you exactly how to walk from the root to that key. The same path always lands on the same key.

xpub and xprv: extended keys

Each node can be exported as an extended key:

• xprv (extended private key) — contains the private key + chain code. With it you can derive every descendant private key, so it can spend. Guard it like the seed itself.
• xpub (extended public key) — contains the public key + chain code. With it you can derive every descendant public key (and thus every address) — but no private keys, so it cannot spend.

This split enables the killer feature: watch-only wallets.

   xprv  ─── derives all ───►  child PRIVATE keys  (can spend)
   xpub  ─── derives all ───►  child PUBLIC keys / addresses  (watch only)

Hand your xpub to a point-of-sale system, an accountant, or a web server and it can generate a fresh receive address for every customer and watch your balance — while being physically incapable of moving a single satoshi. The spending keys never touch that machine.

Why a fresh address per payment

Because one xpub can mint endless addresses for free, best practice is a new address for every receive. Reusing one address links all your payments together on the public ledger. New-address hygiene is a core privacy practice — see privacy & deanonymization.

Hardened vs non-hardened derivation

Here is the subtlety that trips up almost everyone — and it’s a genuine security boundary.

There are two derivation modes, distinguished by the index:

• Non-hardened (indexes 0 to 2³¹−1): the child can be derived from the public parent. This is what makes xpub useful — you can derive public children without any private key.
• Hardened (indexes 2³¹ and up, written with ' or h, e.g. 0'): derivation requires the private parent. You cannot derive a hardened child from an xpub alone.

Why does hardening matter? Because non-hardened derivation has a dangerous leak. The convenience that lets an xpub derive child public keys comes with a hidden trapdoor:

   parent xpub  +  ONE child PRIVATE key  ──►  parent xprv  (the whole subtree's spending power!)

If an attacker ever gets your xpub and a single non-hardened child private key, they can run the math backward and reconstruct the parent private key — and from there spend everything in that branch. Hardened derivation cuts this link: a hardened child’s private key reveals nothing about its parent, even paired with the parent xpub.

The practical rule

Use hardened derivation at the levels you’ll never want to expose alongside a leaked key — in practice the purpose', coin', and account' levels of a standard path are all hardened. The lower change and index levels stay non-hardened so a single xpub can still generate addresses for an account. This is why a standard path looks like m/84'/0'/0'/0/5 — hardened up top, non-hardened below. (See derivation paths.)

The gap limit

When restoring an HD wallet, software doesn’t know how many addresses you used. So it scans forward along m/.../0/0, m/.../0/1, m/.../0/2… looking for any with on-chain history. It stops after finding a run of consecutive unused addresses — typically 20. That run is the gap limit.

index:  0   1   2   3   4   5   6  ...  25  26
used?:  ✓   ✓   ✗   ✓   ✗   ✗   ✗  ...  ✗   ✗
                                  └──── 20 unused in a row → stop scanning

The trap: if you skip ahead and receive coins at, say, index 50 while indexes 5–49 stayed empty, a restoring wallet may stop at the gap and never find those coins — they look lost even though the key is in your seed. Just bump the gap limit and rescan and they reappear. The gap limit is purely a scanning convention, not a property of the chain.

Under the hood — what HMAC-SHA512 actually splits

The page said a parent key plus an index runs through HMAC-SHA512 to make a child. The detail worth seeing is how that 512-bit output is used: it’s cut exactly in half.

I = HMAC-SHA512(key = parent chain code, data = (parent key material) || index)
        │
        ├─ left 32 bytes  (IL)  → a number added to the parent private key (mod n) = child private key
        └─ right 32 bytes (IR)  → the child's chain code

Two consequences fall out of this. First, the chain code (IR) is the extra 256 bits of “flavoring” that mean a leaked public key alone can’t grind out children — you need the chain code as well. Second, the hardened vs non-hardened split lives right here: for a non-hardened child the data fed in uses the parent public key (so an xpub can derive it), while for a hardened child the data uses the parent private key (so an xpub cannot). That single choice of what goes into the HMAC is the entire security boundary the section above described.

The architect’s lens

Step back from the tree diagram and ask the five questions that turn an implementer into an architect:

• Why does it exist? To collapse a “bag of unrelated random keys” into one secret: a single seed deterministically grows an unlimited, reproducible tree, so you back up once and never again — the words encode the seed, the seed recomputes everything.
• What problem does it solve? Stale backups and the watch-only problem. The xpub/xprv split lets you publish an extended public key that mints endless receive addresses and watches balances while being physically incapable of spending — keys for a point-of-sale or web server that never touch spending power.
• What are the trade-offs? Determinism concentrates risk: one leaked seed is everything. Non-hardened derivation carries a real trapdoor — parent xpub + one non-hardened child private key reconstructs the parent xprv — which is exactly why a standard path is hardened up top (m/84'/0'/0') and non-hardened below (/0/5). And the gap limit (~20) means coins received past a long unused run can look lost after a restore.
• When is this the wrong design? When you specifically want unlinkable keys with no shared chain code — a separate seed per purpose isolates blast radius better than one tree. A single throwaway key also needs none of this machinery.
• What breaks if I remove it? You’re back to per-address backups that go stale daily, no watch-only servers (any address-generating machine would also need spending keys), and no portable derivation-path recovery across wallets.

The thread

How does this help untrusting strangers agree on one ledger? HD wallets don’t change consensus at all — every derived key is an ordinary key the network validates the usual way. What they change is the human side of trust-minimization: you can run a watch-only server exposed to strangers and attackers, generate unlimited receive addresses for untrusting counterparties, and still keep spending power air-gapped. The xpub/xprv split lets you publish exactly enough to participate in the ledger while withholding exactly enough to stay sovereign over your coins.

Check your understanding

1. What does “deterministic” mean here, and why does it make a one-time word backup sufficient?
2. What can a watch-only wallet do with an xpub, and what can it not do without the xprv?
3. Explain the failure mode that hardened derivation prevents (xpub + one child key → ?).
4. Why are the top levels of a standard derivation path hardened but the bottom levels not?
5. What is the gap limit, and how can it make real funds appear “lost” after a restore?

Show answers

1. “Deterministic” means no randomness after the seed — the same seed always produces the exact same sequence of keys, on any compatible software anywhere. So a one-time word backup suffices: the words encode the seed, and the seed recomputes the entire tree; you never back up individual keys again.
2. With an xpub a watch-only wallet can derive every descendant public key and address — generate fresh receive addresses and watch your balance. Without the xprv it has no private keys, so it cannot spend a single satoshi.
3. With non-hardened derivation, an attacker holding your parent xpub and a single non-hardened child private key can run the math backward to reconstruct the parent xprv, gaining the whole subtree’s spending power. Hardened derivation cuts this link: a hardened child’s private key reveals nothing about its parent.
4. The top levels (purpose', coin', account') are hardened so a leaked key can’t be combined with the xpub to reconstruct parent secrets. The lower change and index levels stay non-hardened so a single xpub can still derive an account’s addresses for watch-only use — hence paths like m/84'/0'/0'/0/5.
5. The gap limit (typically 20) is the run of consecutive unused addresses a restoring wallet scans before it stops. If you received coins at, say, index 50 while indexes 5–49 stayed empty, the restore may stop at the gap and never find them — they look lost although the key is in your seed. Bumping the gap limit and rescanning makes them reappear; it’s purely a scanning convention.