Bitcoin Script ist eine Sprache für Ausgabebedingungen. Jeder Transaktionsausgang – ein Betrag mit Bedingungen für seine nächste Verwendung – trägt solche Bedingungen. Wer ihn ausgeben möchte, muss sie erfüllen. Script hilft damit, eine einfache Frage zu beantworten: Darf diese Transaktion genau dieses Geld verwenden?
Alice erhält 20 000 sat, also zwanzigtausend der kleinsten Bitcoin-Einheiten. Das Netzwerk eröffnet kein Konto auf ihren Namen. Es entsteht ein Transaktionsausgang: ein Betrag samt Bedingung für das spätere Ausgeben. Solange er nicht ausgegeben wurde, heißt er UTXO. Bei einer gewöhnlichen Zahlung verlangt die Bedingung eine Signatur mit dem passenden Schlüssel. Wenn Alice später bezahlt, wählt ihre Wallet diesen Ausgang aus, verweist mit einem neuen Transaktionseingang darauf und erstellt eine digitale Signatur. Dafür verwendet sie den privaten Schlüssel, ohne ihn irgendwohin zu senden; andere prüfen die Signatur mit dem öffentlichen Schlüssel. Alices Empfangsadresse zu kennen, genügt nicht. Die Bedingungen des ursprünglichen Ausgangs stehen im Feld scriptPubKey. Bitcoin Script legt fest, wie ihre Erfüllung geprüft wird. Ein Knoten ist dabei kein Beamter, der Alice erkennt, sondern ein Computer, der Regeln kontrolliert. Neben der Signatur muss er beispielsweise prüfen, ob derselbe Ausgang bereits ausgegeben wurde. Erst wenn alle einschlägigen Regeln erfüllt sind, ist die Transaktion gültig. [4] [2]
Bei gewöhnlichen Zahlungen erstellt die Wallet die Bedingungen. Sichern Sie sie nach ihrer Anleitung; eine normale Wiederherstellung aus Wörtern in einer kompatiblen Wallet verlangt nicht automatisch, jedes Skript von Hand aufzubewahren. Bei komplexeren Konfigurationen wie Multisig, die mehrere Signaturen erfordern, beschreiben die Wörter eines einzelnen Beteiligten aber möglicherweise nicht die gesamte Ausgaberegelung. Für den Alltag eignet sich eine Wallet mit erprobten Verfahren besser als das manuelle Zusammenstellen von Skripten in Hexadezimalschreibweise. Ausgangsdeskriptoren beschreiben den Skripttyp, die Schlüssel und ihre Ableitung und helfen so festzulegen, wonach eine wiederhergestellte Wallet suchen soll. Ein privater Schlüssel allein genügt möglicherweise nicht, um eine komplexere Konfiguration wiederherzustellen. Bewahren Sie auch die erforderlichen Skripte und Angaben zur Schlüsselherkunft auf, also woher und wie die Schlüssel abgeleitet wurden, und prüfen Sie die vorgesehenen Ausgabepfade. [11]
Die folgenden Kapitel zeigen die Kodierung der Bedingungen innerhalb einer Transaktion; zum alltäglichen Bezahlen müssen Sie sie nicht kennen. Das Feld scriptSig und der Bereich witness liefern Prüfdaten. Ein Hash ist ein Datenfingerabdruck; eine Zeitsperre verhindert das Ausgeben vor einer bestimmten Grenze. Einen Stapel kann man sich als übereinanderliegende Elemente vorstellen, die von oben bearbeitet werden. Script verarbeitet Daten mithilfe eines Stapels: Werte werden darauf abgelegt, und als Opcodes bezeichnete Anweisungen nehmen sie herunter, vergleichen sie oder verarbeiten sie anderweitig. Signaturanweisungen prüfen Signaturen; private Schlüssel und das Erstellen von Signaturen gehören nicht zu dieser Prüfung. Die Sprache kann Signaturen, Hash-Bedingungen und Zeitsperren kombinieren. Sie besitzt keine allgemeinen Schleifen und ist nicht Turing-vollständig: Sie kann nicht jede Berechnung ausdrücken, die in einer universellen Programmiersprache möglich ist. Der Knoten muss die genauen Regeln für den jeweiligen Ausgangstyp und die Skriptversion anwenden. [1] [3]
Ein Ausgang vom Typ P2PKH (Pay to Public Key Hash) hat üblicherweise die Form OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. Der Eingang liefert in seinem scriptSig eine Signatur und einen öffentlichen Schlüssel. Bei der Prüfung wird kontrolliert, ob der Hash des öffentlichen Schlüssels dem Wert im Ausgang entspricht; anschließend wird die Signatur geprüft. Die Adresse oder den öffentlichen Schlüssel zu kennen, reicht zum Ausgeben daher nicht aus. Den privaten Schlüssel verwendet die signierende Wallet, nicht der Knoten, der die Transaktion prüft. [1]
P2SH speichert gemäß BIP16 den Hash eines Skripts im Ausgang. Der ausgebende Eingang liefert das passende redeemScript, also das beim Ausgeben offengelegte Skript, zusammen mit den nötigen Daten. Sein scriptSig darf ausschließlich Anweisungen enthalten, die Daten auf den Stapel legen. Der Knoten prüft zuerst den Hash und wertet dann redeemScript mit den übrigen Stapelelementen aus. Ein passender Hash allein reicht nicht zum Ausgeben: Auch die Bedingungen dieses Skripts müssen erfüllt sein. [5]
Bei SegWit Version 0 werden die Prüfdaten in den als witness bezeichneten Teil der Transaktion verlagert. Dieser ist eine Liste von Datenelementen und selbst kein Skript. P2WPKH verwendet eine Signatur und einen öffentlichen Schlüssel; P2WSH enthält außerdem ein witnessScript, dessen SHA256-Hash zum Ausgang passen muss. Bei nativem SegWit ist scriptSig leer. Bei einer Einbettung in P2SH enthält es nur eine Anweisung zum Ablegen des entsprechenden witness-Programms; die eigentlichen Prüfdaten bleiben im witness. [6]
Die Signaturprüfung arbeitet mit einer Nachricht, die nach einem festgelegten Verfahren aus der Transaktion abgeleitet wird. Der SIGHASH-Modus bestimmt, welche Teile die Signatur vor Änderungen schützt. Es lässt sich daher nicht pauschal sagen, dass jede Signatur die gesamte Transaktion abdeckt. BIP143 bezieht bei Signaturoperationen in SegWit Version 0 stets auch den Betrag des ausgegebenen Ausgangs ein. Die Wallet muss die richtigen Daten und den gewählten Modus kennen; Script beurteilt bei der Prüfung nicht die menschliche Absicht des Unterzeichners. [7]
Taproot erlaubt gemäß BIP341, einen Ausgang vom Typ P2TR (Pay to Taproot) auf zwei Arten auszugeben. Der Schlüsselpfad prüft eine Schnorr-Signatur gegen den öffentlichen Ausgangsschlüssel, ohne ein Skript offenzulegen. Der Skriptpfad legt dagegen das gewählte Skript und einen Kontrollblock, den control block, offen, der dessen Bindung an den Ausgang nachweist. Die anderen Skripte im Baum müssen nicht offengelegt werden. Die Regeln für das offengelegte Skript hängen auch von der Version des zugehörigen Blattes ab. [8]
BIP342 definiert Tapscript für Taproot-Blätter der Version 0xc0. Die Signaturanweisungen verwenden hier Schnorr-Signaturen, und OP_CHECKSIGADD ermöglicht Bedingungen, die mehrere Signaturen verlangen. Das alte OP_CHECKMULTISIG ist bei der Ausführung verboten. Die bisherige Skriptlängengrenze von 10 000 Byte und die Grenze von 201 nach den älteren Regeln gezählten Opcodes gelten nicht. Ein aus der Größe des witness abgeleitetes Budget begrenzt Signaturoperationen; Grenzen für den Stapel bestehen weiterhin. Die Grenzen einer Version dürfen daher nicht als allgemeine Eigenschaften von Script dargestellt werden. [9]
Die Konsensregeln bestimmen, ob das Ausgeben eines Ausgangs in einem Block gültig ist. Standardness bezeichnet zusätzliche lokale Regeln eines Knotens für die Aufnahme unbestätigter Transaktionen in den Mempool und ihre Weiterleitung; damit ist kein Standardisierungsverfahren gemeint. Eine nach den Konsensregeln gültige Transaktion wird daher möglicherweise nicht allgemein weitergeleitet. Besondere Vorsicht gilt bei OP_SUCCESSx in Tapscript: Sind die vorherigen Prüfungen bestanden, beendet das Erkennen dieses Opcodes beim Dekodieren die Skriptprüfung erfolgreich, noch vor der normalen Ausführung und den Stapelprüfungen. Dies schafft Raum für künftige Erweiterungen und ist keine gewöhnliche sichere Ausgabebedingung. [10] [9]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Transaktion, Multisig, Timelock, Taproot. Auf diesen Eintrag verweisen außerdem Hash, SHA-256, Konsensregeln, Timelock.