MASTERING-BITCOIN · Interactive Practice | Unit 5 · Video 7
| Concept | Notation | Meaning |
|---|---|---|
| Master private key | Root of the HD wallet tree | |
| Master public key | Public counterpart — can derive public keys only | |
| BIP44 standard path | Five fixed levels for multi-coin HD wallets | |
| Hardened derivation | prime mark (e.g. ) | Breaks parent-xpub → child-xpub link (more secure) |
| Normal derivation | no prime (e.g. , ) | Allows xpub to derive child public keys |
| Gap limit | (typically 20–100) | Max consecutive unused addresses the wallet will scan |
Coin types: = Bitcoin, = Ethereum. Change: = receive, = internal change. Indices start at 0.
Conceptual question: How do the five levels of a BIP44 path combine into a unique address coordinate?
Use the controls below to construct a derivation path. Watch how the tree highlights change, and read the "plain English" translation at the bottom.
⚙ interactive visualization — coming to this page format soon
Notice: The first three levels are always hardened (red, prime-marked). Changing the account level creates completely isolated branches — moving from account 0 to account 3 is like opening a new set of books. Changing the index just walks forward along a single branch and is derivable from an exported xpub.
Conceptual question: What happens when a payment arrives beyond the wallet's scan window?
Adjust the gap limit (how far the wallet scans past the last used address) and the payment index (which address the customer paid). Green = paid, grey = empty, dashed box = scan window. If the payment lies outside the window after a restore, the wallet will miss it.
⚙ interactive visualization — coming to this page format soon
Reflect: Set the gap limit to 20 (the common default) and move the payment index past 20. The wallet sees 20 empty addresses in a row, stops scanning, and treats everything further as "not my wallet" — even though those funds are provably yours on-chain. The only fixes are: a larger gap limit, throttled invoice generation, or address reuse (which leaks privacy).
Conceptual question: What can an attacker do if they steal the xpub from your web server versus the xprv from your hardware wallet?
Toggle the credential that the attacker has compromised and see which capabilities they gain.
⚙ interactive visualization — coming to this page format soon
Notice: Under an xpub compromise, the "✅" marks (attacker capabilities) are actually bad for the store owner — green was reserved for "attacker cannot do this." The scariest row, "sign transactions," is only reachable with the xprv. This asymmetry is exactly what makes watch-only BTCPay deployments safe.
Question 1 · Reading a BIP44 Path
Consider the derivation path:
Which plain-English description matches this path?
✅ Correct! Account index 2 is the third account, and change = 1 means internal change.
❌ Not quite. Remember: indices start at 0 (so index 2 = 3rd), coin type is Bitcoin, and change = 1 is the internal change branch (not receive).
Solution:
Read the levels left-to-right after :
So this is the 8th change address of the 3rd Bitcoin account.
Question 2 · Hardened vs Normal Derivation
Gabriel exports an account-level extended public key (xpub at ) and pastes it into his BTCPay server. An attacker later steals that xpub from the server.
True or False: The attacker can derive the private keys for every receive address under that account and drain the wallet.
✅ Correct! The xpub is a receive-only credential. The attacker can redirect future payments, but cannot sign transactions or touch funds already received.
❌ Not quite. The xpub derives only public keys — that is its defining property. Without the xprv (which never leaves the Trezor), no signing is possible.
Solution:
The answer is False.
An xpub is a public key — it can derive only child public keys (and therefore addresses), not private keys. This is exactly the point of the xpub/xprv split:
This separation of powers (xpub = receive credential, xprv = spend credential) is what makes watch-only deployments like BTCPay Server viable.
Question 3 · The Gap Limit Failure Mode
Gabriel's store generates addresses at indices 0 through 59, but no customer pays any of them. A payment then arrives on address index 60. His server crashes; he restores the wallet from his seed phrase on a fresh install with the default gap limit of 20.
What happens?
✅ Correct! The gap limit is a scan-ahead window, not a hard generation limit. Once the wallet sees 20 empties in a row, it stops — and index 60 is invisible.
❌ Not quite. The payment is not lost from the blockchain — Gabriel still owns those satoshis. The problem is that his restored wallet cannot see them, because it stopped scanning after 20 consecutive empty addresses.
Solution:
The correct answer is: the wallet scans indices 0-19, sees 20 consecutive empty addresses, stops, and silently misses the payment on index 60.
On restore, the wallet has no memory of which addresses were previously handed out — it only has the seed. It walks the derivation tree looking for used addresses, and the gap limit tells it how many consecutive empty addresses it will tolerate before concluding the rest of the branch is unused.
With :
Indices 20-59 are never even checked, and neither is index 60 where the payment lives. The funds are still on the blockchain and still controlled by the seed — but the wallet has no idea they exist.
The three operational choices:
BTCPay Server mitigates this with a large gap limit combined with throttled invoice generation — a tuned operational tradeoff, not a mathematical fix.
Question 4 · Why Five Fixed Levels?
BIP44 mandates exactly five levels in a fixed order: .
What is the primary reason for standardizing this structure across wallets?
✅ Correct! Standardization is what lets one seed phrase work across every compliant wallet — the whole value of BIP44.
❌ Not quite. BIP44 is a standardization proposal, not a cryptographic or consensus rule. Its purpose is interoperability between wallets that share a seed.
Solution:
The correct answer is: seed portability.
HD wallets technically support unlimited depth — you could invent any tree shape you wanted. But if every wallet vendor chose a different layout, a user restoring the same seed on Trezor vs Ledger vs Electrum would see three different sets of addresses and three different balances.
BIP43 solves half the problem by reserving the first hardened level to declare the tree's purpose (i.e., which standard is being used).
BIP44 then pins down a specific five-level layout for multi-coin HD wallets:
Every compliant wallet walks this exact tree, so a single seed phrase produces the same addresses everywhere. That interoperability is the whole point.
Why the other options are wrong:
Solved: 0 / 4