Taproot-Annex

BIP-341 reservierte das Feld für künftige Soft Forks und gab ihm keine Bedeutung, sodass heute kein Node seinen Inhalt liest. IsWitnessStandard in Bitcoin Core lehnt einen Taproot-Spend ab, der einen mit 0x50 gekennzeichneten Annex trägt, sodass die Transaktion nicht weitergegeben wird, und BIP-341 warnt, dass dies zu einem dauerhaften Verlust von Guthaben führen kann. Wallets haben keinen Grund, einen anzuhängen, sodass nichts, was Sie beim Kaufen oder Halten von Bitcoin tun, davon abhängt.

Wie es funktioniert

Ein Taproot-Annex wird über seine Position identifiziert und nicht über ein benanntes Feld im Transaktionsformat. Trägt ein Taproot-Input mindestens zwei Witness-Elemente und ist das erste Byte des letzten Elements 0x50, so ist dieses Element der Annex und wird vom Witness-Stack entfernt, bevor irgendetwas anderes geprüft wird. Erst dann entscheidet ein Node, was vor ihm liegt: ein verbleibendes Element bedeutet eine Ausgabe über den Key-Pfad, zwei oder mehr eine Ausgabe über den Script-Pfad.

BIP-341 wählte 0x50 bewusst. Leaf-Versionen treten in geraden und ungeraden Paaren auf, die nicht mit dem ersten Byte eines P2WPKH- oder P2WSH-Witness verwechselt werden dürfen, und 0x50 war ein unpaariger Rest, sodass es die wenigsten künftigen Script-Versionen kostete. Die Regel gilt auch umgekehrt: Eine Leaf-Version darf nicht 0x50 sein, weil ein Control Block, der mit diesem Byte beginnt, nicht von einem Annex zu unterscheiden wäre.

Was der Annex nicht tut, ist die Validierung zu beeinflussen. BIP-341 sagt, das Feld "is always covered by the signature and contributes to transaction weight, but is otherwise ignored during taproot validation." Jede Taproot-Signaturnachricht trägt ein ein Byte großes spend_type gleich (ext_flag * 2) + annex_present, und wenn eines vorhanden ist, trägt die Nachricht außerdem sha_annex, den 32 Byte großen SHA256 des Längenpräfixes des Annex und des Annex selbst, das Byte 0x50 eingeschlossen. Die Abwesenheit wird genauso fest signiert wie die Anwesenheit, sodass niemand im Mempool einen Annex an Ihre Transaktion anfügen oder einen entfernen kann. BIP-341 setzt die Signaturnachricht auf 174 Byte, minus 49 für ANYONECANPAY, minus 32 für NONE, plus 32, wenn ein Annex vorhanden ist, begrenzt auf 206.

Wo Sie ihn sehen

Im gewöhnlichen Gebrauch sehen Sie keinen Taproot-Annex, und das ist das Funktionieren des Designs. Die Relay-Richtlinie von Bitcoin Core prüft in src/policy/policy.cpp jeden Witness-Version-1-Input mit einem 32 Byte großen Programm und gibt false zurück, wenn der Witness zwei oder mehr Elemente enthält und das letzte mit der Konstante ANNEX_TAG beginnt, die in src/script/script.h als 0x50 definiert ist. Der Kommentar neben dieser Prüfung ist die ganze Richtlinie: "Annexes are nonstandard as long as no semantics are defined for them." Eine Transaktion, die einen trägt, ist nach Konsens gültig und in der Praxis nicht zustellbar: Ein Node mit Standardeinstellungen verwirft sie, statt sie weiterzugeben.

Ein Annex taucht tatsächlich an einer Stelle auf, in jeder Taproot-Signatur, die Sie je erstellt haben, deren spend_type ein Nullbit trägt, das besagt, dass hier kein Annex vorhanden ist. Diese Bindung ist es, was einen künftigen Soft Fork nutzbar machen würde: BIP-341 nennt als beabsichtigte Aufgabe, die Validierungskosten teurer neuer Opcodes zu kennzeichnen, ohne dass ein Node die ausgegebene Ausgabe abrufen muss.

Taproot-Annex vs. OP_RETURN

OP_RETURN ist der von Bitcoin vorgesehene Platz zum Veröffentlichen von Bytes, die niemand ausgeben wird, und der Taproot-Annex ist überhaupt kein Veröffentlichungsplatz. Beide werden als Raum für Daten beschrieben, die der Konsens ignoriert, und sie verhalten sich gegensätzlich. OP_RETURN-Daten liegen in einer Ausgabe, sind Teil der Transaktion, die jeder Node validiert, und kündigen eine vereinbarte Bedeutung an: Hier ist nichts ausgebbar. Annex-Bytes liegen im Witness, werden entfernt, bevor der Stack gelesen wird, und tragen eine Warnung der Spezifikation selbst, dass "users SHOULD NOT include annex in transactions, or it may lead to PERMANENT FUND LOSS."

Diese Warnung ist keine Zierde. Ein Soft Fork kann nur Regeln hinzufügen, sodass heute ignorierte Bytes morgen abgelehnt werden können, und Ihre Signatur bindet den Annex, sodass Sie ihn aus einer bereits signierten Transaktion nicht entfernen können. Wer Ausgaben Jahre im Voraus vorsigniert, wie es ein Vault oder ein Lightning-Kanal tut, würde sich an ein Feld binden, dessen Bedeutung noch niemand geschrieben hat.