MSTR Cat

Blockchain/Niveau IV · Le protocole en profondeur/4.3 Conservation et confidentialité/Leçon 1

Portefeuilles HD (BIP32, BIP44, BIP84, BIP86)

Dériver un arbre de clés à partir d’une graine

MatérielUn portefeuille en mode test (testnet ou signet), jamais une vraie graineUn portefeuille HD ou un outil qui affiche les chemins de dérivationUn carnet

Curiosité

  1. Comment une seule graine peut-elle générer un nombre pratiquement illimité de clés privées uniques et récupérables ?
  2. Pourquoi une seule clé privée enfant divulguée, associée à la clé publique étendue du parent, peut-elle exposer toutes les clés d’une branche non durcie ?
  3. Quelle différence structurelle distingue une adresse P2PKH legacy d’une adresse SegWit native ou Taproot en matière d’efficacité des frais ?

Explorer

  1. Avant BIP32, introduit par Pieter Wuille en 2012, les portefeuilles généraient des paires de clés aléatoires pour chaque nouvelle adresse. Sauvegarder le portefeuille signifiait stocker chaque clé privée individuellement ; perdre un fichier de sauvegarde rendait les fonds correspondants irrécupérables. BIP32 a changé ce modèle en dérivant un arbre de clés déterministe à partir d’une seule graine maîtresse. Tout l’historique financier est désormais ancré dans cette unique graine, généralement créée à partir de 128 ou 256 bits d’entropie et notée sous forme de 12 ou 24 mots.
  2. Le chemin de dérivation suit la structure définie dans BIP44 (2014) : `m / purpose' / coin_type' / account' / change / index`. L’apostrophe indique une dérivation durcie. Il s’agit d’un mécanisme de sécurité essentiel. Avec une dérivation non durcie, si un attaquant obtient à la fois la clé publique étendue parente (xpub) et une seule clé privée enfant, quelle qu’elle soit, il peut calculer mathématiquement la clé privée parente. La dérivation durcie rompt ce lien : une clé privée enfant divulguée, combinée à l’xpub, ne révèle rien du secret du parent.
  3. BIP44 a standardisé les trois premiers niveaux afin de permettre la prise en charge de plusieurs cryptomonnaies au sein d’une même hiérarchie. Le niveau `purpose'` identifie le standard (par exemple 44 pour BIP44, 84 pour BIP84). Le niveau `coin_type'` distingue les actifs ; Bitcoin a l’indice 0. Une seule graine peut ainsi gérer différentes cryptomonnaies sans mélanger leurs clés. Le niveau `account'` organise les fonds en comptes distincts, chacun avec sa propre chaîne de change. Les clés publiques étendues (xpubs) sont généralement dérivées à ce niveau de profondeur.
  4. BIP84 a mis à jour le standard pour les adresses SegWit natives commençant par `bc1q`. Il fixe le purpose à 84. Ces adresses sont plus efficaces que les formats legacy, car leurs données de témoin (witness) bénéficient d’une réduction dans le calcul du poids de la transaction, ce qui diminue les frais. Le chemin de dérivation devient `m / 84' / 0' / account' / change / index`. Par exemple, la première adresse externe du compte 0 est dérivée en `m/84'/0'/0'/0/0`. Cette structure permet à des serveurs de générer des adresses de réception à partir d’une xpub sans jamais toucher à une clé privée.
  5. BIP86, un standard de dérivation distinct rédigé par Ava Chow en 2021 pour Taproot, fixe le purpose à 86 et dérive des adresses Taproot à clé unique commençant par `bc1p`. BIP86 couvre les sorties Taproot à clé unique sans arbre de scripts. Comme le chemin de clé (key path) de Taproot peut aussi contenir une clé agrégée, par exemple une clé MuSig2, les sorties d’un portefeuille multipartite peuvent sembler on-chain exactement identiques à ces sorties à clé unique.
  6. Les portefeuilles analysent les adresses en avance pour détecter celles qui ont été utilisées, et s’arrêtent généralement après une « gap limit » de 20 adresses inutilisées consécutives sur une chaîne. Si aucune transaction n’est trouvée dans cette plage, le portefeuille considère qu’il a découvert toutes les clés existantes de ce compte. Pour vérifier ce mécanisme, ouvrez n’importe quel portefeuille HD moderne et repérez les paramètres de son chemin de dérivation. Identifiez chaque niveau : purpose, type de monnaie, compte, change et index. Dérivez deux chemins différents à partir de la même graine pour confirmer qu’ils produisent des clés distinctes tout en restant entièrement récupérables à partir de la phrase mnémonique d’origine.

Faits clés

  • BIP32 dérive un arbre déterministe de clés enfants à partir d’une seule graine maîtresse.
  • La dérivation durcie (marquée par `'`) empêche la fuite de la clé parente si une clé privée enfant et l’xpub sont compromises.
  • La structure de chemin BIP44 est `m / purpose' / coin_type' / account' / change / index`.
  • Le purpose 84 correspond aux adresses SegWit natives (`bc1q`), plus économiques en frais que les formats legacy.
  • Le purpose 86 correspond aux adresses Taproot à clé unique (`bc1p`).
  • Les portefeuilles cessent généralement l’analyse après 20 adresses inutilisées consécutives (la gap limit).

Exercice neuf, six, trois, un

9RassemblerListez 9 chemins de dérivation provenant de différents portefeuilles ou standards. Indiquez pour chacun le purpose (finalité), le type de monnaie et le format d’adresse.
6RegrouperRegroupez les 9 en 6 catégories selon leur type de script : P2PKH legacy, SegWit imbriqué (nested), SegWit natif, Taproot, multidevise ou autre.
3DistillerRéduisez les 6 à 3 raisons pour lesquelles un développeur de portefeuille choisirait un chemin de dérivation plutôt qu’un autre.
1CristalliserRédigez 1 phrase expliquant comment la dérivation durcie protège une clé maîtresse contre toute exposition via les clés enfants.

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

Ouvrir dans l'académie interactive →

EN PT ES ZH JA KO RU DE MS