Derivation Path

Anna restaure son portefeuille et le logiciel lui demande un chemin auquel elle n’avait jamais eu à réfléchir. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. m/0/7 semble compliqué, mais se lit dans l’ordre : m est le nœud privé maître, dont on dérive la clé 0, puis la clé 7 à partir de celle-ci. Ici, nœud désigne un emplacement dans l’arbre des clés, pas un ordinateur du réseau Bitcoin. Les nombres sont des indices, des positions, pas des montants ou des numéros de transaction. Le standard BIP 32 utilise une clé étendue comprenant, en plus de la clé, un chain code : des données nécessaires pour dériver d’autres clés. Le chemin écrit sans la clé de départ ne permet donc pas de signer un paiement. [1] [10]

Prenons m/84'/0'/0'/0/7. La première partie après m indique BIP 84 pour SegWit natif, une façon de construire les adresses et les dépenses. Viennent ensuite Bitcoin mainnet, le réseau principal avec de vrais bitcoins, le compte 0, la branche externe de réception 0 et l’indice 7. C’est la huitième position d’adresse, car on compte à partir de zéro. Le compte sépare un groupe de fonds, la branche indique l’usage des adresses. Dans l’organisation BIP 44, la branche 1 sert à la monnaie rendue au portefeuille : la somme qui reste à l’expéditeur après un paiement. Les trois premières étapes portent une apostrophe et sont hardened ; les deux dernières sont normales. Que change cette marque ? [2] [5]

Une clé privée est une valeur numérique secrète dont le portefeuille se sert pour créer une signature numérique autorisant une dépense. Hardened désigne une méthode de dérivation nécessitant la clé privée du parent. Une étape normale permet d’obtenir une clé publique dérivée depuis un xpub, une clé publique étendue. Avec le type de script adéquat, on peut ainsi construire des adresses sans pouvoir signer des paiements. Un xpub seul ne franchit pas une étape hardened. Selon BIP 380, 0' et 0h signifient la même chose, pas le 0 normal. Pour approfondir : BIP 32 répartit les indices sur 32 bits entre normaux de 0 à 2^31−1 et hardened de 2^31 à 2^32−1 ; la marque transforme zéro en indice 2^31. L’omettre change le calcul, pas seulement la présentation. [1] [7] [10]

BIP 43 appelle purpose le premier niveau hardened : il indique l’organisation prévue. Des valeurs convenues aident les portefeuilles à reconnaître l’usage habituel d’une branche. Pour se repérer, 44' correspond au P2PKH traditionnel, un paiement protégé par l’empreinte d’une clé publique ; 49' au P2SH-P2WPKH, du SegWit dans une enveloppe plus ancienne pour la compatibilité ; 84' au P2WPKH natif ; et 86' au single-key P2TR, une construction Taproot avec une clé interne. Ce sont différentes façons de fixer les conditions de dépense. Le nombre seul ne transforme pas le chemin en script correspondant et ne l’impose pas par le consensus du réseau. Le logiciel doit construire la bonne sortie. Tous les portefeuilles n’utilisent d’ailleurs pas ces conventions. [3] [2] [4] [5] [6]

Anna peut connecter uniquement le xpub d’un compte pour suivre les recettes, plutôt que le portefeuille entier. S’il vient de m/84'/0'/0', il se trouve déjà au niveau du compte. Il ne reste que le suffixe relatif /0/7 pour rejoindre notre exemple précédent. Ajouter encore tout le chemin depuis la racine lancerait une autre dérivation depuis le mauvais endroit ; ses étapes hardened sont de toute façon impossibles depuis un xpub. La clé étendue exportée contient sa profondeur dans l’arbre et le fingerprint du parent, une courte empreinte d’identification, mais pas la liste complète des étapes antérieures. On ne peut donc pas toujours retrouver le chemin d’origine manquant en lisant simplement le xpub. [1] [7]

Un Descriptor décrit les clés et conditions de dépense pour construire les sorties surveillées. BIP 380 permet d’écrire avant la clé, entre crochets, le fingerprint et le chemin de son origine. Ces étapes ont déjà été effectuées. Le suffixe après la clé indique les dérivations suivantes ; un astérisque * peut représenter une série de descendants. Le fingerprint fait quatre octets et peut présenter des collisions : des clés différentes peuvent avoir la même courte empreinte. Ce n’est ni une preuve d’identité ni un remplacement de la clé. Bitcoin Core 29.0 propose deriveaddresses par RPC, l’interface de programmation du nœud. La commande calcule les adresses d’un descriptor et de la plage éventuellement précisée ; ce calcul seul ne consulte pas les soldes et n’envoie pas de fonds. [7] [1] [9]

Le chemin seul ne peut produire vos clés sans les données de départ. Partager un xpub est différent : son destinataire peut dériver les clés publiques de la branche accessible et suivre ses adresses avec le type de script approprié. Il ne reçoit aucun droit de dépense, mais la confidentialité peut en souffrir. BIP 32 signale aussi un risque moins évident : un xpub parental associé à une clé privée descendante divulguée, accessible par des étapes normales, peut révéler la clé privée étendue du parent. Une frontière hardened bloque cette voie précise vers le parent. Elle n’annule pas la clé divulguée et ne sauve pas les fonds contrôlés par cette clé. [1]

Revenons à la restauration. Seed Phrase désigne les mots de sauvegarde. Selon BIP 39, ces mots et l’éventuelle passphrase produisent la seed, le secret de départ pour créer les clés. La passphrase est un texte secret supplémentaire, pas le mot de passe habituel de l’application. Avec une autre seed, le même chemin donne d’autres clés. Réseau, compte, branche et type de script doivent aussi correspondre. Il faut enfin parcourir assez d’adresses et d’historique : Gap Limit arrête la recherche après une suite d’adresses inutilisées. Un solde nul ne prouve donc pas à lui seul la perte des clés. Anna peut comparer avec une adresse connue et d’anciens paiements. L’acceptation du chemin montre seulement que le logiciel sait le traiter, pas qu’il a retrouvé tout le portefeuille original. [8] [2] [7]