Derivation Path est une suite ordonnée d’indices normaux et hardened utilisée pour dériver une clé selon BIP 32. Ce n’est ni une seed, ni une clé privée, ni une adresse ; la même notation sur une autre clé de départ produit d’autres clés.
Dans m/0/7, m désigne le nœud privé maître et chaque barre ajoute une dérivation : d’abord l’enfant 0, puis son enfant 7. La dérivation utilise une clé étendue avec son chain code. Ces nombres ne sont ni des montants ni des numéros de transaction ; le chemin seul ne fournit aucun matériau de signature. [BIP 32 — Hierarchical Deterministic Wallets]
BIP 32 divise les indices sur 32 bits en normaux, de 0 à 2^31−1, et hardened, de 2^31 à 2^32−1. 0' et 0h désignent tous deux l’indice hardened 2^31, pas le 0 normal ; BIP 380 accepte l’apostrophe et h. Un enfant public normal peut être obtenu à partir d’un xpub, mais pas un enfant hardened avec ce seul xpub. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 380 — Output Script Descriptors]
L’exemple m/84'/0'/0'/0/7 désigne la convention BIP 84, Bitcoin mainnet, le compte 0, la branche externe de réception 0 et l’indice 7, soit la huitième position d’adresse. Les trois premiers niveaux sont hardened, les deux derniers normaux. Dans BIP 44, la branche 1 sert à sa propre monnaie rendue ; les indices commencent à zéro. [BIP 44 — Multi-Account Hierarchy] [BIP 84 — Native P2WPKH derivation]
BIP 43 réserve le premier niveau hardened au purpose. La convention 44' correspond à P2PKH, 49' à P2SH-P2WPKH, 84' à P2WPKH et 86' à single-key P2TR. Le nombre seul n’impose aucun script au consensus ; le logiciel doit construire la sortie correspondante. Tous les portefeuilles ne suivent pas ces conventions. [BIP 43 — Purpose Field] [BIP 44 — Multi-Account Hierarchy] [BIP 49 — P2WPKH nested in P2SH] [BIP 84 — Native P2WPKH derivation] [BIP 86 — Single Key P2TR Outputs]
Si un xpub a déjà été exporté au niveau m/84'/0'/0', le suffixe relatif /0/7 suffit pour ce descendant. Ajouter de nouveau tout le chemin racine à un xpub de compte réalise une autre dérivation, et ses étapes hardened sont de toute façon impossibles depuis ce xpub. La profondeur et le fingerprint parental sérialisés ne contiennent pas tout l’historique du chemin d’origine. [BIP 32 — Hierarchical Deterministic Wallets] [BIP 380 — Output Script Descriptors]
BIP 380 permet une origine fingerprint/chemin entre crochets avant la clé et un suffixe de dérivation après elle. L’origine décrit des étapes déjà effectuées ; le suffixe reste à dériver. Le descriptor précise aussi le script et peut inclure une plage via *. Le fingerprint fait quatre octets et peut présenter des collisions ; ce n’est ni une preuve d’identité ni un substitut de la clé. [BIP 380 — Output Script Descriptors] [BIP 32 — Hierarchical Deterministic Wallets] [Bitcoin Core 29.0 — deriveaddresses RPC]
BIP 32 avertit qu’un xpub parental associé à un descendant privé normal divulgué peut révéler la clé privée étendue du parent. Une frontière hardened sépare ce mécanisme précis, sans protéger la clé déjà divulguée. Un xpub partagé expose aussi sa branche publique et peut nuire à la confidentialité même s’il ne signe pas seul. [BIP 32 — Hierarchical Deterministic Wallets]
La restauration vérifie la bonne seed et l’éventuelle passphrase, le réseau, le compte, la branche, le script et la plage de recherche, dont Gap Limit. Une syntaxe valide peut pointer vers une autre branche vide ; un solde nul ne prouve donc pas que les clés sont erronées. La vérification se fait avec une adresse de réception et un historique connus, pas seulement parce que le logiciel accepte le chemin. [BIP 39 — From mnemonic to seed] [BIP 44 — Multi-Account Hierarchy] [BIP 380 — Output Script Descriptors]
Pour une vision complète, lisez aussi HD Wallet, Extended Public Key (xpub), Gap Limit, Output Descriptor, BIP 39. Cette entrée est également citée par HD Wallet, Watch-only Wallet, Sortie de monnaie, Extended Public Key (xpub).