Skip to content
Blockchain LabTHE VENTURE STUDIO

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.

The five-minute read

The defect

A fresh key for every payment is good privacy and a terrible backup, unless the keys are derived from one seed.

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.

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.

Where the claim stops

BIP 32 is not BIP 39. The mnemonic is separate.

One action, walked through

  1. Derive a child by hashing the parent key with an index.
  2. Give a watch-only server the parent public key.
  3. Keep hardened branches for keys the server must not be able to expand.
  4. Is the branch hardened?

The argument, unpacked

Why it is still on the desk

A custody design should say which branches are hardened, and what a leaked child key reveals.

After the text

Almost every hardware wallet ships this. The leak condition is the part that still surprises teams.

What has to be true

  • BIP 32 is not BIP 39. The mnemonic is separate.
  • A non-hardened leak is worse than it looks.
  • The tree does not hide the transaction graph.

What happened after the paper

Almost every hardware wallet ships this. The leak condition is the part that still surprises teams.

What to check before you use the idea

  • Is the branch hardened?
  • What does a leaked child private key plus the parent xpub reveal?
  • Where is the master seed held?

Terms

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.

The problem the paper 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

  • BIP 32 is not BIP 39. The mnemonic is separate.
  • A non-hardened leak is worse than it looks.
  • The tree does not hide the transaction graph.

Why a venture studio still reads it

A custody design should say which branches are hardened, and what a leaked child key reveals.

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.