Dépense par chemin de clé

Une sortie Taproot peut être vidée en signant pour sa clé ou en révélant un script engagé, et la voie de la clé est la discrète. Le BIP-341 fixe ce témoin à exactement un élément, une signature Schnorr de 64 octets sous le sighash par défaut, ce qui porte l'entrée entière à 230 unités de poids, soit 57,5 vbytes. Pour un détenteur, un coffre partagé et un paiement en solo se ressemblent alors on-chain.

Comment cela fonctionne

Une dépense par chemin de clé signe pour la clé de sortie, qui n'est la clé choisie par personne : le BIP-341 la construit comme Q = P + int(t)G, où P est la clé publique interne et t un hachage étiqueté de P avec la racine de merkle de l'arbre de scripts.

Signer signifie donc appliquer ce même décalage du côté privé. La routine de référence annule d'abord la clé secrète lorsque le point interne a une coordonnée y impaire, parce que les ajustements taproot s'appliquent à des clés x-only de 32 octets, puis ajoute t modulo l'ordre de la courbe. Le résultat se signe sous le BIP-340 et rejoint seul la pile de témoins.

La validation est un test de comptage avant d'être un test cryptographique. Un nœud lit les 32 octets du programme de témoin, échoue aussitôt si la pile de témoins est vide, et retire le dernier élément comme annexe lorsqu'il y a deux éléments ou plus et que cet élément commence par 0x50. S'il reste exactement un élément, la dépense est une dépense par chemin de clé, et cet élément doit se vérifier comme une signature BIP-340 contre la clé de sortie. Rien dans cette procédure ne dit au nœud si un arbre de scripts a jamais été engagé.

La signature fait 64 octets lorsque SIGHASH_DEFAULT, valeur 0x00, est implicite, ce qui couvre toute la transaction. Elle atteint 65 octets lorsqu'un autre octet de sighash est ajouté, et une signature de 65 octets portant 0x00 à cette dernière position est rejetée délibérément : la permettre laisserait un mineur ou tout nœud relayeur compléter une signature de 64 octets jusqu'à 65, changeant le wtxid et le taux de frais voulus par l'expéditeur.

Ce que la signature couvre représente au plus 206 octets de message. Elle engage la version de transaction et le locktime, des hachages de chaque outpoint d'entrée, du montant, du scriptPubKey précédent et du numéro de séquence, ainsi que les sorties.

L'arithmétique des tailles en découle. Sous le BIP-141, le poids d'une transaction est la taille de base multipliée par trois plus la taille totale, et la taille virtuelle est ce poids divisé par quatre, arrondi au supérieur pour une transaction entière. Une entrée Taproot apporte 41 octets de base (un outpoint de 36 octets, un octet de longueur pour un scriptSig vide, une séquence de quatre octets) et 66 octets de témoin (un compteur de pile, un préfixe de longueur, la signature), soit 41 fois 3 plus 107, ou 230 unités de poids, et donc 57,5 vbytes.

Une recommandation du BIP-341 prend les auteurs de portefeuilles en défaut. Une sortie sans aucun script devrait tout de même engager un ajustement, calculé comme un hachage étiqueté de la clé interne seule, plutôt que de publier la clé interne inchangée. La spécification explique pourquoi : lorsque deux parties additionnent leurs clés en une clé de sortie partagée, l'une d'elles peut y intégrer discrètement un ajustement cachant un chemin de script dépensable par elle seule, et l'autre n'a aucun moyen de le remarquer.

Pourquoi cela compte quand vous achetez du bitcoin

Le message de signature de Taproot est la raison pour laquelle un portefeuille matériel peut calculer vos frais sans faire confiance à l'ordinateur auquel il est branché.

Sous le BIP-143, les règles de la version SegWit 0, le message n'engageait que le montant dépensé par l'entrée signée, rien de plus. Un appareil signant une entrée d'une transaction à trois entrées devait recevoir les deux autres montants et ne pouvait pas les vérifier, ce qui est la brèche qu'utilise un hôte compromis pour vous faire signer des frais bien plus élevés que ce que l'écran affichait. Le BIP-341 engage les montants de chaque entrée que la transaction dépense, ainsi que tous leurs scriptPubKeys précédents, de sorte qu'un signataire peut les totaliser lui-même. Cette amélioration couvre aussi les dépenses par chemin de script, mais le chemin de clé est l'endroit où la plupart des propriétaires des appareils de nos 41 avis sur les portefeuilles la rencontreront.

