Dies ist Teil 3 der technischen Artikelreihe über Bitcoin-Verträge von Cointelegraph Research. Um den vorherigen Artikel zu lesen, klicken Sie Hier.
SIGHASH_ANYPREVOUT, as Vorschlägeed in BIP 118, baut auf dem früheren SIGHASH_NOINPUT-Konzept auf, das in erwähnt wurde 2015 Lightning Network-Artikel von Joseph Poon und Thaddeus Dryjaund später offiziell von Joseph Poon vorgeschlagen Bitcoin-Dev-Mailing Liste im Februar 2016.
SIGHASH_ANYPREVOUT ist kein neuer Opcode, sondern ein vorgeschlagener neuer Wert für das SIGHASH-Flag, der als Soft-Fork-Upgrade für Bitcoin eingesetzt werden soll. Das SIGHASH-Flag wird an eine Signatur angehängt und bestimmt, welche Teile einer Transaktion signiert sind und vom CHECKSIG-Opcode überprüft werden. Das ausgewählte Flag wird vom Unterzeichner ausgewählt und nicht vom Unterzeichner erzwungen scriptPubKey. Aufgrund der technischen Details im Zusammenhang mit der Aktualisierbarkeit in einem Softfork erstreckt sich der SIGHASH_ANYPREVOUT-Vorschlag nur auf Ausgaben von Taproot-Adressen.
Es gibt bereits eine Vielzahl von Standard-SIGHASH-Modi, wie in Abbildung 1 dargestellt. Wenn das Flag auf SIGHASH_ALL gesetzt ist, muss die Signatur alle Eingaben, alle Ausgaben und den spezifischen ausgegebenen Outpoint abdecken und so die Autorisierung kryptografisch an genau dieses UTXO binden. Ein Outpoint ist die Kombination aus einer Transaktions-ID und einem Ausgabeindex, die zusammen eindeutig identifizieren, welches UTXO eine Transaktion verbraucht. Bei SIGHASH_NONE müssen nur die Eingaben signiert werden, sodass die Ausgaben nicht eingeschränkt werden. Die Variante SIGHASH_SINGLE signiert alle Eingaben, aber nur die Ausgabe mit demselben Index wie die zu signierende Eingabe. Der ANYONECANPAY-Modifikator bietet weitere Flexibilität, indem er ermöglicht, dass eine einzelne Eingabe unabhängig von den anderen signiert wird. Entscheidend ist, dass keiner dieser vorhandenen Modi zulässt, dass eine Signatur die Bindung an den Outpoint unterlässt. Diese Einschränkung wird durch SIGHASH_ANYPREVOUT aufgehoben.
BIP-118 definiert zwei ANYPREVOUT-Varianten, die sich darin unterscheiden, wie viel von der vorherigen Ausgabe sie aus dem Digest weglassen, zusammengefasst in Abbildung 2. Unter SIGHASH_ANYPREVOUT wird der Outpoint aus dem Digest ausgeschlossen, aber die Signatur bindet sich weiterhin an die Menge und den scriptPubKey der vorherigen Ausgabe sowie an die Eingaben nSequenz. Unter SIGHASH_ANYPREVOUTANYSCRIPT werden der Betrag und der scriptPubKey ebenfalls ausgeschlossen, was bedeutet, dass die Signatur überhaupt nicht an das Sperrskript der ausgegebenen Ausgabe gebunden ist. Alle anderen Verpflichtungen folgen dem standardmäßigen Aufbau der Taproot-Signaturnachricht und hängen vom ausgewählten Basisflag ab, z. B. SIGHASH_ALL oder SIGHASH_SINGLE.
Da der Outpoint im Digest weggelassen wird, kann dieselbe Signatur die Ausgabe jedes kompatiblen UTXO autorisieren, das die verbleibenden festgeschriebenen Felder erfüllt. Zum Beispiel eine mit ANYPREVOUT | vorsignierte Transaktion ALL zur Erzeugung einer 0,5-BTC-Ausgabe kann wiederverwendet werden, wenn dieselbe Adresse später ein weiteres UTXO von 0,5 BTC erhält, selbst wenn der private Schlüssel, der zum Erstellen der Originalsignatur verwendet wurde, nicht mehr verfügbar ist. Wenn das neue UTXO jedoch mehr als 0,5 BTC enthält, geht der Überschuss für die Miner verloren, es sei denn, die ursprüngliche Signatur enthielt eine Änderungsausgabe. Diese Neubindungseigenschaft macht ANYPREVOUT aus nützlich für Layer-2-Protokollewobei dieselbe vorsignierte Transaktion für mehrere mögliche UTXOs in der Kette gelten muss, ohne dass für jedes einzelne neue Signaturen erforderlich sind.
Bei vertragsähnlichen Anwendungen behalten die ANYPREVOUT-Varianten die Bindung an den scriptPubKey der vorherigen Ausgabe bei und sind in der Regel am relevantesten. Sie ermöglichen die Wiederverwendung von Signaturen über kompatible UTXOs hinweg und stellen gleichzeitig sicher, dass Gelder an dasselbe Sperrskript gebunden bleiben. ANYPREVOUTANYSCRIPT entfernt diese Bindung vollständig und eignet sich daher weniger für Anwendungen im Covenant-Stil.
Ähnlich wie OP_CTV verbessert SIGHASH_ANYPREVOUT die Logik, die bereits mit vorsignierten Transaktionen erreichbar ist, ermöglicht aber selbst keine rekursiven Vereinbarungen oder Transaktionsselbstprüfung. Stattdessen wird die Bindung zwischen einer Signatur und einem bestimmten UTXO gelockert, sodass eine Signatur über mehrere kompatible UTXOs hinweg wiederverwendet werden kann.
Einige Untersuchungen haben auch ergeben, dass das Entfernen der Outpoint-Verpflichtung Konstruktionen wiederhergestellter Schlüssel möglich macht – das heißt, ein öffentlicher Schlüssel kann aus einem festen Signatur- und Nachrichtenpaar abgeleitet werden, sodass der entsprechende private Schlüssel nachweislich niemandem bekannt ist, wodurch der Schlüsselpfad des UTXO nachweislich unbrauchbar wird und alle Ausgaben über den Skriptpfad erzwungen werden. Dadurch würde der Bedarf an temporären Schlüsseln vermieden, die andernfalls erforderlich wären, um den Schlüsselpfad in Konstruktionen, die nur auf der Durchsetzung des Skriptpfads basieren, unbrauchbar zu machen. Diese Beobachtung erscheint in Bitcoin-Vereinbarungen: Drei Möglichkeiten, die Zukunft zu kontrollieren von Jacob Swambo et al. (2020)obwohl es sich eher um eine theoretische Konstruktion als um einen in BIP-118 vorgeschlagenen Entwurf handelt.
Das mit SIGHASH_ANYPREVOUT-Signaturen verbundene Hauptrisiko besteht darin Signaturwiedergabe. Da diese Signaturen nicht an einen bestimmten Outpoint gebunden sind, kann dieselbe Signatur verwendet werden, um ein anderes UTXO als das ursprünglich vorgesehene auszugeben, vorausgesetzt, das neue UTXO erfüllt die verbleibenden festgeschriebenen Felder. Dieses Risiko wird in bestimmten Konfigurationen stärker ausgeprägt: wenn ANYPREVOUT | SINGLE wird verwendet und Ausgabemengen können neu angeordnet werden; wenn ein separates UTXO mit demselben scriptPubKey und derselben Menge vorhanden ist, im Fall von ANYPREVOUT; wenn derselbe öffentliche Schlüssel in einem kompatiblen Skript erscheint, im Fall von ANYPREVOUTANYSCRIPT; oder wenn ein Miner die Reihenfolge und Einbeziehung von Transaktionen beeinflussen kann, um diese Bedingungen auszunutzen. Diese Szenarien erfordern jedoch entweder einen vorsätzlichen Missbrauch oder ein Versäumnis des Benutzers oder Entwicklers, die Wiedergabebedingungen beim Protokollentwurf zu berücksichtigen.
In unserem nächsten Artikel beginnen wir mit der Diskussion von Opcodes, die als unterstützende Werkzeuge dienen. Diese erweitern die Ausdruckskraft des Bitcoin-Skripts oder der Datenverarbeitung, implementieren jedoch keine Covenant-Funktionalität, sofern sie nicht mit anderen Opcodes kombiniert werden. In dieser nächsten Kategorie werden wir diskutieren OP_CHECKSIGFROMSTACK Und OP_CAT.
