From words to keys

How a wallet finds your coins starts from a sentence worth stopping at: your words encode a number, and "a defined procedure produces a master key". This page is that procedure. It is four transformations, each of which explains a behaviour you have probably already met and found arbitrary.

None of this is required to use a wallet safely. It is required to diagnose one — because every silent failure in self-custody happens at one of these four steps, and knowing which one narrows an afternoon of guessing to a single question.

1The words are a number in a costume

The BIP39 wordlist holds exactly 2,048 words. That number is not aesthetic. 2,048 is 2¹¹, so each word stands for precisely eleven bits, and a phrase is nothing more than those bits laid end to end.

Twelve words is therefore 132 bits. But a 12-word wallet is described everywhere as 128-bit security, and the gap is the point of this section: 128 bits are your secret, and the last 4 are a checksum computed from them.

The checksum is the first bits of the SHA-256 hash of your entropy — one checksum bit for every 32 bits of secret. That is the whole rule, and it is why the counts above are the only legal phrase lengths. Thirteen words is not a longer phrase; it is not a phrase.

2What the checksum actually catches

The checksum is a genuine error detector, and it is worth knowing its strength precisely, because the folklore around it points people at the wrong suspect when a restore goes wrong.

Change anything about your phrase — a misread word, two words swapped — and the entropy bits change. The checksum recomputed from those new bits then has to coincidentally match the checksum bits already sitting at the end. For a 12-word phrase there are 4 such bits, so the odds of an accidental match are 1 in 16. For 24 words there are 8, so 1 in 256.

• A 12-word phrase catches a scrambled or misread word about 94% of the time. Roughly one error in sixteen slips through as a valid but different wallet.
• A 24-word phrase catches it about 99.6% of the time. One in 256 slips through.
• It cannot catch anything at all once the phrase is valid. A checksum says the words are internally consistent. It says nothing about whether they are your words.

What follows from this is narrower than it first appears. If your wallet accepted the phrase and showed you an empty balance, the checksum has ruled out most transcription errors. It has not ruled out the one in sixteen that produces a different valid wallet, and it never had anything to say about a wrong passphrase, a wrong branch or a scan still in progress. Those are the causes no checksum can see, and they are the subjects of the next two sections.

A handwritten seed card face down on a desk beside an open notebook, the notebook showing a column of hand-written eleven-digit binary numbers, one per line, in the same pen.

Image to come

3The words are not the seed

Here is the step most people skip, and it is the one that explains passphrases.

Your phrase is not fed to the wallet directly. It is put through PBKDF2 — a deliberately slow key-stretching function — running 2,048 rounds of HMAC-SHA512, and what comes out is a 512-bit seed. The phrase is the password. And the salt, the other input, is the literal string mnemonic with your passphrase appended to it.

Three consequences fall straight out of that construction, and each is a thing people discover the hard way.

A passphrase cannot be wrong

Because the passphrase is part of the salt rather than something checked against a stored value, there is nothing to compare it to. Every passphrase produces a valid 512-bit seed, and therefore a real, working, completely different wallet. BIP39 says so directly: every passphrase generates a valid seed, but only the correct one makes the desired wallet available.

This is the mechanism behind the symptom. A mistyped passphrase cannot produce an error message, because from the software's point of view nothing went wrong — you asked for a different wallet and it built one, correctly, and it is empty. A trailing space, a capital letter, a different Unicode dash: each is a separate wallet, silently.

The wordlist is part of the input

PBKDF2 hashes the text of the phrase, not the numbers behind it. So the same twelve concepts written in the English and Japanese wordlists produce entirely unrelated seeds. The specification is blunt about it: translating a mnemonic to a different wordlist necessarily creates a completely different seed. Record the language along with the words.

2,048 rounds is a speed bump, not armour

Worth saying plainly, because passphrase advice often implies otherwise. 2,048 iterations is a very low work factor by modern standards — password hashing schemes designed for the job use orders of magnitude more. If someone holds your recovery words and is guessing at the passphrase, that stretching buys you very little.

A passphrase protects you because it is long and unguessable, not because the derivation is expensive. Treat a short memorable passphrase on top of a compromised seed card as a delay, not a defence — which is the argument the passphrase guide makes from the practical side.

4The seed becomes the root of the tree

The 512-bit seed is hashed once more, and this is where the tree in the previous guide actually begins. The seed is run through HMAC-SHA512 keyed with the fixed string Bitcoin seed, and the 64 bytes that come out are cut in half:

• The left 32 bytes become the master private key. This is the number everything else descends from.
• The right 32 bytes become the master chain code. Extra entropy mixed into every child derivation, so that knowing a key is not enough to derive its siblings.

A key plus its chain code is what an extended key means — the "x" in xprv and xpub. That pairing is what makes a whole branch derivable from one string, and it is what the next section is about.

