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.

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 you do with an xpub that you can’t do with it — and why is a watch-only wallet possible?
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?