Opcode

Anna möchte Peter bezahlen. Ihre Wallet erstellt die Transaktion und die nötigen Signaturen. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Ein Knoten ist ein Programm, das Transaktionen und Blöcke prüft und sich mit anderen Netzwerkteilnehmern austauscht. Knoten prüfen dann, ob Anna die gewählten Coins ausgeben durfte. Bitcoin Script beschreibt einen Teil dieser Prüfungen. Ein Opcode ist ein einzelner Schritt, etwa eine Signaturprüfung. Anna schreibt für eine gewöhnliche Zahlung keine Anweisungen von Hand. Ein Knoten darf aber weder einem Besitzernamen noch dem Etikett „signiert“ vertrauen: Er muss die Bedingungen prüfen. Ein gültiges Skript ist dabei nur ein Teil der gesamten Transaktionsprüfung. [1] [4]

In einer lesbaren Darstellung stehen etwa OP_DUP oder OP_CHECKSIG. Das sind Anweisungsnamen für Menschen; im Skript werden sie durch ein Byte große Codes dargestellt. Ein Byte ist eine übliche Einheit für Datenmengen. Andere Teile enthalten Daten, zum Beispiel einen öffentlichen Schlüssel. Der öffentliche Schlüssel dient zur Prüfung von Signaturen und muss nicht geheim bleiben. Anweisungen der Familie OP_PUSHDATA bestimmen, wie viele folgende Bytes als Daten eingefügt werden. Diese Bytes werden nicht erneut als Anweisungen ausgeführt. Es ist der Unterschied zwischen „Salz hinzufügen“ im Rezept und der Zutat, die in die Schüssel kommt. [1] [2]

Stellen Sie sich einen Stapel Zettel vor, von dem Sie den obersten nehmen. So arbeitet der grundlegende Stack des Skripts. OP_DUP kopiert den obersten Eintrag, OP_DROP entfernt ihn. Werden auf einem nicht leeren Stack erst OP_DUP und dann OP_DROP ausgeführt, hat er wieder seinen ursprünglichen Inhalt. Kopiert wurden keine Coins, sondern Arbeitsdaten. Fehlt ein benötigter Eintrag, kann die Prüfung scheitern. Auch Reihenfolge und genaue Kodierung sind entscheidend. [1]

OP_EQUAL nimmt die obersten beiden Einträge, vergleicht ihre Bytes und ersetzt sie durch das Vergleichsergebnis. OP_EQUALVERIFY bricht bei Ungleichheit sofort mit einem Fehler ab; bei Gleichheit geht es ohne dieses Ergebnis auf dem Stack weiter. Keine dieser Operationen prüft allein eine Signatur. Zwei identische Kopien eines öffentlichen Schlüssels kann jeder vorlegen. Erst die passende Signaturprüfung kann belegen, dass jemand die erforderliche Nachricht signieren konnte. [1] [4]

OP_CHECKSIG prüft eine Signatur anhand eines öffentlichen Schlüssels und einer aus der Transaktion gebildeten Nachricht. Der private Schlüssel ist ein geheimer Zahlenwert, mit dem eine solche Signatur erzeugt wird. Der private Schlüssel wird dabei nicht offengelegt. Die Einstellung sighash legt fest, welche Teile die Signatur abdeckt; nicht jeder Modus signiert alles. Ältere Skripte und SegWit Version 0 verwenden das Signaturverfahren ECDSA. Tapscript, die Skriptregeln von Taproot, verwendet für gewöhnliche 32-Byte-Schlüssel das andere Verfahren Schnorr. Der Anweisungsname allein verrät diesen Zusammenhang nicht. [1] [3]

Eine Bedingung kann normales Ausgeben oder einen alternativen Wiederherstellungsweg erlauben. OP_IF und OP_ELSE wählen anhand eines Stackwerts einen Zweig; OP_ENDIF schließt den bedingten Abschnitt. Bitcoin Script hat keine allgemeinen Programmschleifen, die sich beliebig wiederholen. Trotzdem darf nicht alles in einem nicht ausgeführten Zweig ignoriert werden. Manche Anweisungen werden schon beim Lesen geprüft. Ihre Art und die Regelversion sind entscheidend. [1] [3]

CLTV, die Anweisung OP_CHECKLOCKTIMEVERIFY, kann eine absolute Grenze erzwingen, etwa eine festgelegte Blockhöhe, also die Position des Blocks in der Kette. CSV, OP_CHECKSEQUENCEVERIFY, erzwingt zusammen mit den Altersregeln eine relative Wartezeit ab Bestätigung des ausgegebenen Ausgangs. Ein Ausgang ist ein zuvor empfangener Betrag samt Ausgabebedingungen. Die Anweisungen prüfen Transaktionsfelder; sie starten keinen Timer, senden kein Geld und ersetzen keine Signatur. Für eine konkrete Anwendung muss die passende Zeitsperre mit den übrigen Bedingungen kombiniert werden. [7] [8] [9]

Klären Sie vor einem technischen Beispiel, ob es ältere Skripte, SegWit oder Tapscript verwendet. Tapscript ergänzt OP_CHECKSIGADD zum Kombinieren von Signaturprüfungen. OP_CHECKMULTISIG dagegen scheitert bei Ausführung; in einem nicht ausgeführten Zweig wird es nach diesen Regeln ignoriert. Die Namen widersprechen sich nicht, die Prüfumgebungen unterscheiden sich. Eine Opcodeliste ist kein universeller Baukasten, dessen Teile ohne Weiteres zwischen Formaten austauschbar sind. [1] [3] [6]

BIP 342 reserviert die Familie OP_SUCCESSx für künftige Tapscript-Erweiterungen. Nach bestandenen vorgelagerten Prüfungen genügt ihr Auftreten beim Dekodieren, um die folgenden Skriptprüfungen erfolgreich zu überspringen, auch in einem nicht ausgeführten Zweig. Ein zufällig gleiches Byte innerhalb eingefügter Daten zählt nicht. Das schafft Raum für Regeländerungen; es ist keine bereits aktivierte neue Schutzfunktion. Eine Bedingung, die sich auf eine noch undefinierte künftige Bedeutung stützt, schützt die Coins womöglich nicht wie erwartet. [1] [3]

Ein Full Node prüft Gültigkeitsregeln selbstständig, kann aber strengere Regeln für das Annehmen und Weiterleiten unbestätigter Transaktionen haben. Bitcoin Core v29.0 lehnt beispielsweise standardmäßig die Weiterleitung von Transaktionen ab, die eine OP_SUCCESSx-Anweisung in Tapscript verwenden, obwohl der Konsens sie im Block erlauben kann. Prüfen Sie bei einem Beispiel daher Version, Anfangsdaten, Signaturumfang und Fehlerfälle. Lesbare Syntax allein belegt keine sichere Wallet; bei gewöhnlicher Nutzung übernimmt geprüfte Software diese Arbeit. [1] [5]