BIP48 expliqué : le chemin de dérivation derrière SSP

Jusqu'ici dans cette série nous avons couvert ce qu'est le multisig et quel seuil choisir. Les deux articles décrivaient le comportement d'un portefeuille multisig — m clés sur n signent, la chaîne vérifie le seuil, l'argent bouge. Ni l'un ni l'autre ne disait grand-chose sur comment le portefeuille est réellement assemblé en dessous. C'est cet article.

Version courte : quand SSP crée un portefeuille pour vous, il ne se contente pas de générer deux clés aléatoires et de tourner la page. Il les génère d'une manière qui suit un standard documenté appelé BIP48, de sorte que le portefeuille résultant est interopérable, récupérable depuis un logiciel autre que SSP, et prévisible à inspecter on-chain. C'est l'article qui explique ce qu'est BIP48, pourquoi il existe, et pourquoi « ce portefeuille utilise BIP48 » est l'une des phrases les plus ennuyeuses et importantes du multisig.

TL;DR

• Un chemin de dérivation est la route depuis une seule seed phrase jusqu'à une clé spécifique (et adresse) dans un portefeuille. Des chemins normalisés comme BIP44 / BIP48 permettent à différents logiciels de portefeuille d'arriver aux mêmes clés depuis la même seed.
• BIP48 est la spec spécifique aux portefeuilles multisig. Elle dit : voici le chemin de dérivation canonique pour les m clés qui composent un portefeuille 2-of-3, 3-of-5, etc., à travers les principaux types de script de sortie.
• SSP utilise BIP48. Cela signifie que les deux seeds générées par votre portefeuille SSP sont utilisables depuis tout autre portefeuille compatible BIP48 (Sparrow, Electrum, les descriptors de Bitcoin Core) — pas seulement depuis SSP.
• BIP48 corrige un problème qu'avait la spec multisig antérieure (BIP45) : il sépare proprement les clés pour les différents types de script (legacy, P2SH-wrapped SegWit, native SegWit, Taproot) afin qu'une seule seed phrase puisse les tenir toutes sans collision.
• Vous n'avez pas besoin de manipuler les chemins de dérivation à la main pour utiliser SSP. Vous devriez savoir qu'ils existent pour que « la récupération du portefeuille » ne semble pas être de la magie — et pour comprendre ce à quoi votre seed correspond réellement.

Tour en 30 secondes des chemins de dérivation

Avant que BIP48 ait un sens, la mécanique en dessous devait exister. Cette mécanique est BIP32 : les portefeuilles hierarchical deterministic (HD). L'idée centrale est qu'une clé maîtresse — dérivée d'une seed phrase — peut produire un arbre infini de clés enfants, de manière déterministe. Parcourez un chemin particulier dans l'arbre et vous arriverez toujours à la même clé enfant. Parcourez-en un autre et vous arriverez à une autre.

Les chemins ressemblent à ça :

m / purpose' / coin_type' / account' / change / index

