Données témoins

Chaque entrée a son propre témoin : une pile d'éléments, le plus souvent une signature et une clé publique. La section se place après les sorties, derrière un marqueur et un indicateur, deux octets, qui signalent au logiciel que la transaction est au format plus récent. Un nœud exécutant un logiciel antérieur à la mise à niveau de 2017 ne la demande jamais et ne la voit jamais.

Comment cela fonctionne

Les données témoins ont leur propre place dans la disposition en octets d'une transaction, définie par le BIP-144.

Une transaction sérialisée au format plus récent se lit ainsi : version, l'octet marqueur 0x00, l'octet indicateur 0x01, les entrées, les sorties, puis une pile témoin par entrée dans le même ordre, puis le locktime. Le marqueur est là où réside l'astuce de compatibilité, car une valeur de zéro signifierait zéro entrée pour l'ancien analyseur, ce qui n'a pas de sens, si bien qu'un ancien logiciel qui reçoit le nouveau format sait immédiatement qu'il ne lui est pas destiné et que les pairs hérités ne le reçoivent tout simplement jamais.

Deux identifiants en découlent. Le txid est un double SHA-256 de la transaction, le marqueur, l'indicateur et les témoins étant retirés, ce qui explique que rien à l'intérieur d'un témoin ne puisse le modifier. Le wtxid hache la sérialisation complète. Chaque bloc engage une racine de merkle de ses wtxid dans une sortie coinbase, un OP_RETURN dont le script fait au moins 38 octets et commence par l'étiquette de quatre octets 0xaa21a9ed, de sorte que les données sont protégées même si elles vivent hors de l'engagement plus ancien.

Le coût est là où la réduction se voit. Tout ce qui est hors du témoin est facturé quatre unités de poids par octet et tout ce qui est dedans est facturé une unité, dans la limite de 4 000 000 unités de poids par bloc. Divisez le poids par quatre et vous obtenez des octets virtuels, l'unité dans laquelle les taux de frais sont exprimés.

Où le voir

Ouvrez n'importe quelle transaction sur un explorateur de blocs et la taille, la taille virtuelle et le poids s'afficheront côte à côte. Quand ils diffèrent, l'écart correspond au témoin. Un paiement sans aucun témoin affiche une taille égale à son vsize ; un paiement Taproot peut afficher un vsize à peine égal au quart de sa taille brute.

Déplier une seule entrée sur un explorateur moderne montre la pile elle-même. Pour un paiement bc1q, ce sont deux éléments, une signature d'environ 71 ou 72 octets et une clé publique compressée de 33 octets, et pour une dépense Taproot par chemin de clé, c'est un seul élément d'exactement 64 octets. Ce décompte est la raison même pour laquelle les types de sortie plus récents coûtent moins cher à dépenser.

Ce champ apparaît aussi dans les fichiers que votre portefeuille matériel manipule. Une transaction bitcoin partiellement signée comporte un enregistrement UTXO témoin et un enregistrement témoin final par entrée, ce qu'une application coordinatrice échange dans les deux sens pendant qu'une transaction multisig recueille des signatures.

Données témoins vs script témoin

Les données témoins sont la pile entière ; un script témoin est l'un de ses éléments. Pour une dépense P2WSH, le dernier élément de la pile est le script sur le hash duquel la sortie s'est engagée, et tout ce qui le précède existe pour satisfaire ce script. La relation copie exactement le schéma plus ancien, où un script de rachat est le dernier élément d'un script de signature P2SH. Ainsi, tout script témoin est une donnée témoin, tandis que la plupart des données témoins, y compris toute dépense ordinaire à clé unique, ne contiennent aucun script témoin.