Annexe Taproot

Le BIP-341 a réservé ce champ pour de futurs soft forks et ne lui a donné aucune signification, si bien qu'aucun nœud ne lit son contenu aujourd'hui. La fonction IsWitnessStandard de Bitcoin Core rejette une dépense Taproot qui porte une annexe étiquetée 0x50, de sorte que la transaction ne se propagera pas, et le BIP-341 avertit qu'elle peut entraîner une perte définitive de fonds. Les portefeuilles n'ont aucune raison d'en attacher une, donc rien de ce que vous faites en achetant ou en conservant du bitcoin n'en dépend.

Comment cela fonctionne

Une annexe Taproot est identifiée par sa position, et non par un champ nommé dans le format de transaction. Si une entrée Taproot porte au moins deux éléments de témoin et que le premier octet du dernier élément est 0x50, cet élément est l'annexe et il est retiré de la pile de témoin avant que quoi que ce soit d'autre soit examiné. C'est seulement ensuite qu'un nœud décide ce qu'il a sous les yeux : un élément restant signifie une dépense par chemin de clé, deux ou plus signifient une dépense par chemin de script.

Le BIP-341 a choisi 0x50 délibérément. Les versions de feuille vont par couples (une version paire, une version impaire) qui ne doivent pas être confondus avec le premier octet d'un témoin P2WPKH ou P2WSH, et 0x50 était un reste non apparié, ce qui coûtait le moins de versions de script futures. La règle joue aussi en sens inverse : une version de feuille ne peut pas être 0x50, car un bloc de contrôle commençant par cet octet serait indistinguable d'une annexe.

Ce que l'annexe ne fait pas, c'est influencer la validation. Le BIP-341 dit que le champ « is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation. » Chaque message de signature Taproot porte un spend_type d'un octet égal à (ext_flag * 2) + annex_present, et lorsqu'une annexe est présente, le message porte aussi sha_annex, le SHA256 de 32 octets du préfixe de longueur de l'annexe et de l'annexe elle-même, octet 0x50 inclus. L'absence est signée aussi fermement que la présence, de sorte que personne ne peut greffer une annexe sur votre transaction dans la mempool ni en retirer une. Le BIP-341 fixe le message de signature à 174 octets, moins 49 pour ANYONECANPAY, moins 32 pour NONE, plus 32 lorsqu'une annexe est présente, avec un plafond de 206.

Où cela se voit

Vous ne voyez pas d'annexe Taproot dans un usage ordinaire, et c'est le fonctionnement normal du dispositif. La politique de relais de Bitcoin Core, dans src/policy/policy.cpp, vérifie chaque entrée de version de témoin 1 avec un programme de 32 octets et renvoie faux lorsque le témoin contient au moins deux éléments et que le dernier commence par la constante ANNEX_TAG, définie comme 0x50 dans src/script/script.h. Le commentaire à côté de cette vérification résume toute la politique : « Annexes are nonstandard as long as no semantics are defined for them. » Une transaction qui en porte une est valide par consensus et intransmissible en pratique : un nœud par défaut la rejette au lieu de la transmettre.

Une annexe apparaît réellement à un seul endroit, chaque signature Taproot que vous avez jamais produite, dont le spend_type porte un bit à zéro indiquant qu'il n'y a pas d'annexe ici. C'est cet engagement qui rendrait utilisable un soft fork à terme : le BIP-341 désigne comme tâche prévue de signaler le coût de validation de nouveaux opcodes coûteux sans qu'un nœud ait à récupérer la sortie dépensée.

Annexe Taproot vs OP_RETURN

OP_RETURN est l'emplacement désigné du bitcoin pour publier des octets que personne ne dépensera, et l'annexe Taproot n'est pas du tout un emplacement de publication. Les deux sont décrits comme un espace pour des données que le consensus ignore, et ils se comportent de façon opposée. Les données OP_RETURN vivent dans une sortie, font partie de la transaction que chaque nœud valide, et annoncent une signification convenue : rien ici n'est dépensable. Les octets d'une annexe vivent dans le témoin, sont retirés avant que la pile soit lue, et portent un avertissement de la spécification elle-même, selon lequel « users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS. »

Cet avertissement n'est pas décoratif. Un soft fork ne peut qu'ajouter des règles, donc des octets ignorés aujourd'hui peuvent être rejetés demain, et votre signature s'engage sur l'annexe, de sorte que vous ne pouvez pas la retirer d'une transaction déjà signée. Quiconque pré-signe des dépenses des années à l'avance, comme le fait un coffre ou un canal Lightning, figerait un champ dont personne n'a encore écrit la signification.