Par exemple, le chemin BIP44 m / 44' / 0' / 0' / 0 / 0 atteint la première adresse de réception du premier compte de Bitcoin sous les règles BIP44. Changez le coin_type en 60' et vous êtes dans l'espace Ethereum ; changez le purpose en 84' et vous êtes dans l'espace BIP84 (native SegWit) ; et ainsi de suite. L'apostrophe (') est la dérivation hardened — l'enfant ne peut pas être inversé vers son parent. Chaque segment après le maître est un nombre 32 bits, partitionné par convention.

C'est la partie qu'on passe en vitesse : le chemin est une métadonnée, pas un secret. Quiconque connaît votre chemin et votre clé privée (ou clé étendue) peut dériver les mêmes adresses. Le chemin dit au portefeuille où regarder. La seed lui dit ce qu'il y a.

Pour un rappel sur ce qu'est la seed elle-même, le post seed phrase best practices est le prérequis.

Ce que spécifie BIP48

BIP48 vit à m / 48' / coin_type' / account' / script_type' / change / index. L'ajout intéressant est script_type' — l'avant-dernier segment.

Ce segment encode quel type de sortie multisig le chemin sert :

• 0' → P2SH (multisig legacy)
• 1' → P2SH-wrapped SegWit (P2WSH-in-P2SH)
• 2' → native SegWit (P2WSH)
• 3' → multisig équivalent Taproot (selon les amendements à BIP48)

C'est important parce qu'en pratique le même ensemble de cosigners m-of-n produit des adresses différentes on-chain selon le script de sortie utilisé. Sans BIP48, un portefeuille pourrait silencieusement utiliser un type, le logiciel de récupération en supposer un autre, et le résultat ce sont deux portefeuilles qui paraissent devoir dériver les mêmes pièces — mais qui ne le font pas, parce qu'ils calculent des adresses différentes.

BIP48 fixe aussi le segment purpose' à 48', donc les chemins multisig ne peuvent pas entrer en collision avec les chemins single-sig BIP44/BIP49/BIP84. Une seed peut contenir un portefeuille single-sig à BIP84 et un portefeuille multisig 2-of-2 à BIP48, sans interférence. Chacun vit dans son propre sous-arbre.

Au-delà du chemin lui-même, BIP48 spécifie comment les clés publiques des cosigners (« xpubs ») doivent être ordonnées au moment de construire la sortie multisig. La règle canonique est l'ordonnancement lexicographique des clés publiques avant qu'elles entrent dans le redeem script. Cela supprime l'ambiguïté — tout portefeuille conforme à BIP48 qui construit à partir des mêmes xpubs calcule la même adresse. Sans cette règle, deux portefeuilles pourraient combiner les mêmes clés dans des ordres différents et se retrouver à des adresses différentes avec la même règle de redeem.

Si vous voulez lire la spec à la lettre, elle vit dans le repo Bitcoin BIPs (bips/bip-0048.mediawiki).

Comment SSP utilise BIP48 en pratique

Quand vous configurez un portefeuille SSP, deux seed phrases sont générées — une dans l'extension de navigateur, une dans l'app mobile SSP Key. Chaque seed phrase correspond à une clé privée maîtresse. À partir de chaque maîtresse, SSP dérive le chemin BIP48 pour la chaîne pertinente (Bitcoin, Ethereum, Flux et le reste du panel supporté par SSP) en script_type' = 2' (native SegWit sur Bitcoin ; formes canoniques équivalentes sur les autres chaînes là où c'est applicable).

Les xpubs des deux signataires sont ensuite échangés. Chaque côté a maintenant le même ensemble de deux xpubs, ordonnés lexicographiquement selon BIP48. À partir de cette paire, chaque côté calcule indépendamment la même adresse. Les deux moitiés ne partagent jamais de clé privée — seules les clés publiques voyagent entre les appareils.

Quand vous recevez de l'argent, l'adresse affichée est l'adresse dérivée BIP48 calculée à partir des deux xpubs. Quand vous dépensez, chaque appareil signe la même transaction sous sa propre clé privée. Le redeem script on-chain référence les deux clés publiques ; le réseau vérifie les deux signatures. C'est tout le protocole.

La raison pour laquelle ça compte dans un scénario de récupération : si SSP, en tant que produit, disparaissait demain, vous détiendriez toujours deux seed phrases conformes à BIP48. Les charger toutes deux dans Sparrow (ou tout autre portefeuille multisig qui supporte les chemins BIP48 que SSP utilise) reconstruit le même portefeuille, aux mêmes adresses, avec une pleine capacité de dépense. Le portefeuille ne vit pas à l'intérieur de SSP — il vit on-chain, et les seeds plus la spec BIP48 suffisent à l'atteindre depuis n'importe où.

C'est en grande partie pourquoi la pièce self-custody-without-cold-storage traite un portefeuille SSP 2-of-2 comme un portefeuille sérieux plutôt que comme une curiosité à saveur custodiale. Il est récupérable à partir de standards ouverts.

Pourquoi BIP48 plutôt que BIP45 (et pas BIP44)

La spec multisig antérieure était BIP45. C'était une honnête première tentative : m / 45' / cosigner_index' / change / index, avec cosigner_index' encodant quel cosigner vous êtes dans le portefeuille. Rétrospectivement, elle avait deux problèmes.

D'abord, cosigner_index' cuisinait un ordre dans le chemin lui-même. Cela voulait dire que l'ordre dans lequel les signataires étaient ajoutés affectait la dérivation, ce qui rendait le setup conjoint fragile — vous trompez d'ordre et vous dérivez des adresses différentes de votre cosigner. BIP48 résout ça en enlevant entièrement le cosigner index du chemin et en laissant l'ordonnancement lexicographique des clés publiques s'en charger.

Ensuite, BIP45 ne séparait pas par type de script. Le même chemin serait réutilisé que le portefeuille utilise du multisig P2SH legacy ou du multisig SegWit-wrapped. Cela créait le même problème de collisions-d'adresses-mais-pas-les-mêmes-pièces décrit ci-dessus.

BIP44, la spec HD plus générale, n'a jamais prétendu couvrir le multisig. Surcharger BIP44 avec des chemins multisig créait ses propres conflits. BIP48 a été la correction explicite : un purpose number dédié, un slot de script-type explicite, et un ordonnancement déterministe des clés. Aujourd'hui la plupart des portefeuilles multisig modernes convergent dessus ; c'est le standard de facto.

Pour l'histoire plus profonde de la façon dont cela se relie au chapitre suivant du multisig — l'agrégation Schnorr, où plusieurs signatures se compressent en une — l'article suivant de cette série, Schnorr signatures and multisig aggregation, reprend le fil.

Ce que cela signifie pour l'interopérabilité

Le test le plus propre de « ce portefeuille multisig est-il vraiment self-custodial ? » est : puis-je le récupérer sans le logiciel du portefeuille ? Si la réponse est oui — en utilisant des seeds documentées, un chemin de dérivation documenté et des outils standards — le portefeuille est sincèrement à vous. Si la réponse est non, le portefeuille a des éléments custodial cachés.

La conformité BIP48 de SSP est ce qui nous permet de répondre oui. Les seed phrases sont BIP39 (mnémonique standard), la dérivation est BIP48, la construction d'adresse est canoniquement BIP48. Tout portefeuille qui parle les mêmes standards peut reconstruire le portefeuille.

C'est pourquoi l'introduction Meet SSP Wallet cadre SSP comme « self-custody avec multisig 2-of-2 » plutôt que comme un service géré. Les standards en dessous sont la raison pour laquelle ce cadrage est honnête.

Ce que cela signifie pour vous

Trois conclusions :

1. Vous n'avez pas à mémoriser les chemins pour utiliser SSP. Le nombre m/48'/0'/0'/2'/0/0 n'est pas quelque chose qu'un utilisateur normal devrait jamais taper. Mais savoir qu'il existe est ce qui rend « je peux récupérer ce portefeuille sans SSP » une affirmation réelle plutôt qu'une affirmation marketing.
2. Vos deux seeds sont interopérables. Si jamais vous avez besoin de récupérer dans un portefeuille multisig tiers, BIP48 plus vos deux seeds BIP39 plus le coin_type de la chaîne est la recette. La check-list self-custody nomme cela comme étape de répétition pour une raison.
3. Un portefeuille multisig qui n'utilise pas BIP48 (ou similaire) mérite d'être questionné. Si un produit ne peut pas vous dire exactement comment les adresses sont dérivées de vos clés, ce n'est pas de la self-custody — c'est de la custody avec des étapes en plus. La conformité aux standards est ce qui rend l'affirmation « vos clés, vos pièces » vérifiable.