A scientific and technical paper. Based on Bitcoin Improvement Proposal 44 (Marek Palatinus, Pavol Rusnak; created April 24, 2014; Final status).
BIP-0044 standardizes an applied five-level hierarchical deterministic (HD) derivation scheme: m / purpose' / coin_type' / account' / change / address_index. The standard makes wallet recovery from a seed reproducible, separates cryptoassets from user accounts, and defines an algorithm for searching for used addresses. At the same time, the determinism of the path creates an important cryptanalytic fact: upon obtaining a seed or a valid extended public key (xpub), an attacker can systematically enumerate the addresses of the corresponding branch; this is primarily a privacy and profiling threat, rather than a standalone method for signing a transaction.
Normative context
BIP-44 is a specific implementation of BIP-43 and builds on BIP-32. BIP-32 defines the extended key tree and chaincode, BIP-43 reserves the first component of the path as the destination marker, and BIP-44 fixes the destination value 44' and semantics of the next four levels.
| Document | Function on the stack | Practical significance |
|---|---|---|
| BIP-32 | HD-tree: extended private/public keys, CKDpriv and CKDpub | Allows deterministic generation of keys and watch-only branches |
| BIP-43 | Purpose field | Breeds different derivation schemes in one seed |
| BIP-44 | Path 44'/coin'/account'/change/index | Unifies multi-coin wallets, accounts, and address discovery |
Derivation model
An apostrophe denotes a hardened index: i is used instead i + 2^31. In BIP-44, the purpose, coin type, and account levels are required to be hardened; the change and address index levels are non-hardened.
Normal daughter derivation (BIP-32):
\[ I = \operatorname{HMAC\!\text{-}\!SHA512}(c_{par},\operatorname{serP}(K_{par}) \parallel \operatorname{ser32}(i)) = I_L \parallel I_R \]
\[ k_i = (\operatorname{parse256}(I_L)+k_{par}) \bmod n, \qquad c_i=I_R \]
where \(k_{par}\) is the parent’s private key, \(K_{par}=k_{par}G\) is the public key, \(c_{par}\) is the chain code, \(n\) is the order of the secp256k1 group.
Hardened derivation:
\[ I = \operatorname{HMAC\!\text{-}\!SHA512}(c_{par}, 0x00 \parallel \operatorname{ser256}(k_{par}) \parallel \operatorname{ser32}(i+2^{31})) \]
The parent’s public key is not sufficient to compute such a child.
Five levels of the path
| Component | Type | Meaning | Example |
|---|---|---|---|
m | Root | Master node obtained from seed | Root of one backup seed |
purpose' | Hardened | Scheme identifier; for BIP-44, 44′ | m/44' |
coin_type' | Hardened | Separation of coin spaces | Bitcoin: 0′; Bitcoin Testnet: 1′ |
account' | Hardened | Independent logical accounting area | Personal account 0′, work 1′ |
change | Ordinary | 0 — external receiving chain; 1 — internal change chain | .../0/7 — the eighth receiving address |
address_index | Ordinary | Sequential address index starting from zero | .../1/3 — the fourth change address |
Example of code representation
# BIP-44: первый внешний Bitcoin-адрес первого счёта
path = "m/44'/0'/0'/0/0"
# второй адрес сдачи того же счёта
change_path = "m/44'/0'/0'/1/1"Historical and practical context. This notation has become the accepted consensus among wallets: recovery in compatible software requires not only the seed but also the correct choice of scheme/path. Therefore, erroneously importing a BIP-44 seed into a wallet expecting, for example, BIP-84, may visually indicate an empty balance without actually meaning any coins have been lost.
Semantics of levels
Purpose. The value 44′ informs the implementation that a BIP-44 subtree exists below. This isn’t cryptographic protection per se, but rather a protocol marking that prevents mixing address formats and path conventions.
Coin type. Separate hardened subtrees allow a single master seed to serve multiple cryptocurrencies, reducing the risk of address reuse between coins. Coin types are registered separately in SLIP-0044; for Bitcoin, the index in BIP-44 is 0′, and for Bitcoin Testnet, it is 1′.
Accounts are numbered starting from zero and are intended to separate purposes: personal funds, donations, and operating expenses. The specification recommends not creating a new account until the previous one has a transaction history, as this condition makes recovery final and unambiguous.
Change and index. Separating external and internal addresses reduces the likelihood of change addresses being published as receiving addresses and maintains UTXO accounting discipline. Standard derivation at these levels ensures a watch-only infrastructure mode: addresses can be generated from account xpub without storing private keys.
Account detection
After importing the seed, the wallet starts with account 0, builds an external chain change=0, checks the addresses’ transaction history, and stops searching for the next account when the current external account has no history. The criterion is the transaction history, not the balance: the account must be empty, but a previously used account must be found.
for account in 0, 1, 2, ...:
external = derive("m/44'/coin_type'/account'/0")
history = scan_until_gap(external, gap_limit=20)
if history is empty:
break
record(account)A real-life example of recovery. A user could have spent all the coins from an account m/44'/0'/0', then created and replenished it .../1'. If the importer only evaluates the balance, it will mistakenly stop at a zero account; a correct algorithm will continue searching due to past on-chain activity.
Gap limit
BIP-44 sets the address gap limit to 20: after 20 consecutive addresses with no history in the external chain, the implementation assumes there are no more used addresses. Internal chains are not scanned separately, as change only occurs in transactions involving external addresses of a given account.
Operational limitation. If an owner generated more than 20 external addresses without using them and then received funds at an address beyond this gap, standard recovery may not automatically detect it. This is a detection limitation issue, not a key compromise issue; the solution is to increase the scan window or explicitly specify an extended range.
Cryptanalytic significance. The gap limit also limits the search for a blockchain analyst: the well-known xpub allows generating candidate addresses, but without expanding the window, it’s impossible to firmly conclude that there’s no activity after the twentieth empty index. This is a finiteness heuristic, not a proof that the keys don’t exist.
Cryptanalytic fact
BIP-44 predictability refers to the predictability of its structure , not the computability of its secrets. Knowledge of the standard and the public address prevents the seed, private key, or other addresses from being recovered: security relies on the strength of ECDLP in the secp256k1 group, the one-way nature of HMAC-SHA512, and the secrecy of the chain code.
Enumeration attack on xpub
If an attacker obtains an extended public key for an external branch, such as xpub for m/44'/0'/0'/0, they can deterministically derive all addresses .../0/i in a given range, match them against the blockchain, and cluster the transactions. This is applicable for auditing, forensic research, and payment infrastructure surveillance, but does not grant signing rights.
# Псевдокод watch-only анализа (без приватных ключей)
for i in range(0, scan_window):
pubkey_i = CKDpub(external_xpub, i)
address_i = encode_address(pubkey_i)
inspect_blockchain_history(address_i)A real-life scenario from compliance practice. Passing xpub to an accounting service or payment server allows it to generate new receiving addresses and see the entire flow covered by the branch. This is convenient for separating roles, but it creates a long-term identifier for financial activity; xpub should be considered sensitive metadata.
Escalation “xpub + child private key”
For a standard BIP-32 derivation, knowing the parent xpub and the private key of its direct non-hardened descendant allows one to calculate the parent’s private key. This is due to the additive structure of the CKDpriv formula:
\[ k_{par} = (k_i — \operatorname{parse256}(I_L)) \bmod n \]
Here \(I_L\) is calculated from the chain code and public key contained in parent xpub, as well as the known index \(i\).
For BIP-44, the practical compromise boundary depends on the location of the leak. A branch’s xpub .../0 plus a private key .../0/i reveals the branch’s private key .../0 and, therefore, all its descendants; however, the hardened boundary above it prevents this fact from being traced back to the account’s private key. Similarly, an account xpub plus the private key of one direct child .../0 or .../1 both branches already compromises the account’s private key and both publicly derived branches.
| Attacker dataset | Result | Consequence |
|---|---|---|
| Address / public key | No derivation of adjacent keys | Regular on-chain observability |
| External xpub | All addresses of this external branch | Loss of branch privacy, not theft of funds |
| Parent xpub + direct non-hardened child private key | Parent private key | Compromise of the corresponding subtree |
| Seed / master private key | All BIP-44 subtrees of this seed | Complete loss of control over funds |
Borders and security measures
It’s incorrect to call BIP-44 a “vulnerability”: it’s an open standard of a designated organization. The risk arises from a combination of a predictable path and the leak of privileged material—seed, xprv, xpub, or a child private key under normal derivation.
- Store seeds and xprv exclusively in an isolated environment; do not insert seeds into websites, scripts, or unverified software.
- Don’t publish xpub unless necessary: it doesn’t sign transactions, but it does expose the observable address set of the branch.
- Do not mix the parent’s xpub and the private keys of its non-hardened direct descendants in different trust domains.
- Separate work, personal, and public flows into different account branches or, if privacy is a priority, into different seeds.
- When restoring, check the purpose, coin type, account range, and gap limit; a “zero balance” after import does not prove a lack of funds.
Final Provisions
BIP-44 is not a mechanism for obfuscation, but a convention for HD wallet interoperability. Its key value lies in the reproducible mapping of a single seed into independent subtrees of coins, accounts, external addresses, and change; its key analytical feature is the ability to predictably enumerate addresses when accessing the corresponding xpub.
Sources
BIP-0044: Multi-Account Hierarchy of Deterministic Wallets: https://cryptco.ru/bip-0044-multi-account-hierarchy-of-deterministic-wallets/
- Palatinus, M.; Rusnak, P. BIP-0044: Multi-Account Hierarchy for Deterministic Wallets . Bitcoin Improvement Proposal 44, 2014; status Final. Original document: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
- Wuille, P. BIP-0032: Hierarchical Deterministic Wallets . Bitcoin Improvement Proposals.
- Palatinus, M. BIP-0043: Purpose Field for Deterministic Wallets . Bitcoin Improvement Proposals.
- SatoshiLabs. SLIP-0044: Registered coin types for BIP-0044 .