BIP-0032: Hierarchical Deterministic Wallets

BY KEYHUNTER 09.09.2026
BIP-0032: Hierarchical Deterministic Wallets

Pieter Wuille  · Bitcoin Improvement Proposal 32 · 2012 Research Paper: Cryptographic Construction, Threat Model, and Cryptanalytic Implications

BIP-0032 defines the basic design of hierarchical deterministic wallets (HD Wallets): a tree of extended private and public keys is constructed from a single secret seed. The master key and 256-bit chaincode are derived using HMAC-SHA512 with a key of  "Bitcoin seed"; child nodes are then derived through separate private and public derivation functions.

The standard’s key cryptanalytic fact is that, with  non  -hardened derivation, compromising the parent’s extended public key and any private key of its descendant allows for algebraic recovery of the parent’s private key. This property explains the need for hardened boundaries and the practice of placing them at the destination, coin type, and account levels in modern BIP-44/49/84/86 schemes.

1. Status and subject of the standard

BIP-0032 was published on February 11, 2012, as an informational BIP with a  Final status . It standardizes the key derivation mechanism, extended key serialization, masternode creation, and a recommended, but optional, wallet structure.

The standard solves two cryptographic engineering problems: backups are replaced by storing a single, sufficiently entropic seed; the public portion of the tree can be delegated to an observing system without transferring signature rights. The second property was particularly important for online stores: the server issues new addresses, while the spending keys remain in an isolated environment.

2. Mathematical model

The work is carried out in a group of points on an elliptic curve of order secp256k1  n with a base point  G. The private key is a scalar  k in the range  1..n-1, and the public key is a point  K = kG. Operations with keys are performed modulo the order of the group.

\[ K = \operatorname{point}(k) = kG, \qquad k \in \{1,\ldots,n-1\}. \]

BIP-0032 notation:   — 4-byte big-endian representation of the index;   — 32-byte representation of the scalar;   — compressed SEC1 serialization of the point. For a compressed key, this is a byte   or  , depending on the parity of the coordinate  , and 32 bytes of the coordinate  .ser32(i)ser256(k)serP(K)0x020x03yx

Cryptanalytic context.  The security of the correspondence  K = kG relies on the hardness of the ECDLP problem in the secp256k1 group. In an idealized model, the best general approach requires on the order of \(2^{128}\) group operations (Pollard’s rho algorithm), rather than trying \(2^{256}\) scalars.

Historical example: why secp256k1 was chosen

Bitcoin initially used secp256k1, standardized by the SEC. Later, the highly audited , , emerged in the Bitcoin ecosystem  libsecp256k1, and BIP-340 enshrined the Schnorr signature scheme on the same curve. BIP-0032 does not create a new cryptographic primitive: it builds a deterministic composition around an already chosen group and HMAC-SHA512.

3. Extended Keys

The regular key is supplemented by a 32-byte chain code. The extended private key is the pair \((k,c)\); the extended public key is \((K,c)\), where \(K=kG\). The chain code is not a private key and does not sign transactions, but it is a secret/sensitive derivation context: together with the key material, it defines the entire child subtree.

\[ xprv \equiv (k,c), \qquad xpub \equiv (K,c), \qquad K=kG. \]

Child categoryIndexPossibility to get from xpubPurpose
Normal / non-hardened\(0 \le i < 2^{31}\)YesObservable address chains, watch-only
Hardened\(2^{31} \le i < 2^{32}\)NoCryptographic branch isolation

For brevity, the hardened index \(i+2^{31}\) is written as \(i’\), or in practical ways as  i',  iH or  . Each extended node has \(2^{31}\) normal and \(2^{31}\) hardened children.iH

4. Generating a master node

The seed  S must be generated by a cryptographically secure random number generator. BIP-0032 allows for a length of 128–512 bits and recommends 256 bits. HMAC-SHA512 is calculated from the seed once, with the domain-separated string  Bitcoin seed serving as the HMAC key.

