Bitcoin Core Developers’ Normative Standards: BIP-32 Hierarchical Deterministic Wallets and BIP-39 Mnemonic Code for Generating Deterministic Keys

BY KEYHUNTER 03.09.2026

Bitcoin Core Developers' Normative Standards: BIP-32 Hierarchical Deterministic Wallets and BIP-39 Mnemonic Code for Generating Deterministic Keys

The basis of cryptographic and cryptanalytic analysis of seed, mnemonic and HD derivations

Scientific and technical article for publication in WordPress · Version: September 2026

Annotation

This article systematically examines the BIP-39 → BIP-32 integration that underlies backup and deterministic key generation in Bitcoin wallets. Three commonly confused entities are separated: entropy, mnemonic phrase, and binary seed; mnemonic generation, PBKDF2-HMAC-SHA512, master extended key creation, and child derivation functions are formally described. The central cryptanalytic fact is that compromising the parent xpub and any  unhardened  child private key allows algebraic recovery of the parent private key and its entire unhardened subtree. Therefore, hardened bounds are not a convenience of addressing, but rather boundaries for damage containment.

1. Status and subject of standards

BIP-32  (Bitcoin Improvement Proposal 32) defines hierarchical deterministic wallets (HD wallets): a tree of extended private and public keys, reproducible from a single secret. Its goal is selective delegation: an observing service can obtain new public addresses without acquiring signing rights.

BIP-39  defines a human-friendly means of transporting computer randomness: a sequence of words encodes entropy with a checksum, and then, along with an optional passphrase, is converted into a 512-bit seed. BIP-39 is not a “human-generated password” scheme and does not explicitly recommend the brainwallet approach.

LayerEntranceTransformationResultThe meaning of security
The source of randomnessENT: 128–256 bits from CSPRNGNoEntropyDetermines the actual durability of the backup
BIP-39 mnemonicENTSHA-256 checksum, 11-bit groups, dictionary12/15/18/21/24 wordsA human-readable record, not the seed itself
BIP-39 seedMnemonic + passphrasePBKDF2-HMAC-SHA512, 2048 iterations64 bytesBIP-32 input; passphrase changes the entire tree
BIP-32 master nodeSeedHMAC-SHA512 with the “Bitcoin seed” key(k m , c m )The Root of the Secret Tree
BIP-32 descendantsExtended key + indexCKDpriv or CKDpubChild extended keySeparation of roles, accounts, and addresses

2. Terms and threat model

Let secp256k1 have a base point  G and subgroup order  n. A typical private key is a scalar  k ∈ [1,n−1], and the public key is a point  K = kG. The security of the “public key → private key” communication reduces to the computational difficulty of ECDLP; for secp256k1, the target score is about 2,128 group  operations.

A BIP-32 extended key isn’t just a key: it’s a pair of  (k,c) either  (K,c), where  c is a 32-byte chain code. The chain code serves as the HMAC key in subsequent derivations and prevents descendants from depending solely on the master key.

The key difference is  that mnemonic is a passphrase, seed is the result of PBKDF2, BIP-32 master private key is the left half of the HMAC of the seed, and xprv is a serialized extended private key with metadata. These values ​​are not synonymous.

3. BIP-39: From Entropy to Words

Let the original entropy have a length  ENTmultiple of 32, from 128 to 256 bits. The first  CS = ENT/32 bits of the SHA-256 hash of this entropy are added to it; the result is divided into 11-bit index words. Since 2 11  = 2048, each index addresses a dictionary word with 2048 elements.

CS = ENT / 32
MS = (ENT + CS) / 11
checksum = prefix CS (SHA256(ENT))
bitstream = ENT || checksum

ENT, bitCS, bitTotal bitsNumber of wordsRandom search space
1284132122 128
1605165152,160​
1926198182 192
2247231212,224​
2568264242 256

Checksum: purpose and limits

The checksum serves to detect random writing errors, but it does not increase entropy or authenticate the phrase. For 24 words, the checksum length is 8 bits: approximately one in 256 randomly altered sequences can pass the check; the checksum cannot correct errors.

A cryptanalytic example.  In a practical reconstruction of a damaged paper copy of a 24-word phrase, checksum can eliminate most of the invalid candidates, but does not prove that the remaining candidate is the original one. The check must be completed by independent verification against a known address, descriptor, xpub, or transaction history; the phrase cannot be published in “online recovery sites.”

Dictionaries and normalization

The dictionary semantics are part of the PBKDF2 input: words are concatenated into a string and normalized to UTF-8 NFKD. Translating an English phrase into another dictionary is not a translation of the same secret—it produces a different string input and, therefore, a different seed.

