Glossaire / Adresses et clés
Dérivation BIP-86
- Qu'est-ce que la dérivation BIP-86 ?
- La dérivation BIP-86 place les comptes Taproot à clé unique à m/86'/0'/0', puis ajuste chaque clé dérivée avec son propre hachage afin que l'adresse s'engage sur un chemin de script non dépensable.
Spécifié dans BIP-86.
Le BIP-86 couvre les portefeuilles détenant des sorties Taproot pour un signataire unique, en réutilisant la structure de compte du BIP-44 avec 86' au niveau purpose. Le BIP-49 et le BIP-84 définissent aussi une seconde étape d'adresse, mais seul le BIP-86 modifie la clé elle-même : la valeur de 32 octets dans votre adresse est la clé que vous avez dérivée, ajustée par un hachage d'elle-même. Restaurez vos mots dans un logiciel qui n'analyse que le BIP-84 et le solde de votre bc1p affiche zéro.
Comment cela fonctionne
La dérivation BIP-86 se fait en deux étapes, et seule la première est la descente familière dans un arbre de clés.
La première étape est le chemin. Le modèle est m / purpose' / coin_type' / account' / change / address_index, avec 86' dans l'emplacement purpose et chaque niveau en dessous utilisé sans modification, de sorte qu'un premier compte bitcoin se situe à m/86'/0'/0' et sa première clé de réception à m/86'/0'/0'/0/0.
La seconde étape est celle où le BIP-86 se sépare de ses prédécesseurs. Le BIP-49 et le BIP-84 définissent eux aussi une seconde étape, mais la leur enveloppe la clé dérivée dans un script et le témoin révèle encore la clé produite par le chemin. Le BIP-86 remplace la clé. Il cite le BIP-341 sur la règle qu'il doit respecter : "If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path." La clé dérivée est donc lue comme clé interne via lift_x, et ce qui parvient à la chaîne est cette clé interne plus int(HashTapTweak(bytes(internal_key)))G. Le résultat est un seul push de 32 octets derrière OP_1, écrit 0x5120 suivi de la clé ajustée, et le dépenser ne demande qu'une signature dans le témoin avec un scriptSig vide.
Les vecteurs de test publiés montrent l'écart. À m/86'/0'/0'/0/0 la clé interne dérivée de la phrase de récupération est cc8a4bc64d897bddc5fbc2f670f7a8ba0b386779106cf1223c6fc5d7cd6fc115, tandis que la clé que le réseau voit est a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c, encodée en bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr. Une implémentation qui saute la seconde étape publie la première valeur à la place, et vous remet donc des adresses d'apparence plausible qu'un portefeuille conforme restaurant la même phrase de récupération ne trouvera jamais.
Ava Chow a écrit le document, qui a été attribué le 22 juin 2021 et porte aujourd'hui le statut Deployed.
Où le rencontre-t-on
La dérivation BIP-86 se trouve derrière la plupart des portefeuilles à signataire unique qui vous donnent une adresse bc1p sans demander quel format vous voulez. Bitcoin Core a fait des portefeuilles à descripteurs le réglage par défaut dans la version 23.0, et les notes de version de cette version indiquent qu'un portefeuille à descripteurs nouvellement créé contient un descripteur tr() généré automatiquement "which allows for creating single key Taproot receiving addresses".
Le matériel a rattrapé son retard à des rythmes très différents. Notre avis sur KeepKey date la prise en charge des sorties Taproot de cet appareil au micrologiciel 7.10.0 en février 2025, de sorte qu'un signataire bon marché peut détenir une phrase de récupération dont il ne vous montrera pas la branche 86', tandis que d'autres logiciels lisant les mêmes mots dépensent ces bitcoins normalement.
La spécification est d'une franchise inhabituelle sur la raison pour laquelle un chemin fixe reste nécessaire. Sa section motivation accorde que "there are now solutions which obviate the need for fixed derivation paths for specific script types", ce qui désigne les descripteurs, puis nomme pourquoi ils ne tranchent pas la question : de nombreux portefeuilles logiciels et signataires matériels sauvegardent encore la phrase de récupération seule, sans aucune trace du chemin ni du type de script à côté. Un descripteur porte cette information ; une liste de mots non, alors c'est le nombre 86 qui la porte à sa place.
Dérivation BIP-86 vs P2TR
La dérivation BIP-86 est une recette pour remplir une sortie P2TR, pas la définition d'une telle sortie. P2TR est la version de témoin 1 et accepte n'importe quelle clé de sortie de 32 octets, y compris une clé agrégée à partir de plusieurs signataires sous MuSig2 et une clé s'engageant sur un arbre de scripts réellement utilisables. Le BIP-86 couvre le cas le plus étroit de cet espace : un signataire, une phrase de récupération, et un chemin de script délibérément laissé non dépensable pour que rien ne se cache derrière la clé. Chaque adresse produite par le BIP-86 est une sortie P2TR, et l'essentiel de ce que P2TR peut exprimer sort entièrement de son champ, de sorte qu'un portefeuille qui annonce prendre en charge Taproot peut toujours refuser une branche multisig ou à verrouillage temporel portant le même format d'adresse.