\[ I = \operatorname{HMAC\!\text{-}\operatorname{SHA512}(\text{key}=\texttt{“Bitcoin seed”},\,\text{data}=S), \] \[ I = I_L \parallel I_R, \quad |I_L|=|I_R|=256\ \text{bit}, \quad k_m=\operatorname{parse}_{256}(I_L), \quad c_m=I_R. \]

If \(k_m=0\) or \(k_m\ge n\), the master key is invalid; the seed must be replaced. The probability of this happening is extremely low, since the order of secp256k1 is almost equal to \(2^{256}\).

Practical example

The BIP-39 mnemonic often serves not as a direct input to BIP-0032, but as a mechanism for a human-readable backup representation: PBKDF2-HMAC-SHA512 converts the mnemonic and optional passphrase into a 512-bit seed, after which the given BIP-0032 formula is applied. It’s important not to confuse these levels: BIP-39 defines the mnemonic and seed derivation, while BIP-0032 defines the key tree from the seed.

5. CKDpriv: Private Derivation

The function   receives the child’s extended private key. For the hardened branch, the parent’s private key with a zero prefix is ​​passed to HMAC; for the normal branch, the parent’s compressed public key is passed. In both cases, the index is always encoded as a 4-byte value.CKDpriv((kpar, cpar), i)

\[ \text{If }i \ge 2^{31}:\quad I=\operatorname{HMAC\!\text{-}\operatorname{SHA512}(c_{par},\ 0x00\parallel \operatorname{ser}_{256}(k_{par})\parallel\operatorname{ser}_{32}(i)). \] \[ \text{If }i < 2^{31}:\quad I=\operatorname{HMAC\!\text{-}\operatorname{SHA512}(c_{par},\ \operatorname{ser}_P(K_{par})\parallel\operatorname{ser}_{32}(i)). \] \[ I=I_L\parallel I_R,\qquad k_i=(\operatorname{parse}_{256}(I_L)+k_{par})\bmod n,\qquad c_i=I_R. \]

A node is invalid if \(\operatorname{parse}_{256}(I_L)\ge n\) or \(k_i=0\); the implementation must move on to the next index. BIP-0032 estimates the probability of this case to be less than \(2^{-127}\), but correct handling is required for inter-implementation compatibility.

Test vector from BIP-0032

For a seed,  000102030405060708090a0b0c0d0e0f the standard publishes a master extended private key starting with  xprv9s21ZrQH143K3..., followed by the values ​​at the paths  m/0',  m/0'/1,  m/0'/1/2' and so on. Such vectors are not an illustration of a “real wallet,” but a regression oracle: any library must reproduce them byte-for-byte.

6. CKDpub: public derivation

This function   is defined only for normal indices. It uses the same HMAC input as the normal variant of CKDpriv and appends the left half of the HMAC result to the parent’s public endpoint.CKDpub((Kpar,cpar),i)

\[ I=\operatorname{HMAC\!\text{-}\operatorname{SHA512}(c_{par},\operatorname{ser}_P(K_{par})\parallel\operatorname{ser}_{32}(i))=I_L\parallel I_R, \] \[ K_i=\operatorname{point}(\operatorname{parse}_{256}(I_L))+K_{par},\qquad c_i=I_R. \]

If the index is hardened, CKDpub returns an error. Cases such as \(\operatorname{parse}_{256}(I_L)\ge n\) or obtaining a point at infinity are also invalid. When importing xpub, the implementation is responsible for verifying that the serialized public key actually specifies a secp256k1 point.

Algebraic identity

For a normal descendant, private and public derivations are consistent:

\[ \begin{aligned} N(\operatorname{CKDpriv}((k_{par},c_{par}),i)) &=(k_{par}+\operatorname{parse}_{256}(I_L))G\\ &=K_{par}+\operatorname{parse}_{256}(I_L)G\\ &=\operatorname{CKDpub}(N(k_{par},c_{par}),i). \end{aligned}\]

It is this equality that enables watch-only functionality. For example, an online store stores the xpub of an external branch and outputs a new order address using the index  k, while an offline device with xprv outputs the same private key only when it needs to spend funds.

7. Cryptanalytic fact: xpub plus descendant

The key limitation of BIP-0032 is  that the extended public key of the parent \((K_{par},c_{par})\) plus the private key of any of its known normal descendants \(k_i\) and the index \(i\) reveals the private key of the parent. This is not an attack on SHA-512 or ECDLP; it is a direct consequence of the linear normal derivation formula.

\[ I_L=\operatorname{left}_{256}(\operatorname{HMAC\!\text{-}\operatorname{SHA512}(c_{par},\operatorname{ser}_P(K_{par})\parallel\operatorname{ser}_{32}(i))), \] \[ \boxed{\quad k_{par}=(k_i-\operatorname{parse}_{256}(I_L))\bmod n.\quad} \]

Armed with the recovered \(k_{par}\) and the already known chaincode from xpub, the attacker obtains all private subtree keying material of this node, including all normal and hardened descendants below it. However, they cannot ascend past the hardened boundary, since the HMAC input at this step requires the private key of the upstream node, which xpub does not reveal.

Historical and operational example

Early and modern integrations often use xpub for server-side deposit address creation. If the same server, backup, browser extension, or debug log obtains a private key from an unhardened branch under this xpub, the “server cannot spend” protection disappears: a compromise becomes a complete compromise of the subtree. This is the well-known reason why BIP-44 sets hardened boundaries above address chains, and private keys for addresses cannot be shared with systems that own the corresponding ancestor xpub.

Threat differentiation.  The xpub key itself doesn’t allow for the derivation of private keys: this would still require solving ECDLP. The vulnerable combination is precisely  the parent’s xpub key + the normal child’s private key + index . Similarly, a single normal child public key without the chain code prevents the parent’s key from being recovered.

8. Hardened derivation as a barrier

In the hardened branch, HMAC obtains the secret \(k_{par}\) rather than the public \(K_{par}\). Therefore, from the parent’s xpub, it is impossible to even calculate the intermediate \(I_L\) needed to obtain the child, much less invert the expression for the parent scalar.

\[ \text{Hardened: }\quad I=\operatorname{HMAC\!\text{-}\operatorname{SHA512}(c_{par},0x00\parallel\operatorname{ser}_{256}(k_{par})\parallel\operatorname{ser}_{32}(i)). \]

The compromise of the hardened approach is functional, not cryptographic: xpub cannot be used to generate addresses below the hardened step. Therefore, a well-designed tree places hardened boundaries between independent risk areas, and leaves the address branches as normal when server-side address generation is required.

9. Tree and path notation

The root is designated  m for both the private tree and  M=N(m) its public view. The path  m/3'/2/5 represents the sequential application of CKDpriv: first hardened index 3, then normal indexes 2 and 5.

\[ N(m/a/b/c)=M/a/b/c\quad\text{only if all }a,b,c\text{ normal}, \] \[ N(m/a’/b/c)=N(m/a’)/b/c,\qquad M/a’\text{ undefined}. \]

Each leaf corresponds to a specific key pair. The internal node is the root of the subtree, and therefore its xprv should be considered a proxy for all underlying funds. The xpub of the internal node is a tool for monitoring underlying normal addresses, but also a source of metadata about payment activity.

10. Identifiers and serialization

The extended key identifier is  HASH160 derived from the serialized ECDSA public key, i.e., RIPEMD-160 (SHA-256 (SEC1 key)). The first 32 bits of the identifier are called the fingerprint and are used in serialization as a fast pointer to the parent; this is not a cryptographically unique identifier, so software must account for possible collisions.

\[ \operatorname{identifier}(K)=\operatorname{RIPEMD160}(\operatorname{SHA256}(\operatorname{ser}_P(K))). \]

Serialization fieldSizeMeaning
Version bytes4 bytesMainnet:  0488B21E (xpub),  0488ADE4 (xprv); testnet:  043587CF (tpub),  04358394 (tprv)
Depth1 byteNode depth; master – 0
Parent fingerprint4 bytesThe first 32 bits of the parent identifier; the master is zero.
Child number4 bytesChild node index; master has zeros
Chain code32 bytesHMAC derivation context
Key data33 bytesCompressed pubkey or 0x00 || ser256(k)

The total structure takes up 78 bytes. A 4-byte double SHA-256 checksum is appended to it, after which the data is encoded with Base58Check; for the given version bytes, mainnet strings begin with ”  xpub ” or ”  xprv ” and are 111 characters long.

Import validation example

1. Decode Base58Check and check the checksum.
2. Check that the version bytes are known and consistent with the key data type.
3. For depth = 0, require zero parent fingerprint and child number.
4. For xprv require prefix 0x00 and 1 <= k < n.
5. For xpub, require SEC1 prefix 0x02/0x03 and check if the point belongs to secp256k1.
6. Reject the object if there is any violation.

BIP-0032 Vector 5 specifically includes negative tests: public/private version confusion, invalid prefixes, zero depth with non-zero parent fields, unknown version, scalar 0 or \(n\), invalid dot, and invalid checksum. These checks prevent parsing errors, network parameter spoofing, and handling mathematically incorrect objects.

11. Recommended wallet structure

BIP-0032 proposes a basic layout  for both the external  and   internal m/i'/0/k account chains  . The external chain creates addresses for counterparties; the internal chain is used for change and other addresses that don’t need to be disclosed to the outside world.im/i'/1/k

PathPurposePractical scenario
m/i'/0/kExternal chainA new address for each online store account
m/i'/1/kInternal chainChange address for a spending transaction
N(m/*)Set account xpubAudit of receipts and expenses without the right to sign
N(m/i'/0)xpub external chainIsolated payment acceptance server

The standard emphasizes that this layout is advisory. Later standards specify the semantics of the levels: for example, BIP-44 uses the path  m / purpose' / coin_type' / account' / change / address_index. The purpose of the hardened account-level is to localize the consequences of a key or xpub leak within an account.

12. Security Properties

BIP-0032 formulates the expected properties under the assumption of ECDLP and HMAC-SHA512 security. Given a public point, computing the corresponding scalar must not be simpler than solving ECDLP; given a set of child extended private keys, there must be no practical way to determine a common parent better than exhaustively searching the HMAC space.

LeakageImmediate consequenceWhat not to conclude
A regular private keyControl over funds on this keyIt doesn’t necessarily reveal the entire wallet in itself.
xpubBrowsing and generating normal descendants; loss of subtree privacyDoes not grant signature rights
xprvControl over all descendants of a nodeDoesn’t necessarily reveal ancestors across a hardened boundary
xpub + known normal descendant private keyRecovering the parent of an xprv scalar and the subtree tradeoffDoes not break HMAC or ECDLP
Seed / mnemonic plus passphraseReconstructing the entire tree for the selected path schemeDoes not replace the need to correctly define the paths used

Cryptanalytic boundaries

The “cannot derive a private child from a public parent” guarantee refers to the lack of a known effective procedure without additional secret material. It does not protect against weak seeds, mnemonic leaks, malware, device compromise, side-channel attacks, predictable RNGs, or backup errors. HD determinism improves recovery convenience, but also increases the cost of root compromise: one seed is equivalent to a backup of the entire hierarchy.

Privacy should be taken into account separately: xpub typically doesn’t consume resources, but it allows for the association of multiple future addresses within a single subtree. Therefore, publishing xpub in CMS, support tickets, CI/CD logs, client-side JavaScript, or analytics systems can create long-term deanonymization of the payment flow.

13. Real-World Lessons in Implementation

Leading zeros

BIP-0032 test vectors 3 and 4 were added after real library bugs related to the preservation of leading zero bytes in private keys and HMAC results. Cryptographic values ​​have a fixed byte length:  ser256 they must produce exactly 32 bytes, even if the leading bytes are zero. Normalization via the hex string variable-length changes the HMAC input and produces an incompatible tree.

# Pseudocode: Correct 32-byte scalar serialization
ser256(k) = int_to_bytes(k, length=32, byteorder="big")
# Incorrect: hex(k) without adding leading zeros

Incorrect CKD implementation

Historically, the specification has been refined: an early version used multiplication by \(I_L\), later replaced by addition. A modern implementation must use \(k_i=(I_L+k_{par})\bmod n\), not \(k_i=I_L\cdot k_{par}\bmod n\). This discrepancy is not an “alternative wallet”: it breaks compatibility with published vectors and programs from other vendors.

Extended Key Versions

Prefixes  xpub/xprv identify BIP-32 mainnet serialization, but do not by themselves describe the script type of addresses. Practical wallets often use alternative SLIP-132 versions (e.g., ypub/zpub), which help convey derivation context for P2SH-SegWit or native SegWit. These should not be indiscriminately substituted, as this could result in the wrong address class being displayed, even though the underlying key material remains linked to the same tree.

14. Operating model for a web service

A secure pattern for accepting Bitcoin payments: only the xpub of a specific account’s external normal chain is transmitted to the deployment server; the master seed and xprv remain on the hardware wallet or offline signing device. The server stores the index counter, outputs addresses, and monitors receipts, but is not capable of creating signatures.

  1. Generate seed locally via CSPRNG and store it offline in a backup procedure.
  2. Create a separate hardened account for the service.
  3. Export only the xpub of its external branch to the backend, not to the frontend and not to the WordPress database.
  4. Store the output index atomically, eliminating the reuse of addresses in parallel queries.
  5. Never pass private keys of normal descendants of the same branch to the server.
  6. Periodically scan logs, backups, and repositories for xprv, seed phrases, and private keys.

Example: if the backend owns  N(m/84'/0'/7'/0), it can output the address public keys  .../0,  .../1 and so on. However, the private key  m/84'/0'/7'/0/18 cannot be used in an environment where this xpub is available: their combination reveals the private key of the external branch  m/84'/0'/7'/0.

15. A reproducible example of derivation

Below is minimal CKDpriv pseudocode demonstrating the normative logic. In real code, you should use the proven secp256k1 library, constant-time operations for secret scalars, and a CSPRNG for seed generation.

def CKDpriv(k_par, c_par, i):
    assert 0 <= i < 2**32
    if i >= 2**31:
        data = b"\x00" + ser256(k_par) + ser32(i)
    else:
        data = serP(point(k_par)) + ser32(i)
    I = HMAC_SHA512(key=c_par, data=data)
    IL, IR = I[:32], I[32:]
    t = parse256(IL)
    k_i = (t + k_par) % n
    if t >= n or k_i == 0:
        return CKDpriv(k_par, c_par, i + 1) # taking into account the index bounds
    return k_i, IR

Implementation quality assurance should include all five sets of BIP-0032 test vectors, including negative cases. Of particular importance for audit are: fixed-width serialization, correct big-endian index, separate hardened/non-hardened handling, scalar range checking, and public endpoint validation.

16. Conclusions for cryptanalysis

BIP-0032 is not a signature scheme or a means of “hardening” secp256k1; it is a deterministic key distribution protocol. Its security derives from the quality of the seed, the strength of HMAC-SHA512 as a PRF/KDF-like construction, the difficulty of ECDLP, and proper secret delimitation in the application architecture.

The most significant consequence for auditing is the linearity of non-hardened CKD: the parent’s xpub key, together with the private normal child key, is mathematically sufficient to calculate the parent’s private scalar. Hardened derivation eliminates this escalation path, at the cost of making public derivation impossible beyond the corresponding boundary. Therefore, when assessing risk, it is necessary to analyze not individual keys, but the entire access graph: seed, xprv, xpub, paths, storage locations, logs, and signature processes.

Sources

BIP-0032: Hierarchical deterministic wallets – cryptographic and cryptanalytic analysis: https://cryptia.ru/bip-0032-hierarchical-deterministic-wallets-cryptographic-and-cryptanalytic-analysis/

  1. P. Wuille.  BIP 32: Hierarchical Deterministic Wallets . Bitcoin Improvement Proposals, created 2012-02-11, status Final. Initial specification and test vectors.
  2. RFC 4231.  Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 . IETF, 2005.
  3. Standards for Efficient Cryptography Group.  SEC 2: Recommended Elliptic Curve Domain Parameters , secp256k1.
  4. BIP 39.  Mnemonic code for generating deterministic keys . Context of mnemonic phrases and seeds.
  5. BIP 44.  Multi-Account Hierarchy for Deterministic Wallets . Standardized semantics of the path purpose/coin type/account/change/address index.