Until 2012, backing up a wallet was a never-ending task. The original program stored one hundred ready keys in a file and used one at a time; after the hundredth, the backup made on the first day no longer contained the new keys, and those who relied on it found out the hard way. Solving this problem is the reason for the existence of the twelve words.
The proposal came in February 2012, from Pieter Wuille, and is called BIP-32. The idea is simple to state: instead of drawing each key, a single seed is drawn, and all others are derived from it, always following the same path. A backup made today is valid for keys ten years from now because they are already determined — they just haven't been calculated yet.
The first step takes the 512-bit seed from the previous lesson and passes it through HMAC-SHA-512. Sixty-four bytes come out, cut in half: the thirty-two on the left are the master private key, and the thirty-two on the right are something new, the chain code. This second piece is what prevents knowing one child key from revealing anything about the siblings.
Deriving a child is a single calculation: combine the two, add the child's number, pass through the same function. A new private key and a new chain code come out, ready to generate grandchildren. It's a tree of billions of keys where any branch is recalculable from the seed, and none need to be stored.
From this structure comes the most useful piece of all, the extended key. The private version is written as xprv and derives everything. The public version is written as xpub and derives only public keys — addresses, therefore — without any ability to spend. A store can install the xpub on the server, generate a new address for each customer, and not have anything within that machine that allows moving a coin.
This convenience demands a precaution. An xpub reveals all the addresses that account will ever have, forever, and therefore the entire history and balance. It doesn't spend, but it tells all. Sending an xpub to someone is like opening the entire statement, and there's no way to close it afterward.
There is also a real mathematical trap, and that's where the apostrophe in derivation paths comes from. In common derivation, anyone with a parent's xpub and a single child private key can deduce the parent's private key — and with it, the entire family. Hardened derivation cuts this path back: it uses the parent's private key in the calculation, and therefore an xpub simply cannot produce hardened children.
Now the path is no longer a mystery. In m/84'/0'/0'/0/5, the m is the root. The 84 with an apostrophe is the purpose, which indicates which address pattern will be used and is the subject of the next lesson. The following 0 is the currency, and Bitcoin is zero. The third number is the account, which allows separating personal finances from business ones within the same seed. The first three levels are always hardened, precisely for the reason mentioned in the previous paragraph.
The last two are not, for a practical reason. The fourth level is 0 for addresses you give to those who will pay you and 1 for change addresses, which the wallet creates on its own; the fifth is a counter that increments by one. Since these two levels are common, the account's xpub calculates all of them — which is what the store in the example needs.
A daily detail closes the lesson. When restoring a seed, the wallet does not scan the entire tree: it searches the addresses in order and stops after finding twenty in a row without any movement. This limit of twenty is a convention, and anyone who manually generated an address far ahead of the counter might see the money disappear from the screen without having disappeared from the blockchain.
What's left to explain is the first number of the path, the so-called purpose. It's what decides if the same seed will show addresses starting with 1, with 3, or with bc1 — and why two honest wallets display different balances for the same twelve words. In the next lesson, patterns 44, 49, 84, and 86.