LibraryPrivacy2012Design paperCorpus record
Hierarchical Deterministic Wallets
BIP 32. Pieter Wuille.
A master secret derives a tree of child keys. A parent public key can derive child public keys on non-hardened paths, so a server can issue addresses without the private key.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
A custody design should say which branches are hardened, and what a leaked child key reveals.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 3
- Records linked
- 6
Code
Source, repository, and what is actually hosted
- BIP 32https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
- bitcoin/bipsRepository taken from the source URL. 97 other studies in this library cite the same repository. This is not an audit.
- Full upstream textMirrored 2026-10-10 under BSD-2-Clause. The desk study is not part of that licence.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
The defect
A fresh key for every payment is good privacy and a terrible backup, unless the keys are derived from one seed.
Claim 02 · Paper model
The rule
A master secret derives a tree of child keys. A parent public key can derive child public keys on non-hardened paths, so a server can issue addresses without the private key.
Claim 03 · Paper model
How it is put together
One seed is the backup. Hardened children cannot be derived from the parent public key. Non-hardened children can, and a leaked child private key plus the parent public key leaks the parent.
Claim 04 · Paper model
Where the claim stops
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 The defect
02 The rule
Observation
What the study says
A master secret derives a tree of child keys. A parent public key can derive child public keys on non-hardened paths, so a server can issue addresses without the private key.
Model
What has to hold
A non-hardened leak is worse than it looks.
03 How it is put together
Observation
What the study says
One seed is the backup. Hardened children cannot be derived from the parent public key. Non-hardened children can, and a leaked child private key plus the parent public key leaks the parent.
Model
What has to hold
A non-hardened leak is worse than it looks.
04 Where the claim stops
03 Sequence
One action, as an operating tape
- 01Derive a child by hashing the parent key with an index.
- 02Give a watch-only server the parent public key.
- 03Keep hardened branches for keys the server must not be able to expand.
- 04Is the branch hardened?
04 Load-bearing
The argument, and where a pitch drops it
Why it is still on the desk
The cut
A custody design should say which branches are hardened, and what a leaked child key reveals.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A non-hardened leak is worse than it looks.
After the text
The cut
Almost every hardware wallet ships this. The leak condition is the part that still surprises teams.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A later client, parameter or reward formula is a different object from this paragraph.
05 Register
What has to be true
06 Divergence
What happened after the paper
Almost every hardware wallet ships this. The leak condition is the part that still surprises teams.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 3 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it names
A fresh key for every payment is good privacy and a terrible backup, unless the keys are derived from one seed.
What the design proposes
- One seed is the backup.
- Hardened children cannot be derived from the parent public key.
- Non-hardened children can, and a leaked child private key plus the parent public key leaks the parent.
How the mechanism is specified
- Derive a child by hashing the parent key with an index.
- Give a watch-only server the parent public key.
- Keep hardened branches for keys the server must not be able to expand.
What this page does not treat as proven
Why the desk still reads it
A custody design should say which branches are hardened, and what a leaked child key reveals.
09 Lexicon
Terms, opened into the record
- Hardened derivation
- A child that cannot be computed from the parent public key.
- xpub
- An extended public key that can derive a non-hardened branch.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
Upstream
The file, in full
Licence recorded on the mirror: BSD-2-Clause. Canonical file: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki. Numbers and web addresses in the file open a study or the address itself.
Loading the mirrored file.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.