Pavol Rusnak, Bitcoin Improvement Proposal 84, 2017. The paper is devoted to the analysis of the BIP-84 standard—a scheme for hierarchical deterministic (HD) derivation of native SegWit addresses in the Bech32 format (P2WPKH). The standard specifies the derivation path $\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">m</font></font>}<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">/</font></font>{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">84</font></font>}}^{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">\prime </font></font>}<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">/</font></font>{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">0</font></font>}}^{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">\prime </font></font>}<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">/</font></font>{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">0</font></font>}}^{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">\prime </font></font>}<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">/</font></font>\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">0</font></font>}<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">/</font></font>\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">0</font></font>}$ As a canonical entry point for wallets supporting native SegWit. It is shown that the predictability and standardization of the derivation path generates a specific cryptanalytic vector: mass automated scanning of the first indices of this path during brute-force and “weak seed” attacks on compromised or incorrectly generated HD wallets. The mathematical foundations of BIP32 derivation are presented, along with an analysis of the parent key disclosure vulnerability via the xpub + child privkey combination, and incidents documented in open sources illustrating the practical significance of this vector.

1. Introduction and place of BIP-84 in the standards hierarchy

BIP-84 is an Applications-level standard finalized on December 28, 2017 by Pavol Rusnak (SatoshiLabs/Trezor) [web:2]. The document describes a more general implementation of BIP-32 (HD wallets) and BIP-44 (multi-account hierarchy) for P2WPKH transactions defined in BIP-141 (Segregated Witness) and presented to the user as Bech32 addresses according to BIP-173 [attached_file:1].

2. Abstract and motivation of the standard

The formal goal of BIP-84 is to provide a uniform, reproducible derivation scheme, whereby the same seed, processed by different wallet implementations, produces an identical address tree for P2WPKH transactions [attached_file:1]. Without such standardization, recovering funds from a seed phrase in a third-party wallet would be difficult or impossible.

A practical example:  Trezor and Ledger hardware wallets implement the  m/84'/0'/0' same method precisely thanks to BIP-84 [web:9][web:3]—a user who loses a device can recover the same addresses on any compatible wallet by entering the same BIP-39 seed phrase.

3. Specification: Public Key Derivation

The derivation path is given by the expression:

m \,/\, 84' \,/\, coin\_type' \,/\, account' \,/\, change \,/\, address\_index \tag{1}

where the apostrophe denotes a “hardened” derivation (the index is shifted by ${\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">2</font></font>}}^{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">31</font></font>}}$), and the levels  change and  address_index are non-hardened [attached_file:1]. For Bitcoin mainnet  coin_type' = 0', the key feature of BIP-84 is the fixed value of the level  purpose' = 84', which distinguishes it from BIP-44 ( 44', legacy P2PKH) and BIP-49 ( 49', P2WPKH-v-P2SH).

3.1 Mathematics of Unhardened Derivation (BIP-32)

For a non-hardened child key with index $\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">i</font></font>}$ The public and private keys are calculated as:

I = HMAC\text{-}SHA512(c_{par},\; K_{par} \,\|\, i), \qquad I_L, I_R = split(I) \tag{2}

k_{child} = (I_L + k_{par}) \bmod n, \qquad K_{child} = K_{par} + I_L \cdot G \tag{3}

Where $\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">k</font></font>}$ — private key, $\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">K</font></font>}<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">=</font></font>\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">k</font></font>}<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">\cdot </font></font>\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">G</font></font>}$ — the corresponding public key on the secp256k1 curve, $\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">c</font></font>}$ — chain code, $\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">G</font></font>}$ — base point, $\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">n</font></font>}$ — the order of the group. It is from expression (3) that a critical feature for cryptanalysis follows: if ${\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">K</font></font>}}_{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">p</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">a</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">r</font></font>}}$, ${\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">c</font></font>}}_{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">p</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">a</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">r</font></font>}}$ (that is, a public extended key, xpub) and at least one ${\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">k</font></font>}}_{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">c</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">h</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">i</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">l</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">d</font></font>}}$, That

k_{par} = (k_{child} - I_L) \bmod n \tag{4}

is restored unambiguously, since ${\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">I</font></font>}}_{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">L</font></font>}}$ is calculated publicly from ${\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">K</font></font>}}_{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">p</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">a</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">r</font></font>}}$, ${\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">c</font></font>}}_{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">p</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">a</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">r</font></font>}}$ and index $\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">i</font></font>}$ [web:5][web:10][web:13].

A documented cryptanalytic fact.  This vulnerability was formally described in the academic paper by Gutoski & Stebila, “Hierarchical Deterministic Bitcoin Wallets that Tolerate Key Leakage” (IACR ePrint 2014/998): “an attacker can easily recover the master private key given the master public key and any child private key” [web:5]. This property is precisely why BIP-32 introduced hardened derivation—but it is only applied at the top account/coin_type levels, while the  change and  levels address_index, including those used by BIP-84, remain unhardened by design, which retains the risk in practice of leaking a single address private key along with an account’s xpub [web:13][web:14].

4. Address derivation (P2WPKH / BIP-141)

