Glossar / Entwicklerreferenz
MSG_WITNESS_TX
- Was ist MSG_WITNESS_TX?
- Eine Witness-Transaktionsanforderung, gesendet als getdata, weist einen Peer an, die benannte Transaktion mit ihren weiterhin angehängten Signaturdaten zurückzugeben statt ohne sie.
Spezifiziert im BIP-144.
Fordern Sie eine Transaktion über ihre txid mit MSG_WITNESS_TX an, erhalten Sie die Version mit angehängten Signaturen zurück. Bitcoin Core 0.21.0, veröffentlicht am 14. Januar 2021, fügte die wtxid-Weiterleitung hinzu und ersetzte diese Anforderung weitgehend durch MSG_WTX, die stattdessen über den Witness-Hash anfragt. Für alle, die Bitcoin senden, liegt der Gewinn darin, dass eine veränderte Signatur eine Zahlung nicht mehr aus der Weiterleitung verschwinden lässt.
So funktioniert es
Jede Segwit-Transaktion hat zwei Identitäten, und MSG_WITNESS_TX existiert, weil einem Peer mitgeteilt werden muss, welche davon er erfüllen soll.
Die txid ist der doppelte SHA-256 der Transaktion ohne ihren Witness: Version, Eingaben, Ausgaben, Locktime. Die wtxid ist derselbe Hash über die vollständige Serialisierung, einschließlich Marker-Byte, Flag-Byte und Witness-Stapel. Bei einer Transaktion ganz ohne Witness sind beide gleich. Für die Coinbase-Transaktion definiert BIP141 die wtxid als 32 Bytes aus Nullen, ein Sonderfall, der existiert, damit die Witness-Merkle-Wurzel etwas klar Definiertes hat, woran sie hängt.
Der Anforderungscode ist 0x40000001: der Transaktionstyp 1 mit zusätzlich aufgesetztem Witness-Flag 0x40000000. Senden Sie ein getdata mit dem bloßen Typ 1, antwortet der Peer mit den bereinigten Bytes, die ausreichen, um zu sehen, wohin das Geld ging, und nutzlos sind, um zu prüfen, ob die Transaktion autorisiert war.
Diese Trennung war es, die das alte Malleabilitätsproblem beseitigte. Vor Segwit konnte ein Dritter eine Signatur neu kodieren, die txid ändern und den Sender auf eine Transaktion warten lassen, die unter diesem Namen nicht mehr existierte. Die Signaturen aus der txid herauszunehmen schloss diese Tür, und ihr Schließen machte vorab signierte Lightning-Kanaltransaktionen verlässlich.
BIP339 ging dann einen Schritt weiter. Peers, die vor verack eine wtxidrelay-Nachricht senden, kündigen Transaktionen per wtxid mit dem Inventartyp 5 an, und Bitcoin Core tut dies seit 0.21.0. Der Gewinn liegt im Ablehnungs-Cache: ein Node, der einen fehlerhaften Witness abgelehnt hat, lehnt nicht mehr eine ehrliche Kopie derselben Transaktion ab, weil beide unterschiedliche wtxids haben. MSG_WITNESS_TX bleibt für Peers erhalten, die nie die wtxid-Weiterleitung ausgehandelt haben, was in der Praxis Software bedeutet, die älter ist als diese Version.
Wo Sie es sehen
Am deutlichsten begegnen Ihnen txid und wtxid nebeneinander in der Ausgabe der eigenen Transaktions-RPCs von Bitcoin Core.
Rufen Sie getrawtransaction mit ausführlicher Ausgabe für eine beliebige Segwit-Transaktion auf, erhalten Sie ein Feld txid und ein Feld hash. Sie unterscheiden sich. Der hash ist die wtxid, und der Unterschied ist die einzige sichtbare Spur der Witness-Daten in einem ansonsten gewöhnlichen JSON-Objekt. Block-Explorer indexieren nach txid, also ist das die Zahl, die Sie in ein Suchfeld einfügen, wenn Sie prüfen, ob Ihre Auszahlung angekommen ist.
Auf der Leitung zählt getpeerinfo Nachrichten nach Typ, und die Transaktionsanforderungen in dieser Aufschlüsselung sind auf jedem gut vernetzten Node eine Mischung: MSG_WTX an moderne Peers, MSG_WITNESS_TX an die Nachzügler.
Nichts davon konfiguriert ein Käufer. Es ist indirekt von Bedeutung. Wenn eine Börse Ihnen mitteilt, eine Auszahlung sei gesendet worden, und Ihre Wallet sie nicht findet, lautet die nützliche Frage, ob die Ihnen genannte txid jemals den Mempool erreicht hat, nicht welche Serialisierung die Peers ausgetauscht haben.
MSG_WITNESS_TX vs. MSG_TX
MSG_TX benennt dieselbe Transaktion und gibt sie mit jeder entfernten Signatur zurück. Diese Form verstanden Nodes vor Segwit, und sie zirkuliert noch an Peers, die nie NODE_WITNESS angekündigt haben. Der Unterschied ist nicht kosmetisch: ein Node, dem die bereinigte Version vorliegt, kann die Transaktionsstruktur bestätigen, sie aber nicht validieren, also kann er sie nicht sicher in einen Mempool aufnehmen oder als verifiziert weiterleiten. Bitcoin Core sendet keine Segwit-Transaktion an einen Peer, der nur die ältere Form spricht.