Historically, compatibility has been most reliable for the English dictionary, which is reflected in the specification. Normalization issues are particularly noticeable in localized mnemonics and passphrases: visually identical Unicode characters may have different byte representations before NFKD conversion.

4. BIP-39: mnemonic in seed

BIP-39 uses a mnemonic sentence as the PBKDF2 password and a string  "mnemonic" || passphrase as the salt. Both components are pre-normalized to UTF-8 NFKD; if the passphrase is missing, an empty string is used. The result is always 512 bits long, or 64 bytes.

seed = PBKDF2-HMAC-SHA512(
  password = NFKD(mnemonic),
  salt = NFKD(“mnemonic” || passphrase),
  c = 2048, dkLen = 64 bytes
)

# Псевдокод: BIP-39 seed derivation
mnemonic_utf8 = UTF8(NFKD(mnemonic_sentence))
salt_utf8     = UTF8(NFKD("mnemonic" + passphrase))
seed          = PBKDF2_HMAC_SHA512(mnemonic_utf8, salt_utf8, 2048, 64)

A real-life example:  A hardware wallet can display 24 words, but the user stores an additional passphrase separately. The same 24 words with an empty passphrase and a different passphrase result in two completely different wallets; this creates plausible deniability, but makes loss or typographical error of the passphrase an irreversible loss of access.

Cryptanalytic evaluation

PBKDF2 with 2048 iterations slows down the brute-force attack but doesn’t compensate for the weak initial entropy. If the mnemonic was generated by a predictable random number generator, the attacker tries not 2128  phrases, but the actual small set of states of the flawed generator; checksum and 2048 iterations don’t fix this underlying flaw.

A telling historical case of incidents is “brainwallets”: users substituted CSPRNGs with memorable phrases or quotes. These addresses became subject to dictionary and probabilistic searches; BIP-39 specifically mandates the transfer  of machine  randomness into convenient notations, rather than the secure hashing of human thought.

5. BIP-32: Creating a Root

The BIP-39 binary seed is only a typical source for BIP-32; BIP-32 allows seeds of 128–512 bits and recommends 256 bits. To create a master node, an HMAC-SHA512 is computed with a literal key  "Bitcoin seed"; the left half becomes the master private key, the right half becomes the master chain code.

I = HMAC-SHA512(key = “Bitcoin seed”, data = S)
I = I L  || I R
k m  = parse 256 (I L ), c ​​m  = I R

If   or  , the master key is invalid. The probability of such an event is vanishingly small, but a correct implementation must check for this condition rather than assume it is impossible.km = 0km ≥ n

# Псевдокод: создание BIP-32 master extended private key
I  = HMAC_SHA512(key=b"Bitcoin seed", data=seed)
IL, IR = I[:32], I[32:]
k_m = parse256(IL)
if k_m == 0 or k_m >= n:
    fail("invalid master key")
master_xprv = (k_m, IR)

6. Extended Keys and Serialization

An extended private key has the form  (k,c), and an extended public key  has the form (K,c), where  K=kG. In addition to the 32-byte chain code, serialization includes version bytes, depth, parent fingerprint, child number, and 33 bytes of key material; before Base58Check, this is 78 bytes.

In the traditional mainnet representation, version bytes are distinguished between  xprv ( 0x0488ADE4) and  xpub ( 0x0488B21E); the Base58Check string is 111 characters long. The parent fingerprint is only a quick heuristic identifier of the relationship, so implementations should tolerate collisions and not use it as cryptographic proof of kinship.

# Структура сериализованного extended key (78 байт)
version(4) || depth(1) || parent_fingerprint(4) || child_number(4) ||
chain_code(32) || key_data(33)
# затем Base58Check: checksum = SHA256(SHA256(payload))[:4]

A practical example:  An online store can only upload the external receiving chain’s xpub to the web server. The server displays order addresses and monitors receipts, but it shouldn’t receive xprv, mnemonic, or seed: any of these secrets could lead to the potential for funds being spent if compromised.

7. CKDpriv: Private Derivation

For each index,  i BIP-32 uses HMAC-SHA512 with the parent chain code as the key. Indexes   are normal (non-hardened); indexes   are hardened. The notation   means  .0 ... 231−1231 ... 232−1i'i + 231

data = 0x00 || ser 256 (k par ) || ser 32 (i), i ≥ 2 31
data = ser P (K par ) || ser 32 (i), i < 2 31
I = HMAC-SHA512(key=c par , data=data) = I L  || I R
k i  = (parse 256 (I L ) + k par ) mod n, c i  = I R

