Glossaire / Référence pour développeurs
MSG_WITNESS_TX
- Qu'est-ce que MSG_WITNESS_TX ?
- Une demande de transaction témoin, envoyée sous forme de getdata, indique à un pair de renvoyer la transaction nommée avec ses données de signature encore attachées plutôt que supprimées.
Spécifié dans BIP-144.
Demandez une transaction par son txid avec MSG_WITNESS_TX et vous recevez la version avec les signatures attachées. Bitcoin Core 0.21.0, publié le 14 janvier 2021, a ajouté la retransmission par wtxid et a largement remplacé cette demande par MSG_WTX, qui demande par hachage de témoin à la place. Pour quiconque envoie des bitcoins, l'avantage est qu'une signature modifiée ne fait plus disparaître un paiement de la retransmission.
Comment cela fonctionne
Chaque transaction segwit a deux identités, et MSG_WITNESS_TX existe parce qu'un pair doit être informé de celle qu'on lui demande de satisfaire.
Le txid est le double SHA-256 de la transaction sans son témoin : version, entrées, sorties, locktime. Le wtxid est le même hachage calculé sur la sérialisation complète, octet marqueur et octet indicateur et piles de témoins inclus. Pour une transaction sans aucun témoin, les deux sont égaux. Pour la transaction coinbase, le BIP141 définit le wtxid comme 32 octets de zéro, un cas particulier qui existe pour que la racine de merkle des témoins ait quelque chose de bien défini auquel s'accrocher.
Le code de demande est 0x40000001 : type de transaction 1 avec l'indicateur de témoin 0x40000000 ajouté par-dessus. Envoyez un getdata de type 1 seul et le pair répond avec les octets dépouillés, qui suffisent à voir où l'argent est allé et sont inutiles pour vérifier si la dépense était autorisée.
Cette séparation est ce qui a mis fin à l'ancien problème de malléabilité. Avant segwit, un tiers pouvait réencoder une signature, changer le txid, et laisser l'expéditeur guetter une transaction qui n'existait plus sous ce nom. Déplacer les signatures hors du txid a fermé cette porte, et sa fermeture est ce qui a permis de se fier aux transactions pré-signées des canaux Lightning.
Le BIP339 a ensuite poussé la logique un cran plus loin. Les pairs qui envoient un message wtxidrelay avant verack annoncent les transactions par wtxid en utilisant le type d'inventaire 5, et Bitcoin Core le fait depuis 0.21.0. Le gain est dans le cache de rejet : un nœud qui a refusé un témoin mal formé ne refuse plus une copie honnête de la même transaction, parce que les deux ont des wtxid différents. MSG_WITNESS_TX subsiste pour les pairs qui n'ont jamais négocié la retransmission par wtxid, ce qui en pratique désigne les logiciels antérieurs à cette version.
Où vous le voyez
L'endroit le plus clair pour rencontrer txid et wtxid côte à côte est la sortie des RPC de transaction de Bitcoin Core lui-même.
Appelez getrawtransaction avec une sortie verbeuse sur n'importe quelle dépense segwit et vous obtenez un champ txid et un champ hash. Ils diffèrent. Le hash est le wtxid, et la différence est la seule trace visible des données de témoin dans un objet JSON par ailleurs ordinaire. Les explorateurs de blocs indexent par txid, c'est donc ce numéro qu'il faut coller dans un champ de recherche pour vérifier si votre retrait est arrivé.
Sur le réseau, getpeerinfo compte les messages par type, et les demandes de transaction dans cette répartition seront un mélange sur tout nœud bien connecté : MSG_WTX vers les pairs modernes, MSG_WITNESS_TX vers les retardataires.
Rien de tout cela n'est configuré par un acheteur. Cela compte indirectement. Quand une plateforme d'échange vous dit qu'un retrait a été diffusé et que votre portefeuille ne le trouve pas, la question utile est de savoir si le txid qui vous a été donné a atteint la mempool, pas quelle sérialisation les pairs ont échangée.
MSG_WITNESS_TX vs MSG_TX
MSG_TX nomme la même transaction et la renvoie avec toutes les signatures supprimées. Cette forme est ce que les nœuds antérieurs à segwit comprenaient, et elle circule encore vers les pairs qui n'ont jamais annoncé NODE_WITNESS. La distinction n'est pas cosmétique : un nœud auquel on remet la version dépouillée peut confirmer la structure de la transaction mais ne peut pas la valider, il ne peut donc pas la placer en toute sécurité dans une mempool ni la retransmettre comme vérifiée. Bitcoin Core n'enverra pas une transaction segwit à un pair qui ne parle que l'ancienne forme.