Un HD Wallet calcule de nombreuses clés liées entre elles à partir d'un même point de départ secret, le seed. Les clés privées signent les paiements ; leurs équivalents publics servent à créer les adresses de réception. Le portefeuille peut ainsi utiliser de nouvelles adresses sans sauvegarde distincte pour chacune.
Alice ouvre l'écran de réception, et son portefeuille affiche une adresse. Elle y reçoit 10 000 satoshis, les petites unités du bitcoin. Pour le paiement suivant, l'application propose une autre adresse, qui reçoit 20 000 satoshis. Si ce sont ses seules sommes reçues et non dépensées, le portefeuille affiche un total de 30 000 satoshis. La nouvelle adresse n'a pas créé un compte indépendant, et les fonds précédents n'ont pas été déplacés automatiquement. L'application gère les clés correspondant aux deux paiements. Un HD Wallet facilite ce fonctionnement. HD signifie Hierarchical Deterministic : hiérarchique parce que les clés forment une structure ramifiée, et déterministe parce que le même seed et le même chemin donnent les mêmes clés, y compris lors d'une restauration. Un chemin est une suite de nombres indiquant au logiciel quelle branche et quelle clé calculer. Alice n'a généralement pas à s'en préoccuper pour recevoir un paiement, mais la restauration doit utiliser les bons chemins. Une sauvegarde du secret initial peut donc couvrir aussi les adresses futures ; il faut néanmoins conserver les paramètres du portefeuille. De nouvelles adresses évitent leur réutilisation, sans garantir à elles seules l'anonymat. [1] [12]
Une clé publique étendue, couramment appelée xpub, permet de calculer les clés publiques d'une partie de cette structure. Elle ne contient pas les clés privées nécessaires pour signer un paiement. Un xpub seul ne permet donc pas de dépenser ; pour créer des adresses précises, l'application doit aussi connaître leur format. Un portefeuille watch-only doté du bon xpub peut créer des adresses et suivre les paiements sans clés de signature. Une fuite du xpub peut pourtant relier les adresses passées et futures de cette branche, les soldes et les transactions. Ne partagez que la branche nécessaire. Même un xpub correct n’empêche pas un ordinateur compromis d’afficher une adresse étrangère. Vérifiez l’adresse de réception sur un appareil de signature fiable qui connaît le portefeuille. [1] [12] [14]
Une boutique peut créer une adresse différente pour chaque commande. Le site doit connaître ces adresses, mais ne devrait pas détenir les clés permettant de dépenser les recettes. BIP32 sépare cette branche de réception du reste du portefeuille. Pieter Wuille a rédigé la proposition, attribuée le 11 février 2012. C’est une norme de portefeuille, pas une règle de consensus. Les mots de sauvegarde BIP39, les types de script et la procédure complète de restauration relèvent d’autres couches. [1] [11] [12]
BIP32 ajoute à la clé un chain code de 256 bits, soit 32 octets pour les dérivations suivantes. La forme privée associe un scalaire k de secp256k1 au chain code c ; la forme publique utilise K = point(k) et le même c. La clé maîtresse provient de HMAC-SHA512, avec la chaîne exacte « Bitcoin seed » comme clé de la fonction et le seed comme données. Les 32 octets de gauche sont le candidat à la clé privée, les 32 de droite le chain code. Zéro ou une valeur au moins égale à l’ordre n de la courbe rend la clé maîtresse invalide. [1]
La dérivation est un calcul, pas une recherche dans une liste enregistrée. Il existe une dérivation normale et une dérivation hardened. La première permet de calculer les clés publiques suivantes à partir de la clé publique étendue parente ; une étape hardened exige la clé privée étendue parente. CKDpriv calcule I = HMAC-SHA512(cpar, data), le sépare en IL et IR et ajoute parse256(IL) à la clé privée parente modulo n. IR devient le nouveau chain code. La dérivation normale utilise serP(Kpar) || ser32(i), la dérivation hardened utilise 0x00 || ser256(kpar) || ser32(i), avec i ≥ 2^31. CKDpub ne produit que des branches publiques normales en ajoutant point(parse256(IL)) à Kpar. Un autre numéro de branche change les clés dérivées ensuite. [1]
Un xpub permet de dériver des clés publiques tant que le chemin ne franchit pas une étape hardened. Cela a une contrepartie : le xpub parent associé à une clé privée divulguée d’un enfant normal permet de calculer la clé privée parente. Les autres branches sont alors menacées aussi. Hardened bloque ce calcul inverse, mais ne protège ni contre le vol du seed, ni contre une mauvaise source aléatoire ou la validation d’une transaction malveillante. [1]
Sur mainnet, l’encodage public standard commence par xpub, le privé par xprv ; leurs versions sont 0x0488B21E et 0x0488ADE4. Avant Base58Check, l’enregistrement fait 78 octets : version 4, profondeur 1, empreinte parente 4, numéro enfant 4, chain code 32 et données de clé 33. Le résultat comporte 111 caractères. L’empreinte courte aide à associer les clés, sans prouver une identité. Les préfixes ypub/zpub de SLIP132 indiquent parfois un type de script ; changer le préfixe ne modifie pas à lui seul les clés ni les règles du portefeuille. [1] [9]
BIP43 réserve le premier niveau hardened à l’usage prévu. BIP44 utilise m / 44' / coin_type' / account' / change / address_index. Après le compte viennent la branche 0 de réception ou 1 de monnaie rendue, puis le numéro d’adresse. L’apostrophe ou h indique un indice augmenté de 2^31. La recherche BIP44 applique un gap limit de 20 : elle s’arrête après 20 adresses de réception consécutives inutilisées. BIP48 décrit Multisig, BIP84 l’usage 84' pour SegWit natif et BIP86 l’usage 86' pour Taproot à une seule clé. Ces conventions ne sont ni stockées dans le seed ni imposées par les nœuds. [2] [3] [4] [5] [6]
Les clés seules ne définissent pas le script protégeant les fonds. Un Output Descriptor peut enregistrer l’origine des clés, les chemins, une construction telle que wpkh(), le nombre de signatures requis, les autres participants Multisig et une somme de contrôle. Un descripteur multipath peut réunir réception et monnaie rendue. Le seed d’un participant ne reconstruit ni les autres xpub ni les règles communes. Sauvegardez aussi un descripteur public vérifié ou un export de configuration et protégez sa confidentialité. S’il contient des clés privées, traitez-le comme un secret. [7] [8] [10] [13]
Le seed permet de dériver les clés de nouveau, mais l’application doit connaître son format, l’éventuelle BIP39 passphrase, le réseau, le type de script, coin type, les comptes, les deux branches et la plage de recherche. Multisig exige aussi la configuration commune. Un solde nul ne prouve pas une perte : la recherche peut suivre un autre chemin. Un test sûr sur un appareil fiable doit retrouver les bons UTXO, c’est-à-dire les sorties de transaction encore non dépensées, et vérifier la signature. Ne saisissez jamais un véritable seed ou des mots de sauvegarde dans un outil web ou sur un ordinateur ordinaire connecté. [3] [7] [10] [11]
BIP32 traite aussi de rares résultats invalides : parse256(IL) ≥ n, une clé privée dérivée nulle ou un point public à l’infini. L’indice suivant est alors essayé. Plus souvent, la restauration manque du chemin, de la branche de monnaie rendue ou d’un type de script compatible. Avant de changer d’application, vérifiez la détection des fonds et un petit transfert d’essai. Gardez la sauvegarde et la configuration d’origine jusqu’à validation de la nouvelle procédure. Le xprv fournit les clés nécessaires à la signature, le xpub révèle des liens financiers et le descripteur indique comment construire le portefeuille. [1] [7] [9] [10]
Pour une vision complète, lisez aussi Portefeuille, Seed Phrase, Extended Public Key (xpub), Derivation Path, Gap Limit, Bitcoin. Cette entrée est également citée par Adresse Bitcoin, BIP 39, Cold Storage, Watch-only Wallet.