def CKDpriv(k_par, c_par, i):
    if i >= 0x80000000:
        data = b"\x00" + ser256(k_par) + ser32(i)
    else:
        data = serP(point(k_par)) + ser32(i)
    IL, IR = split(HMAC_SHA512(c_par, data))
    k_i = (parse256(IL) + k_par) % n
    if parse256(IL) >= n or k_i == 0:
        return CKDpriv(k_par, c_par, i + 1)
    return k_i, IR

 The cases or  are unacceptable  ; the specification dictates moving on to the next index. This is not a “fix” to the key and is not a reason to reset it: such an approach would destroy the compatibility and verifiability of the tree.parse256(IL) ≥ nki=0

8. CKDpub and watch-only

Only normal derivation is permitted from an extended public key.   The same HMAC input data is used as in normal CKDpriv, and the child point is obtained by adding the point constructed from  , to the parent point.i < 231IL

K i  = point(parse 256 (I L )) + K par
c i  = I R

def CKDpub(K_par, c_par, i):
    if i >= 0x80000000:
        raise ValueError("hardened derivation unavailable from xpub")
    IL, IR = split(HMAC_SHA512(c_par, serP(K_par) + ser32(i)))
    K_i = point(parse256(IL)) + K_par
    if parse256(IL) >= n or K_i == INFINITY:
        return CKDpub(K_par, c_par, i + 1)
    return K_i, IR

Algebraic consistency is expressed by equality  N(CKDpriv(parent,i)) = CKDpub(N(parent),i) for normal indices. This allows watch-only systems to construct an infinite sequence of addresses without access to the signature, but it also creates a critical combination vulnerability.

9. The Central Cryptanalytic Fact

For a normal child, the value   is computable from the parent xpub and the public index: xpub reveals   and  . If the private key of such a child is subsequently leaked  , the parent’s private scalar is recovered with a single modular subtraction.ILKparcparki

k par  = (k i  − parse 256 (I L )) mod n
where I L  = left256(HMAC-SHA512(c par , ser P (K par ) || ser 32 (i)))

This isn’t an attack on ECDLP, a SHA-512 collision, or a practical cryptographic break of HMAC. It’s a direct consequence of the linear construction of normal CKDpriv: a publicly computable offset is added to a secret parent scalar.

Compromise scenario

  1. The company places account-level xpub in the analytics system or payment server.
  2. The developer mistakenly exports one private key of a normal address from the same subtree to a log, backup, or third-party signing service.
  3. Anyone who has received both artifacts and knows/iterates the index on the observed structure calculates the parent private key.
  4. From the parent xprv, the attacker deterministically obtains all descendants of this subtree and can sign spends from the corresponding addresses.

Countermeasure:  A hardened edge must be placed between the layer whose xpub is being distributed and the layers where private keys could be leaked. Therefore, common BIP-44 paths use hardened purpose, coin type, and account:  m / 44' / coin_type' / account' / change / address_index. Account-level xpub is acceptable for watch-only, but private keys below it require strict isolation.

10. Hardened derivation as a damage boundary

Hardened CKDpriv includes the parent’s private key in the HMAC input and has no corresponding CKDpub operation. Therefore, the parent’s xpub cannot be calculated   for the hardened child; the reverse recovery formula given above is no longer applicable.IL

PropertyNormal childHardened child
Index0 … 2 31 −12 31  … 2 32 −1
HMAC InputParent public key + indexParent private key + index
Output from xpubYesNo
Watch-only addressesYesNo
xpub + child private key → parent private keyYes, if the subtree matchesNo, according to this linear formula

Historical design context.  Early in BIP-32’s history, hardened private derivation was added specifically to reduce the risk of parent private key leakage. The architectural conclusion remains: the convenience of public derivation should always be weighed against the risk of mixing exported xpub and child secrets.

11. Tree structure and paths

The path  m/3'/2/5 denotes a sequential application of CKDpriv from the master node  m. The apostrophe denotes a hardened index; a public path from the neutralized root is possible only as long as no hardened component is encountered.

N(m/a/b/c) = N(m)/a/b/c if a,b,c < 2 31
N(m/a’/b/c) = N(m/a’)/b/c, but N(m)/a’ is undefined

The basic BIP-32 design provides the following accounting entries:  m/i'/0/k — an external chain (receiving addresses)  m/i'/1/k — an internal chain (e.g., change). Modern BIP-43/44 conventions and descriptors clarify the purpose of paths and script types, but BIP-32 remains the foundation of the extended key mechanism.

12. Examples from operation

Payment server without the right to spend

