Derivation Path

Anna is restoring a wallet when the software asks for a path she never had to think about before. A wallet is an application or device for receiving and sending bitcoin. m/0/7 looks complicated, but it is read in order: m is the master private node, from which child key 0 is derived, followed by its child key 7. Here a node is a position in the key tree, not a computer on the Bitcoin network. The numbers are indices, meaning positions, not amounts or transaction numbers. The BIP 32 standard uses an extended key: alongside the key itself it includes a chain code, extra data needed to derive further keys. The written path without the starting key therefore cannot sign a payment. [1] [10]

Consider m/84'/0'/0'/0/7. The first part after m identifies the BIP 84 convention for native SegWit, a way of constructing addresses and spending funds. Next come Bitcoin mainnet, the main network with real bitcoin, account 0, external receiving branch 0 and index 7. This is the eighth address position because counting starts at zero. An account separates a group of funds, while a branch identifies the addresses’ purpose. In the BIP 44 arrangement, branch 1 is for your own change, the amount remaining with the sender after a payment. The first three steps have an apostrophe and are hardened; the last two are normal. What does that marker change? [2] [5]

A private key is a secret numerical value that a wallet uses to create a digital signature authorizing a spend. Hardened identifies a derivation method that requires the parent private key. A normal step can derive a child public key from an xpub, an extended public key. With the relevant script type, that lets software construct addresses without the ability to sign payments. An xpub alone cannot cross a hardened step. Under BIP 380, 0' and 0h mean the same thing, not normal 0. For technical readers, BIP 32 divides 32-bit indices into normal 0 through 2^31−1 and hardened 2^31 through 2^32−1; the marker maps zero to index 2^31. Leaving it out changes the calculation, not just the appearance of the path. [1] [7] [10]

BIP 43 calls the first hardened level purpose, indicating the intended arrangement. Agreed values help wallets know how a branch is normally used. As a reference, 44' identifies traditional P2PKH, a payment protected by a public-key hash; 49' identifies P2SH-P2WPKH, SegWit inside an older wrapper for compatibility; 84' identifies native P2WPKH; and 86' identifies single-key P2TR, a Taproot construction with one internal key. These are different ways to set the conditions for spending money. A number alone does not magically turn the path into the corresponding script or enforce it through network consensus. Software still has to construct the correct output. Not every wallet uses these conventions. [3] [2] [4] [5] [6]

Anna might connect just an account xpub rather than the entire wallet to view incoming payments. If it comes from m/84'/0'/0', it is already at account level. The relative suffix /0/7 is all that remains to reach our earlier example. Adding the whole root path again would start further derivation from the wrong place; its hardened steps cannot be performed from an xpub anyway. An exported extended key carries its depth in the tree and the parent fingerprint, a short identifying tag, but not a complete record of earlier steps. The missing original path therefore cannot always simply be read from the xpub itself. [1] [7]

A Descriptor describes keys and spending conditions so software can construct the outputs it watches. BIP 380 allows the key’s origin fingerprint and path to appear in square brackets before it. Those steps have already happened. A suffix after the key specifies further derivation; an asterisk * can stand for a series of descendants. The fingerprint is four bytes and can collide: different keys can have the same short tag. It is neither proof of identity nor a substitute for the key. Bitcoin Core 29.0 provides deriveaddresses through RPC, the node’s programming interface. It calculates addresses from a descriptor and any specified range; that calculation alone neither checks balances nor sends funds. [7] [1] [9]

A path alone cannot produce your keys without the starting data. Sharing an xpub is different: its recipient can derive public keys within the accessible branch and, with the appropriate script type, follow its addresses. That grants no spending authority but can damage privacy. BIP 32 also warns about a less obvious risk: a parent xpub combined with a leaked private descendant reachable through normal steps can reveal the parent extended private key. A hardened boundary blocks this particular route back to the parent. It does not invalidate the leaked key or rescue funds controlled by that key. [1]

Back to recovery. Seed Phrase means your backup words. Under BIP 39, those words and any optional passphrase produce the seed, the starting secret for generating keys. The passphrase is extra secret text, not the ordinary application password. With a different seed, the same path leads to different keys. The network, account, branch and script type must also match. Software must search enough addresses and history: Gap Limit stops discovery after a run of unused addresses. A zero balance alone therefore does not prove the keys are lost. Anna can compare the result with a known receiving address and earlier payments. Software accepting a path only shows that it can process it, not that it has found the entire original wallet. [8] [2] [7]