Hardened derivation

Every node in a BIP-32 tree can produce 4,294,967,296 children, and the upper half of that range behaves differently. Indices from 2,147,483,648 onward are hardened, written with an apostrophe or the letter h, and no public key can derive them. That restriction is the feature, not a shortcoming.

How it works

Hardened and normal derivation differ by one input to the same hash. Both feed a parent's chain code and a child index into HMAC-SHA512. Normal derivation adds the parent public key, which anyone holding the extended public key already has. Hardened derivation adds the parent private key instead, prefixed with a zero byte, so the calculation cannot be performed without the secret.

The reason is a specific weakness BIP-32 spells out in its security notes: knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key, and therefore every key below that point. The arithmetic behind it is simple. A normal child private key equals the parent key plus a value computed from public information, so subtracting that value recovers the parent.

Hardened indices close the route. There is no public derivation function for them, so an extended public key stops dead at the boundary. A leaked xpub for one account exposes that account's history and nothing above it or beside it.

Where you see it

Hardening shows up as the apostrophes in a derivation path, and where they fall is a deliberate design decision.

The standard native SegWit path is m/84'/0'/0'/0/0. The first three levels, purpose, coin type and account, are hardened. The last two, chain and address index, are not. That split is exactly what makes a watch-only wallet workable: an account extended public key can generate every receiving and change address underneath itself, while an attacker who obtains that same xpub cannot climb toward the master key or step sideways into m/84'/0'/1'.

Notation varies without changing anything. BIP-32 writes 0', many tools accept 0h, and Bitcoin Core writes h in the descriptors it exports because an apostrophe needs escaping inside JSON. A path copied from Sparrow into Core comes back rewritten in the h form, which alarms people the first time and is purely cosmetic.

The practical rule is short. Harden every level down to the account, leave the two levels below it unhardened so watch-only tools keep working, and treat any software offering to export a single non-hardened child private key as a hazard rather than a convenience, because that export combined with your xpub is the whole branch.

Hardened derivation vs a passphrase

Hardened derivation is automatic; a BIP-39 passphrase is a secret you choose. They get grouped together as ways of hardening a wallet and they address unrelated problems. Hardening protects a tree against an extended public key that escaped, and every standard wallet already applies it without asking you. A passphrase is an extra input mixed into the seed before the tree is built at all, producing a completely separate wallet from the same twelve or twenty-four words. Forget the passphrase and the coins are unreachable, because nothing anywhere records it. Forget about hardening and nothing happens, because you were never the one deciding it.