Portefeuilles HD expliqués : comment BIP32 transforme un seed en arbre de clés

Un portefeuille hiérarchique déterministe (HD) dérive un nombre illimité de clés à partir d’une seule phrase de récupération. Comprendre le mécanisme est important pour la récupération : cela explique pourquoi une seule phrase de récupération peut produire de nombreux portefeuilles d’apparence valide, et pourquoi le chemin de dérivation et l’index de compte décident quelles adresses détiennent vos cryptomonnaies.

La clé maîtresse

BIP32 commence par un seed (généralement dérivé d’une phrase BIP-39). Le seed passe par HMAC-SHA512 avec une clé fixe (« Bitcoin seed »), produisant 64 octets : les 32 premiers deviennent la clé privée maîtresse, les 32 derniers deviennent le code de chaîne maître. Les deux sont nécessaires pour dériver les enfants — c’est pourquoi une clé étendue contient une clé plus un code de chaîne.

Clés enfants et codes de chaîne

Chaque clé enfant est dérivée de manière déterministe de son parent :

• Dérivation normale : HMAC-SHA512 de la clé publique parente, du code de chaîne parent et d’un index. Quiconque a un xpub (la clé publique étendue) peut dériver des enfants — c’est ce qui fait fonctionner les portefeuilles watch-only.
• Dérivation renforcée (l’apostrophe, ex. m/44') : HMAC-SHA512 de la clé privée parente, du code de chaîne et de l’index. Elle ne peut être faite que par quelqu’un détenant la clé privée, et elle isole la branche de la clé publique de son parent.

Le code de chaîne est une valeur de 32 octets utilisée pour la dérivation des clés. Il est inclus dans les clés privées étendues comme dans les clés publiques étendues : chaque clé étendue associe une clé à son code de chaîne.

Les niveaux de purpose (BIP43, BIP44, BIP49, BIP84, BIP86)

BIP43 a réservé le premier niveau de l’arbre à un purpose. Les purposes courants sont :

• BIP44 — m/44'/coin'/account'/change/index — adresses legacy (1...)
• BIP49 — m/49'/coin'/account'/change/index — SegWit imbriqué dans P2SH (3...)
• BIP84 — m/84'/coin'/account'/change/index — native SegWit (bc1q...)
• BIP86 — m/86'/coin'/account'/change/index — Taproot (bc1p...)

Sous le purpose se trouvent le type de cryptomonnaie (0' Bitcoin, 60' Ethereum, etc.), le compte, la branche de change (0 = réception, 1 = change) et enfin l’index d’adresse. Chaque niveau est une branche de l’arbre ; le même seed avec deux purposes différents produit deux ensembles d’adresses entièrement différents.

Déterministe contre non-déterministe

• Portefeuilles HD : un seed, un arbre, restaurable partout avec le bon chemin.
• Portefeuilles non-HD (premiers Bitcoin Core, MultiBit Classic) : les clés étaient générées dans un fichier keypool ; sans ce fichier (ou sa sauvegarde), un seed ne peut pas les reconstruire. C’est pourquoi les vieux fichiers de portefeuille comptent.

Ce que cela signifie pour la récupération

• Un seed correct n’est que la moitié de la réponse : le chemin de dérivation et l’index de compte décident quelles adresses sont vérifiées.
• Un mauvais chemin ou compte produit des adresses valides mais vides — pas une erreur.
• Un xpub permet au logiciel de dériver les clés publiques enfants et leurs adresses dans sa branche par dérivation normale, mais pas de restaurer les clés privées. Il contient des métadonnées du nœud, pas le chemin de dérivation complet ; ce chemin nécessite des informations séparées.
• Les gap limits et adresses de change sont les conséquences pratiques de cette structure d’arbre : les portefeuilles analysent une fenêtre bornée d’adresses inutilisées.

La référence des chemins liste les valeurs par défaut pratiques ; cette page est le mécanisme qui les sous-tend.