5The apostrophe, and why it is a security control

You have seen a path written m/84'/0'/0'/0/0. Three of those numbers carry an apostrophe and two do not, and the difference is not decorative — it is the most consequential detail on this page.

Each extended key can produce two kinds of child. Normal children use indexes 0 through 2³¹−1. Hardened children use the range above that, and the apostrophe (sometimes written h) is shorthand for "add 2³¹". The two are derived by different procedures, and only one of them can be performed with a public key.

The leak is the reason hardened derivation exists, and BIP32 flags it as a weakness that is not immediately obvious. Stated plainly:

Anyone holding an extended public key and a single normal child private key descending from it can compute the parent private key — and from there every key in that branch.

Read that as an operational rule rather than a curiosity. An xpub is not secret, and it gets handed out: to a watch-only phone, a coordinator, a block explorer. A private key for one address is a much smaller thing, and people are correspondingly casual with them — sweeping a single address into another wallet, exporting one key for a payment processor, pasting one into a tool. On their own, each is survivable. Together, in the same branch, they reconstruct the branch.

Which is why the path is shaped the way it is

Look again at m/84'/0'/0'/0/0 with that in mind, and the design stops looking arbitrary:

• Purpose, coin and account are hardened — 84'/0'/0'. The account is the boundary you are allowed to export. Hardening it means an account xpub reveals that account and can never be walked upward into your master key or sideways into your other accounts.
• Change and index are not — /0/0. They deliberately stay normal, because that is precisely what lets a watch-only wallet hold only an xpub and still generate every future receiving address without ever seeing a private key.

The tree is drawn so that the cut line is the account. Everything above it is sealed; everything below it is publicly derivable on purpose. That single decision is what makes air-gapped signing and watch-only wallets possible at all.

What it costs you in practice

One habit follows from the leak, and it is cheap: do not export individual private keys out of an HD wallet whose xpub is anywhere else. If you need to move one address's coins somewhere, spend them in a transaction rather than exporting the key. Sweeping a single key from a wallet you have shared the xpub of is the exact shape of the attack.

6Same key, different hats: xpub, ypub, zpub

Restore a wallet and you may be handed a string starting zpub where you expected xpub, or asked which one you have. This causes a great deal of confusion for something that is, underneath, cosmetic.

An extended key is serialised with four leading version bytes. SLIP-132 registered alternative values for those bytes so that the human-readable prefix would announce the intended address type — xpub for legacy, ypub for wrapped SegWit, zpub for native SegWit, with capitalised Ypub and Zpub for the multisig equivalents.

• The key material is identical. A zpub and an xpub for the same node differ only in four bytes of packaging; converting between them changes no keys and moves no coins.
• It is a registry, not a Bitcoin standard. SLIP-132 exists because a bare xpub could not say which address type was meant, and it describes itself as an interim measure pending descriptors.
• Plenty of software only speaks xpub. Bitcoin Core among them. Being told your zpub is invalid usually means the receiving software wants the same key in xpub clothing plus an explicit derivation path.

This is the problem output descriptors were designed to end. A descriptor states the script type, the key and the path in one unambiguous string, so nothing has to be inferred from a prefix — which is why the previous guide tells you to save the descriptor rather than the path.

7Where each failure actually lives

A symptom narrows the search. It rarely settles it on its own, because several of these steps fail the same way. An empty wallet looks identical whether the passphrase is wrong, the branch is wrong, or the scan has not finished. So the table below gives the checks rather than a verdict, and they are worth running in order.

Which is the honest summary of the whole table. Most of these symptoms are the software being pointed somewhere else, and pointing it correctly is a matter of an afternoon. But two rows are not: losing any secret the wallet actually requires, whether the words or the passphrase or both, can end recovery permanently. A checksum-valid phrase that is not yours is exactly as unrecoverable as a forgotten passphrase, and neither is a settings problem. That is the argument for treating a passphrase as a second irreplaceable secret rather than a convenience, and for treating the words as the first.

The short version

Words carry eleven bits each, with the tail end spent on a checksum that catches most transcription errors and no wrong-wallet errors at all. Those words plus a passphrase are stretched into a 512-bit seed, which is hashed into a master key and chain code. The apostrophes in the path mark where the tree is sealed, so that an account can be published as an xpub without publishing everything above it — and the segments without apostrophes are what let a watch-only wallet work.

Everything downstream is bookkeeping on top of those four steps.

The mechanics here are drawn from the specifications rather than from any wallet's behaviour: BIP39 for the checksum and the PBKDF2 construction, BIP32 for master key generation and hardened derivation, and SLIP-132 for the version-byte prefixes. Where a wallet appears to disagree with this page, the wallet is what your coins obey.