OP_EQUAL

Das Byte 0x87 erledigt den einzigen Vergleich, den Bitcoin wirklich braucht: Sind diese beiden Byte-Folgen identisch? Der Vergleich erfolgt auf Rohbytes und nicht auf Zahlen, weshalb die Sprache einen eigenen Opcode für die arithmetische Gleichheit enthält. Jede Zahlung, die Sie je an eine mit 3 beginnende Adresse gesendet haben, beendet ihr Skript mit dieser einen Anweisung.

Funktionsweise

Zwei Elemente werden vom Stapel genommen und eines wird wieder aufgelegt: ein einzelnes Byte 0x01, wenn sie übereinstimmen, oder ein leeres Element, wenn nicht. Bitcoin behandelt ein leeres Element als falsch, sodass das Ergebnis von allem geprüft werden kann, was folgt.

Der Byte-Vergleich ist strenger, als es klingt. Zwei Werte, die ein Mensch als dieselbe Zahl bezeichnen würde, können unterschiedliche Byte-Folgen sein, und dieser Opcode nennt sie ungleich. Das ist das richtige Verhalten für seine eigentliche Aufgabe, nämlich das Vergleichen von Hashes und Preimages, bei dem jede noch so kleine Abweichung fehlschlagen muss, und deshalb werden arithmetische Ergebnisse stattdessen mit OP_NUMEQUAL verglichen.

Die interessante Eigenschaft ist das, was er nicht tut: Er hinterlässt ein Ergebnis, statt auf eines zu reagieren. Ein Skript endet nur dann erfolgreich, wenn das oben liegende Element wahr ist, ein Skript, das mit diesem Opcode endet, stellt also eine Frage und lässt das Ergebnis als Antwort gelten. Die Cleanstack-Regel von Bitcoin Core fügt hinzu, dass nichts anderes zurückbleiben darf, was beim Ausgeben einer Skript-Hash-Ausgabe genau einen wahren Wert und nichts weiter bedeutet.

Dieses letzte Detail ist folgenreicher, als es aussieht. Pay-to-Script-Hash ist keine allgemeine Regel über gehashte Skripte, sondern eine Regel über ein exakt 23 Byte großes Muster: einen Hash-Opcode, einen 20-Byte-Push und diesen Opcode am Ende. Schreiben Sie dieselbe Logik stattdessen mit der kombinierten Verify-Form, greift die Sonderbehandlung nicht, das Redeem-Skript wird nie extrahiert oder ausgeführt, und die Ausgabe verhält sich wie ein gewöhnliches Hash-Rätsel, das jeder ausgeben kann, der das Preimage errät.

Wo er auftritt

Jede nicht ausgegebene Ausgabe auf einer mit 3 beginnenden Adresse zeigt in einem Block-Explorer dieselbe Drei-Token-Anordnung, die hier endet. Ebenso jede verschachtelte SegWit-Auszahlung, die eine Börse Ihnen je gesendet hat.

Er erscheint auch in hash-verriegelten Verträgen. Die Zahlungsskripte von Lightning hashen ein Geheimnis und vergleichen das Ergebnis mit einem festen Wert, was eine Zahlung über mehrere Stationen hinweg abrechnen lässt, sobald der Empfänger ein 32 Byte großes Preimage offenlegt. Atomare Tauschvorgänge zwischen Chains nutzen dieselbe Form.

OP_EQUAL vs. OP_EQUALVERIFY

OP_EQUALVERIFY ist OP_EQUAL mit eingebauter Prüfung. Das Byte 0x88 führt denselben Vergleich durch und bricht das Skript dann sofort ab, wenn die Antwort falsch ist, wobei nichts auf dem Stapel zurückbleibt, wenn es gelingt. Die Wahl zwischen beiden hängt davon ab, was als Nächstes kommt. Verwenden Sie die einfache Form, wenn der Vergleich die abschließende Antwort des Skripts ist, wie es bei Pay-to-Script-Hash der Fall ist. Verwenden Sie die Verify-Form, wenn der Vergleich eine Bedingung unter mehreren ist und die Ausführung fortgesetzt werden muss, wie es die alte Vorlage mit einem einzigen Schlüssel tut, bevor sie eine Signatur prüft. Die Verify-Form spart zudem ein Byte gegenüber dem Schreiben des Vergleichs und einer separaten Verifizierungsanweisung, was sehr viel mehr zählte, als jedes Byte eines Skripts im Nicht-Witness-Teil der Transaktion lag, mit jeweils vier Gewichtseinheiten.