Hardened versus unhardened derivation

Hardening is a boundary in your derivation path rather than a setting you toggle. BIP-32 was assigned on 11 February 2012 with unhardened derivation alone; private derivation for indices at or above 0x80000000 was added on 16 April 2013, and those keys were renamed hardened on 15 January 2014. Where that boundary falls decides how much of your wallet a shared extended public key hands over.

How it works

Unhardened derivation has one property that hardened derivation deliberately lacks, and BIP-32 records the difference as an algebraic identity. Write N() for neutering, the step that discards the private half of an extended key and keeps the 32-byte chain code. Across unhardened levels, N(m/a/b/c) equals N(m)/a/b/c, so neutering before you derive and neutering after you derive land on the same key. At a hardened level the rewrite breaks: N(m/a') cannot be turned into N(m)/a', because public derivation is defined only for non-hardened children and returns failure for anything else.

Mechanically the two modes differ by one field. Both key an HMAC-SHA512 with the parent's chain code and append the 4-byte index. The unhardened mode supplies the parent's compressed public key; the hardened mode supplies the parent's secret padded with a leading zero byte to the same 33-byte width. Nothing holding only an xpub owns that second input, so derivation stops at the boundary.

BIP-32 is unusually blunt about what unhardened keys fail to protect. Its security section lists two properties as absent rather than present: given a parent extended public key and a child public key, finding the index is not hard, and given that same parent extended public key plus any one unhardened child private key, recovering the parent extended private key is not hard either. The first costs you privacy. The second costs you the branch.

Where you see it

Unhardened levels are what make an extended public key worth exporting, and BIP-32 devotes a section to the sharing arrangements built on them. An auditor handed the account extended public keys sees every payment into and out of every account and not one secret key. Two firms that trade often can share the external chain of a single account as a standing address to pay into, so neither has to request a fresh one for each transfer. A webshop can hand the same kind of key to its web server, which then generates receiving addresses it has no power to spend from.

The layout that puts the boundary at the account level is advice, not rule. BIP-32 calls its master, account, chain and subchain structure advisory only and tells implementations they may deviate for specific needs, which is why one compliant wallet can harden more levels than the compliant wallet beside it.

One interoperability trap is worth knowing, because the specification was patched for it twice. Test vectors covering hardened derivation with leading zeros were added on 24 February 2017 and again on 4 November 2020. The hardened input is fixed at 33 bytes, a zero byte followed by the 32-byte secret, so software that trims a leading zero instead of holding that width hashes different data, produces a different branch, and finds an empty wallet when someone restores that seed in another program. Unhardened derivation never meets the bug, because a compressed public key always begins with 0x02 or 0x03 and so has no leading zero to lose.