After receiving the public key ${\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">K</font></font>}}_{\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">c</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">h</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">i</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">l</font></font>}\mathrm{<font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;"><font\; dir="auto"\; style="box-sizing:\; border-box;\; vertical-align:\; inherit;">d</font></font>}}$ A 20-byte hash is calculated  HASH160(K_child) = RIPEMD160(SHA256(K_child))and packed into a scriptPubKey of the following type:

witness: <signature> <pubkey>
scriptSig: (empty)
scriptPubKey: OP_0 <20-byte-key-hash>
              (0x0014{20-byte-key-hash})

The result is encoded in Bech32 (BIP-173) format, yielding addresses prefixed with  bc1q... [attached_file:1].

5. Extended Key Version Bytes

The presence of a separate prefix “zpub”/”zprv” is in itself a cryptanalytic marker: blockchain analysis scanners and parsers use it to instantly identify the wallet type without analyzing the derivation path itself [web:7][web:9].

6. Test vectors of the standard and their secondary use

The official BIP-84 test vector is built on the BIP-39 mnemonic  abandon × 11 about , the canonical “zero” entropy used by developers worldwide to verify implementations [attached_file:1]:

mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon about
m/84'/0'/0'/0/0 → address = bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu
m/84'/0'/0'/0/1 → address = bc1qnjg0jd8228aq7egyzacy8cys3knf9xvrerkf9g
m/84'/0'/0'/1/0 → address = bc1q8c6fshw2dlwun7ekn9qwf37cu2rn755upcp6el

Cryptanalytic fact: the test address as an indicator of a configuration error.  The address  bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyucorresponding to the index  m/84'/0'/0'/0/0 for the “zero” mnemonic is one of the most frequently encountered values ​​in the logs of automated pentesting and GPU brute-force tools (for example, publicly documented sets of test vectors for CUDA-accelerated BIP-39 brute-force, where this combination serves as a “zero entropy” checkpoint before launching a real key search [web:6]). This fact turns the combination  m/84'/0'/0'/0/0 + the “abandon × 11 about” mnemonic into a de facto benchmark: any detected transfer of funds to this address on the blockchain is almost certainly the result of a wallet configuration error by the developer, rather than deliberate use, and such addresses are systematically monitored by the community as a “honeypot-like watch” [web:12][web:6].

7. Cryptanalytic vector: mass scanning of the path m/84’/0’/0’/0/0

Because BIP-84 hard-codes the path structure and the first address of an account is almost always indexed  change=0, address_index=0, automated weak-seed scanners prioritize this entry point when attacking compromised random number generators (RNGs) or predictable mnemonics [web:4][web:9].

A historical example: the Android RNG incident of 2013–2014.  A flaw  SecureRandom in early versions of Android led to repeatable nonces and predictable keys in a number of Bitcoin/Litecoin wallets; although this incident predates BIP-84 (2017), it demonstrates the same attack logic that was later migrated by the industry to native SegWit paths: scanners immediately check the canonical first address of an account ( .../0/0) of any standard derivation scheme, since the probability of its use with weak seed generation is maximum, and the computational cost of checking a single path is minimal [web:4].

Example: xpub + one child privkey (bitcoin security forums).  A practical case was discussed on the Bitcoin StackExchange forum: a leak of an xpub account at the level,  m/44'/60'/4' along with the private key of a child address  .../0 , allowed the recovery of the parent private key using formula (4), compromising the entire subtrade of addresses for this account [web:13]. Similar logic applies to any BIP-84 account level: the compromise of a single xpub signature from a “watch-only” wallet, combined with a single exposed private key pair, nullifies the security of the entire address tree below the account level [web:10][web:14].

8. Backward compatibility and its cryptanalytic consequences

BIP-84 is deliberately incompatible with BIP-44/49: a wallet that doesn’t support  purpose' = 84'[attached_file:1] simply won’t see the account [attached_file:1]. This prevents address space collisions between different types of scripts, but also means that all native SegWit traffic is deterministically concentrated in a single, publicly known path subtree—which simplifies targeted scanning compared to a hypothetical random [attached_file:1] scheme  purpose.

9. Practical implications for security audit

• The extended public key (zpub/xpub) of an account should be treated as sensitive data and not as “safe to disclose” watch-only material [web:3][web:10].
• Software developers are required to exclude test mnemonics (including  abandon × 11 about) from production configurations – historically, such addresses become leak points during deployment errors [web:6][web:12].
• Using only hardened derivation at all levels eliminates the threat of recovering the parent key using formula (4), but breaks compatibility with BIP-84/BIP-44 in their canonical form [web:5][web:14].

BIP-0084: Derivation Scheme for P2WPKH Based on BIP44 – scientific analysis: https://cryptrade.ru/bip-0084-derivation-scheme-for-p2wpkh-based-on-bip44-scientific-analysis/

This research paper is based on the primary source of BIP-0084 (bitcoin/bips, GitHub) and open-source materials on the cryptanalysis of BIP-32 HD wallets. The formulas are presented in LaTeX-compatible notation (MathJax).