Where in the tree do wallet keys live?

Evidence

Each numbered marker in the text points here, and the ↩ links lead back to every place that cites an entry. Quotes are verbatim from the BIP files at commit 3a10b5b, including their wiki markup; links open the exact lines; the quoted text sits under each entry. Labels say what kind of statement each is: a rule, the author’s rationale, history, a test vector, or our own inference.

1. ↩ a b Rule BIP 44 defines a logical hierarchy on top of BIP 32's derivation algorithm and BIP 43's purpose scheme; it is a particular application of BIP 43.

   BIP 44 L17–21

   Quoted source text (1)

   This BIP defines a logical hierarchy for deterministic wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on). This BIP is a particular application of BIP43.

2. ↩ a b Author’s rationale BIP 44's hierarchy is meant to handle multiple coins, multiple accounts, external and internal chains per account, and millions of addresses per chain.

   BIP 44 L25–27

   Quoted source text (1)

   It allows the handling of multiple coins, multiple accounts, external and internal chains per account and millions of addresses per chain.

3. ↩ a b Author’s rationale BIP 84's motivation: a common scheme lets different wallets share a seed, and dedicated SegWit accounts mean only compatible wallets detect them.

   BIP 84 L20–23

   Quoted source text (1)

   With the usage of P2WPKH transactions it is necessary to have a common derivation scheme. It allows the user to use different HD wallets with the same masterseed and/or a single account seamlessly. Thus the user needs to create dedicated segregated witness accounts, which ensures that only wallets compatible with this BIP will detect the accounts and handle them appropriately.

4. ↩ History BIP 44 (Palatinus, Rusnak; assigned 2014; requires BIPs 32 and 43), BIP 84 (Rusnak; 2017) and BIP 86 (Chow; 2021) are application-layer specifications, all recorded as Deployed.

   BIP 44 L3–12 BIP 44 L9–12 BIP 84 L3–10 BIP 84 L8–10 BIP 86 L3–8

   Quoted source text (5)

   Layer: Applications Title: Multi-Account Hierarchy for Deterministic Wallets Authors: Marek Palatinus <slush@satoshilabs.com> Pavol Rusnak <stick@satoshilabs.com>

   Status: Deployed Type: Specification Assigned: 2014-04-24 Requires: 32, 43

   Layer: Applications Title: Derivation scheme for P2WPKH based accounts Authors: Pavol Rusnak <stick@satoshilabs.com>

   Status: Deployed Type: Specification Assigned: 2017-12-28

   Layer: Applications Title: Key Derivation for Single Key P2TR Outputs Authors: Ava Chow <me@achow101.com> Status: Deployed Type: Specification Assigned: 2021-06-22

5. ↩ a b c d e Rule BIP 44 defines five levels below m: purpose', coin_type', account', change and address_index; an apostrophe marks hardened derivation.

   BIP 44 L31–37

   Quoted source text (1)

   We define the following 5 levels in BIP32 path: <pre> m / purpose' / coin_type' / account' / change / address_index </pre> Apostrophe in the path indicates that BIP32 hardened derivation is used.

6. ↩ a b Rule Purpose is the constant 44' (0x8000002C), following BIP 43, and marks the subtree as following this specification; it is hardened.

   BIP 44 L43–46

   Quoted source text (1)

   Purpose is a constant set to 44' (or 0x8000002C) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification. Hardened derivation is used at this level.

