Descripteur de sortie

Les descripteurs existent parce qu'une clé étendue seule est ambiguë. Le même xpub peut produire des adresses legacy, SegWit imbriquées, SegWit natives ou Taproot, et seule la fonction d'encapsulation tranche la question. Bitcoin Core crée des portefeuilles à descripteur par défaut depuis la version 23.0, publiée en avril 2022, et une sauvegarde multisig sans son descripteur est souvent irrécupérable.

Comment cela fonctionne

Un descripteur est une fonction appliquée à une expression de clé, suivie d'un dièse et de huit caractères de somme de contrôle. La fonction nomme le script : pkh pour legacy, sh(wpkh(...)) pour le SegWit imbriqué, wpkh pour le SegWit natif, tr pour Taproot, et wsh(sortedmulti(2,...)) pour un coffre 2-sur-3.

L'expression de clé porte le reste. Les crochets contiennent l'origine, c'est-à-dire l'empreinte de la clé maîtresse et le chemin utilisé pour atteindre cette clé, comme dans [1a2b3c4d/84h/0h/0h]. La clé étendue suit, puis un suffixe tel que /0/* où l'astérisque est un caractère générique représentant tour à tour chaque index d'adresse. Un descripteur comportant un caractère générique est dit ranged, et demander les adresses 0 à 999 à partir de celui-ci est un seul appel RPC plutôt que mille imports.

La réception et le rendu de monnaie sont deux descripteurs, pas un seul, et c'est pourquoi les portefeuilles les importent par paires se terminant par /0/* et /1/. Le BIP-389 a simplifié cela avec la notation multipath, en écrivant la paire sous la forme /<0;1>/ dans une seule chaîne.

La somme de contrôle est petite et essentielle. Le BIP-380 définit un code de huit caractères sur le texte du descripteur, conçu pour détecter le type de dommage qui arrive réellement à une longue chaîne : un caractère interverti, un copier-coller tronqué, un saut de ligne inséré par un client de messagerie. Bitcoin Core refuse tout descripteur dont la somme de contrôle ne correspond pas, et getdescriptorinfo calcule la bonne pour une chaîne que vous avez saisie vous-même.

Où le voir

Les descripteurs sont le format de sauvegarde pour tout ce qui est plus compliqué qu'une seule phrase de récupération. Sparrow, Nunchuk et Specter en exportent un pour chaque portefeuille qu'ils créent, et un Coldcard écrit le descripteur sur microSD lors de la configuration multisig afin que l'arrangement puisse être reconstruit sans le logiciel coordinateur d'origine.

Bitcoin Core est l'endroit où ils sont devenus la norme. La version 0.17.0, publiée en octobre 2018, les a introduits pour l'analyse et la génération d'adresses ; importdescriptors et listdescriptors en ont fait la langue maternelle du portefeuille ; et le portefeuille à descripteur est désormais le seul type que le logiciel crée. Restaurer un portefeuille Core à partir d'un descripteur plus une nouvelle analyse est un chemin pris en charge, et qui survit à une réinstallation complète du logiciel.

Pour un simple portefeuille à signature unique, vous pouvez généralement vous en passer sans jamais en voir un, car votre phrase de récupération et le chemin standard suffisent. Pour le multisig, le descripteur est la moitié manquante de la sauvegarde : trois phrases de récupération sans trace du type de script, de l'ordre des clés ou de l'origine de chaque cosignataire peuvent vous laisser incapable de reconstruire les adresses où se trouvent vos bitcoins.

Descripteur de sortie vs clé étendue

Une clé étendue est un ingrédient et un descripteur est la recette. Le xpub indique au logiciel quelles clés existent ; le descripteur lui indique quoi construire à partir d'elles et où commencer à compter. C'est pourquoi importer un xpub dans deux applications différentes peut produire deux listes d'adresses différentes, tandis qu'importer le même descripteur ne le peut pas. Les deux divulguent les mêmes informations confidentielles : quiconque détient l'un ou l'autre peut énumérer votre branche, donc un descripteur mérite le même soin que la clé qu'il contient.