For an online store, exporting an xpub branch of external addresses to a server is justified: it issues a new address for the order and tracks UTXOs, while the transaction signature remains offline. Due to the loss of privacy, xpub should still be considered sensitive: it allows for linking output addresses and monitoring receipts from this branch.

Audit and corporate separation

The auditor can be given a limited set of xpubs, sufficient to monitor the receipts and expenditures of selected branches. Passing the master xprv for ease of synchronization is an anti-pattern: such an export grants full control over all descendants and turns the audit copy into the equivalent of a hot wallet.

Archival recovery

When restoring a wallet, it’s important to record not only the words but also the exact dictionary, NFKD-compatible passphrase, network, path, and addressing scheme. A valid mnemonic with an incorrect passphrase, path, or script type usually creates a valid but “empty” wallet—this is a diagnostic ambiguity, not proof of a lack of funds.

13. Validation and test vectors

Cryptographic implementations must be verified using the official BIP-32 and BIP-39 test vectors, including special cases involving leading zeros. For BIP-32, correct fixed-width serialization is essential:   it must produce exactly 32 bytes, and the compressed SEC1 public key must produce 33 bytes.ser256(k)

# Минимальный контур валидации BIP-32
assert len(ser256(k)) == 32
assert len(serP(K)) == 33
assert 1 <= k < n
assert is_valid_secp256k1_point(K)
assert depth == 0 implies parent_fingerprint == b"\x00"*4 and child_number == 0
assert base58check_checksum(payload) is valid

Real development errors often lie not in “complex math” but in encodings: incorrect index endianness, missing a byte  0x00 in hardened input, uncompressed period instead of SEC1 compressed form, missing leading zero, non-NFKD Unicode, or accepting an invalid period from serialized xpub.

14. BIP-39 Limitations

BIP-39 defines a short checksum that detects errors only probabilistically and does not correct them. It does not include built-in versioning of key assignments or address formats; in the current ecosystem, this ambiguity is mitigated by wallet descriptors, but archiving must still store recovery metadata.

Furthermore, BIP-39 cannot represent an arbitrary BIP-32 seed with an inverse transformation: the mnemonic → seed mapping is one-way. This leads to a rule of thumb in digital forensics: the presence of a seed does not allow one to reconstruct the original words, and the presence of a BIP-32 xprv does not allow one to reconstruct a BIP-39 mnemonic.

15. Practical protection profile

  • Generate ENT only from a cryptographically strong source of randomness; do not create mnemonics from phrases, dates, patterns, or weak PRNGs.
  • Store the mnemonic and passphrase separately; test recovery on an isolated device with a test sum beforehand.
  • Never enter production mnemonic, seed, or xprv into websites, cloud notes, screenshots, tickets, or LLM chats.
  • Treat xpub as sensitive data: it is the source of mass deanonymization of the corresponding branch.
  • Do not mix exported xpub with child private keys from its normal subtree; design hardened boundaries before distributing xpub.
  • Check BIP-32/BIP-39 test vectors, NFKD, field lengths, checksum, and secp256k1 point validity.
  • Archive the derivation path, network, script/descriptor type, and passphrase policy used, along with the backup phrase.

Final Provisions

BIP-39 addresses the problem of securely transferring entropy through humans, while BIP-32 addresses the problem of scalable deterministic key hierarchy. The cryptographic strength of this system is determined not by the beauty of mnemonic words, but by the quality of the initial entropy, the secrecy of the mnemonic/passphrase/seed/xprv, the correctness of the byte implementation, and the discipline of hardened boundary placement.

The main cryptanalytic lesson of BIP-32 is clear and operational: leaking  xpub the private key of a normal child does not require solving a discrete logarithm—it directly recovers the parent’s private key. Therefore, proper role separation in the HD tree is part of the cryptographic security model, not just an address convention.

Normative sources

BIP-32 and BIP-39: analysis seed, mnemonic and HD-derivations:  https://usde.ru/bip-32-and-bip-39-analysis-seed-mnemonic-and-hd-derivations/

  1. Pieter Wuille, Eric Lombrozo.  BIP-32: Hierarchical Deterministic Wallets . Bitcoin BIPs repository, status Final.  https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
  2. Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe.  BIP-39: Mnemonic code for generating deterministic keys . Bitcoin BIPs repository, status Deployed.  https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
  3. Krawczyk, Bellare, Canetti.  HMAC: Keyed-Hashing for Message Authentication , RFC 2104.
  4. Kaliski.  PKCS #5: Password-Based Cryptography Specification Version 2.0 , RFC 2898.
  5. Standards for Efficient Cryptography Group.  SEC 2: Recommended Elliptic Curve Domain Parameters , secp256k1.