Votre portefeuille doit pouvoir dériver les clés avant que tout cela s'applique, et à travers ces avis le tableau est inégal. KeepKey a ajouté la prise en charge des sorties Taproot dans le micrologiciel 7.10.0 en février 2025. L'annonce de MetaMask elle-même liste encore Taproot comme à venir, de sorte qu'il ne peut pas vous donner une adresse bc1p à laquelle recevoir, quoi que fasse le reste de sa prise en charge du bitcoin.

Les frais penchent vers le chemin de clé d'une petite marge par entrée, qui s'accumule dans le sens où la plupart des lecteurs achètent. L'entrée P2WPKH signée du vecteur de test du BIP-143 lui-même porte une signature de 71 octets et une clé de 33 octets, soit 107 octets de témoin une fois le compteur de pile et les préfixes de longueur comptés, ce qui donne 271 unités de poids, ou 67,75 vbytes. Une entrée par chemin de clé économise 10,25 vbytes par rapport à cela, de sorte qu'un épargnant qui a cumulé 30 petits achats distincts et les consolide ensuite retire environ 307 vbytes à cette seule transaction.

Soyez clair sur ce que la confidentialité achète réellement. Cacher votre politique de dépense n'est pas cacher votre historique : si les bitcoins viennent de l'une des 63 plateformes d'échange examinées sur ce site, cette plateforme détient déjà vos documents d'identité et l'adresse de retrait, et aucun format de signature n'y touche. Ce qui reste caché, c'est si le bitcoin était protégé par une seule clé ou par un quorum avec une branche de récupération d'avocat, et ce second fait est celui qui rend une adresse digne d'être ciblée.

Parcours de taproot_sign_key

taproot_sign_key est la routine de référence que le BIP-341 publie pour produire exactement ce témoin, et elle tient entièrement en neuf lignes de Python.

Elle prend un arbre de scripts, la clé secrète interne, un type de sighash et l'aléa auxiliaire que demande le BIP-340. Quand l'arbre de scripts est vide, elle définit l'entrée d'ajustement comme une chaîne d'octets vide ; sinon cette entrée est la racine de merkle renvoyée par l'auxiliaire d'arbre. Elle ajuste la clé secrète interne avec cette valeur, signe le sighash, ajoute l'octet de type de hachage seulement lorsque le type n'est pas zéro, et renvoie une liste contenant un seul élément. Cet élément est tout le témoin.

Deux détails méritent l'attention. La branche vide n'est pas le cas sans ajustement qu'elle paraît être, parce que fournir une chaîne d'octets vide laisse l'ajustement comme le hachage étiqueté de la clé interne seule, ce qui est exactement l'engagement non dépensable que la spécification recommande pour une sortie sans scripts. Et l'argument d'aléa relève du BIP-340 plutôt que de Taproot : une fois la clé ajustée, le résultat est une signature Schnorr ordinaire, ce qui explique pourquoi les dépenses par chemin de clé n'ont besoin d'aucun traitement particulier pour être vérifiées par lots.

Dépense par chemin de clé vs P2TR

P2TR est le type de sortie, et une dépense par chemin de clé est l'une des deux façons d'en vider une. Un bitcoin reste un bitcoin P2TR quelle que soit la voie qui le draine ensuite. La distinction compte lorsque quelqu'un vous dit que les adresses Taproot sont privées : recevoir sur l'une publie une clé de 32 octets et rien d'autre dans les deux cas, tandis que la confidentialité dont les gens parlent arrive au moment de la dépense, et seulement si la voie de la clé est celle empruntée.

Dépense par chemin de clé vs MuSig2

MuSig2 est une façon de produire la signature qu'exige une dépense par chemin de clé, et non une condition de celle-ci. Un propriétaire unique signant avec une clé unique fait une dépense par chemin de clé chaque fois qu'il paie, sans aucun protocole d'agrégation en vue. Les deux sont confondus parce que l'agrégation est le cas intéressant : MuSig2 permet à plusieurs parties d'aboutir à une clé et une signature, de sorte que leur règlement emprunte la même voie et les mêmes 57,5 vbytes que quelqu'un qui paie son déjeuner. Cela va aussi dans l'autre sens, puisqu'une clé agrégée peut se trouver dans une feuille de script, où la dépenser est une dépense par chemin de script qui se trouve utiliser MuSig2.