7. ↩ a b Rule Coin type gives each coin its own hardened subtree, avoiding address reuse across coins; BIP 44 lists 0' for Bitcoin and 1' for Bitcoin testnet and points to SLIP-0044 for the full list.

   BIP 44 L54–55 BIP 44 L144–150 BIP 44 L153–154 BIP 44 L156

   Quoted source text (4)

   This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues.

   |0 |0x80000000 |Bitcoin |- |1 |0x80000001 |Bitcoin Testnet

   This BIP is not a central directory for the registered coin types, please visit SatoshiLabs that maintains the full list:

   [[https://github.com/satoshilabs/slips/blob/master/slip-0044.md|SLIP-0044 : Registered coin types for BIP-0044]]

8. ↩ a b c Rule Accounts split the key space into independent user identities so coins are never mixed; they are numbered from 0, use hardened derivation, and software should not create an account while the previous one has no transaction history. BIP 44 likens them to bank accounts: one for donations, one for savings, one for common expenses.

   BIP 44 L67–68 BIP 44 L75–81 BIP 44 L70–73

   Quoted source text (3)

   This level splits the key space into independent user identities, so the wallet never mixes the coins across different accounts.

   Accounts are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. Hardened derivation is used at this level. Software should prevent a creation of an account if a previous account does not have a transaction history

   Users can use these accounts to organize the funds in the same fashion as bank accounts; for donation purposes (where all addresses are considered public), for saving purposes, for common expenses etc.

9. ↩ a b c d e Rule Change is 0 for the external chain (addresses shown outside the wallet, for receiving) and 1 for the internal chain (change); it uses public derivation.

   BIP 44 L88–94

   Quoted source text (1)

   Constant 0 is used for external chain and constant 1 for internal chain (also known as change addresses). External chain is used for addresses that are meant to be visible outside of the wallet (e.g. for receiving payments). Internal chain is used for addresses which are not meant to be visible outside of the wallet and is used for return transaction change. Public derivation is used at this level.

10. ↩ a b c d Rule Addresses are numbered from 0 along each chain, with public derivation.

    BIP 44 L98–101

    Quoted source text (1)

    Addresses are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation. Public derivation is used at this level.

11. ↩ Rule After importing a seed, software discovers accounts in order, scanning each account's external chain and stopping at the first account with no transactions; it works on transaction history, not balances.

    BIP 44 L108–112 BIP 44 L118–120

    Quoted source text (2)

    # derive the first account's node (index = 0) # derive the external chain node of this account # scan addresses of the external chain; respect the gap limit described below # if no transactions are found on the external chain, stop discovery # if there are some transactions, increase the account index and go to step 1

    Please note that the algorithm works with the transaction history, not account balances

12. ↩ History BIP 44 gives the address gap limit as 20 at the time of writing: after 20 unused addresses in a row, software stops scanning that chain. It scans only external chains, reasoning that internal chains receive only coins that come from the associated external chains, and wallet software should warn a user who tries to exceed the limit.

    BIP 44 L124–127 BIP 44 L129–130

    Quoted source text (2)

    Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain. We scan just the external chains, because internal chains receive only coins that come from the associated external chains.

    Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.

13. ↩ Test vector BIP 44's examples table lists 16 paths: the first and second address of the external and change chains, for the first and second account, for Bitcoin and for Bitcoin testnet.

    BIP 44 L170–174 BIP 44 L260–264

    Quoted source text (2)

    |Bitcoin |first |external |first |m / 44' / 0' / 0' / 0 / 0

    |Bitcoin Testnet |second |change |second |m / 44' / 1' / 1' / 1 / 1

14. ↩ a b c d e Test vector This site's model, starting from BIP 84's and BIP 86's published mnemonic, reproduces every published root, account and address value in both BIPs' test vectors (zprv/zpub for BIP 84; xprv/xpub, internal key, output key, scriptPubKey and address for BIP 86); the build fails otherwise. Intermediate values (node keys, fingerprints, key hashes, tweaks) are derived by the same tested model and implied by the published leaves, but not published themselves. BIP 86 defines no alternate version bytes, and its vectors print as xprv/xpub.

    BIP 84 L69–71 BIP 86 L86–87

    Quoted source text (2)

    mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about rootpriv = zprvAWgYBBk7JR8Gjrh4UJQ2uJdG1r3WNRRfURiABBE3RvMXYSrRJL62XuezvGdPvG6GFBZduosCc1YP5wixPox7zhZLfiUm8aunE96BBa4Kei5

    mnemonic = abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about rootpriv = xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu

15. ↩ a b c Test vector From an account's extended public key alone, the model re-derives every published receiving and change address of that account, because the two levels below the account use public derivation. On its own such a key cannot spend.

    BIP 44 L94 BIP 84 L75 BIP 86 L92

    Quoted source text (3)

    Public derivation is used at this level.

    xpub = zpub6rFR7y4Q2AijBEqTUquhVz398htDFrtymD9xYYfG1m4wAcvPhXNfE3EfH1r1ADqtfSdVCToUG868RvUUkgDKf31mGDtKsAYz2oz2AGutZYs

    xpub = xpub6BgBgsespWvERF3LHQu6CnqdvfEvtMcQjYrcRzx53QJjSxarj2afYWcLteoGVky7D3UKDP9QyrLprQ3VCECoY49yfdDEHGCtMMj92pReUsQ

16. ↩ a b c d e Editorial inference BIP 44 itself names no script type or address format; BIPs 84 and 86 treat the purpose value as what signals the script type or serialization, and tie one to each purpose.

    BIP 84 L35 BIP 86 L37–39

    Quoted source text (2)

    but only uses a different purpose value to indicate the different transaction serialization method.

    To derive a public key from the root account, this BIP uses the same account-structure as defined in BIPs [[bip-0044.mediawiki|44]], [[bip-0049.mediawiki|49]], and [[bip-0084.mediawiki|84]], but with a different purpose value for the script type.

17. ↩ a b c Rule BIP 84 keeps BIP 44's account structure and changes only the purpose, 84', to indicate the P2WPKH serialization (the BIP 173 format), building addresses with BIP 141's P2WPKH encapsulation.

    BIP 84 L16 BIP 84 L35 BIP 84 L41 BIP 84 L49–52

    Quoted source text (4)

    This BIP defines the derivation scheme for HD wallets using the P2WPKH ([[bip-0173.mediawiki|BIP 173]]) serialization format for segregated witness transactions.

    this BIP uses the same account-structure as defined in [[bip-0044.mediawiki|BIP 44]] and [[bip-0049.mediawiki|BIP 49]], but only uses a different purpose value to indicate the different transaction serialization method.

    For the <code>purpose</code>-path level it uses <code>84'</code>.

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

18. ↩ a b c Rule BIP 86 uses purpose 86' for keys used as the internal key of single-key P2TR outputs: the internal key is lift_x(derived key), tweaked with a hash of the key alone so that, as BIP 341 recommends, the output commits to an unspendable script path rather than none, in a version 1 output 0x5120{output key}.

    BIP 86 L14–15 BIP 86 L45 BIP 86 L60–61 BIP 86 L70–71 BIP 86 L54–57

    Quoted source text (5)

    This document suggests a derivation scheme for HD wallets whose keys are involved in single key P2TR ([[bip-0341.mediawiki|BIP 341]]) outputs as the Taproot internal key.

    For the <tt>purpose</tt>-path level it uses <tt>86'</tt>.

    internal_key: lift_x(derived_key) 32_byte_output_key: internal_key + int(HashTapTweak(bytes(internal_key)))G

    scriptPubKey: 1 <32_byte_output_key> (0x5120{32_byte_output_key})

    If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path.

19. ↩ Rule BIP 84's outputs are spent with an empty scriptSig and a witness of a signature and the public key; BIP 86's with an empty scriptSig and a witness holding only a signature.

    BIP 84 L49–51 BIP 86 L68–69

    Quoted source text (2)

    witness: <signature> <pubkey> scriptSig: (empty)

    witness: <signature> scriptSig: (empty)

20. ↩ Rule BIP 84 serializes extended keys with alternate version bytes: 0x04b24746 (zpub) and 0x04b2430c (zprv), with vpub/vprv on testnet.

    BIP 84 L57

    Quoted source text (1)

    Extended public keys use <code>0x04b24746</code> to produce a "zpub" prefix, and private keys use <code>0x04b2430c</code> to produce a "zprv" prefix. Testnet uses <code>0x045f1cf6</code> "vpub" and <code>0x045f18bc</code> "vprv."

21. ↩ Rule BIPs 84 and 86 are not backwards compatible by design: a wallet that does not implement them will not discover the accounts at all.

    BIP 84 L64 BIP 86 L76–78

    Quoted source text (2)

    This BIP is not backwards compatible by design as described under [[#considerations|considerations]]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong.

    This BIP is not backwards compatible by design. An incompatible wallet will not discover these accounts at all and the user will notice that something is wrong.

22. ↩ Author’s rationale BIP 86's motivation: many wallets and hardware signers still use seed backups without derivation path or script information, so a fixed path makes single-key Taproot outputs likely to be recoverable; although there are now solutions that avoid fixed paths, it largely reuses the approach of BIPs 49 and 84 for ease of implementation.

    BIP 86 L23–28

    Quoted source text (1)

    it is useful to have a common derivation scheme so that HD wallets that only have a backup of the HD seed can be likely to recover single key Taproot outputs. Although there are now solutions which obviate the need for fixed derivation paths for specific script types, many software wallets and hardware signers still use seed backups which lack derivation path and script information. Thus we largely use the same approach used in BIPs [[bip-0049.mediawiki|49]] and [[bip-0084.mediawiki|84]] for ease of implementation.

23. ↩ Test vector The same mnemonic gives unrelated keys under purposes 44', 84' and 86' (and the schemes use different output types).

    BIP 84 L77–80 BIP 86 L94

    Quoted source text (2)

    // Account 0, first receiving address = m/84'/0'/0'/0/0

    // Account 0, first receiving address = m/86'/0'/0'/0/0

24. ↩ Author’s rationale BIP 86 notes that because it uses the same method as BIPs 44, 49 and 84 it should not be difficult to implement; BIP 84 points to SLIP-0132 for further registered version bytes.

    BIP 86 L80–81 BIP 84 L59

    Quoted source text (2)

    However this BIP uses the same method used in BIPs 44, 49, and 84, so it should not be difficult to implement.

    Additional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]].