OP_CHECKSIG

Nahezu jeder Bitcoin, der je ausgegeben wurde, ist durch diesen einen Opcode gelaufen, das Byte 0xac. Er bildet einen Digest der Transaktion nach dem Sighash-Byte, das an das Ende der Signatur angehängt ist, prüft die Signatur gegen den öffentlichen Schlüssel und legt true oder false auf den Stack. Legt er false auf den Stack, findet die Ausgabe nicht statt, und das ist in Code das Ganze dessen, was es bedeutet, Bitcoin zu besitzen.

So funktioniert es

OP_CHECKSIG nimmt zwei Elemente vom Stack, zuerst den öffentlichen Schlüssel und darunter die Signatur, und erledigt dann drei getrennte Aufgaben, die üblicherweise zu einer zusammengefasst werden.

Zuerst entscheidet er, was signiert wurde. Das letzte Byte einer Signatur ist nicht Teil der Signatur: Es ist ein Flag, das angibt, welche Teile der Transaktion der Digest abdeckte. Der bei Weitem häufigste Wert ist 0x01, das heißt alle Eingaben und alle Ausgaben, sodass jede Änderung an irgendeinem Teil der Transaktion nach dem Signieren sie ungültig macht. Das Verfahren zum Bilden dieses Digests wurde zweimal ersetzt, durch BIP-143 für SegWit-Ausgaben der Version 0 und erneut durch BIP-341 für Taproot, beide Male, um zu verhindern, dass die Kosten des Hashings mit dem Quadrat der Transaktionsgröße wachsen.

Zweitens prüft er die Kodierung, und Bitcoin ist hier ungewöhnlich streng. Eine Legacy-Signatur muss gültiges DER sein, höchstens 72 Bytes einschließlich des Flag-Bytes, mit dem S-Wert in der unteren Hälfte der Kurvenordnung. Die Regel zur strikten Kodierung kam als BIP-66 im Juli 2015, und die Umstellung machte an einem einzigen Nachmittag sechs Blöcke zu Waisen, weil mehrere große Pools auf Block-Headern aufbauten, die sie nicht validiert hatten. Sie bleibt die klarste Darstellung dessen, dass Mining und Validieren verschiedene Aufgaben sind.

Drittens verifiziert er. Legacy- und SegWit-Ausgaben der Version 0 verwenden ECDSA über secp256k1. Tapscript verwendet stattdessen eine 64-Byte-Schnorr-Signatur nach BIP-340, verlangt, dass eine fehlgeschlagene Prüfung ein leeres Element auf den Stack legt und nichts anderes, und belastet das Skript mit 50 Gewichtseinheiten Budget für jede geprüfte Signatur.

Wo er auftritt

OP_CHECKSIG schließt fast jedes Skript ab, das existiert. Eine Legacy-Ausgabe endet damit, eine native SegWit-Ausgabe mit einem einzigen Schlüssel führt dieselbe Vorlage mit demselben abschließenden Opcode aus, obwohl diese Bytes nie auf der Chain erscheinen, und die Commitment-Skripte von Lightning enden damit nach ihren Timelock- und Widerrufszweigen.

Die Ausnahme sollten Sie kennen, wenn Sie einen Block-Explorer lesen. Eine Taproot-Ausgabe über den Schlüsselpfad führt überhaupt kein Skript aus: Der Node prüft eine einzelne Signatur direkt gegen den 32-Byte-Schlüssel in der Ausgabe. Es gibt keine Assembler-Darstellung zum Anzeigen und keinen Opcode, auf den man zeigen könnte, und genau deshalb ist dieser Ausgabetyp der günstigste und privateste, der verfügbar ist, und deshalb sieht eine bc1p-Adresse, die nur von ihrem Eigentümer ausgegeben wird, auf der Chain identisch aus wie jede andere.

OP_CHECKSIG vs. OP_CHECKSIGADD

OP_CHECKSIGADD existiert, weil OP_CHECKSIG nicht gezählt werden kann. In einem Skript mit mehreren Parteien müssen Sie wissen, wie viele der vorgelegten Signaturen gültig waren, und das alte Design beantwortete das mit einem einzigen Opcode, der eine ganze Liste von Schlüsseln und Signaturen auf einmal verschluckte. Tapscript ersetzte ihn durch einen Opcode, der eine Signatur prüft und eins zu einer laufenden Summe auf dem Stack addiert, sodass aus einer 2-von-3-Regel eine kurze Sequenz wird, die mit einem Vergleich gegen 2 endet. Die Änderung ist nicht kosmetisch: Signaturen einzeln zu zählen ist das, was es erlaubt, Schnorr-Signaturen in Stapeln zu verifizieren, und aus der Batch-Verifizierung kommt die Validierungsgeschwindigkeit von Taproot.