Einführung

Bitcoin wird manchmal als programmierbares Geld bezeichnet. Aufgrund seiner digitalen Natur bietet es den Benutzern ein hohes Maß an Flexibilität bei der Festlegung der Bedingungen für die Ausgabe von Geldern.

Wenn wir über Bitcoin sprechen, sprechen wir von Wallets und Coins. Aber wir könnten uns Wallets auch als Schlüssel, Coins als Schecks und die Blockchain als eine Reihe verschlossener Tresore vorstellen. Jeder Tresor hat einen schmalen Schlitz, sodass jeder Schecks einwerfen oder nachschauen kann, wie viel Wert der Tresor enthält. Allerdings hat nur der Schlüsselinhaber Zugriff auf das Innere.

Wenn ein Schlüsselinhaber jemand anderem Geld geben möchte, schließt er sein Schließfach auf. Er stellt einen neuen Scheck aus, der auf den alten verweist (der dann vernichtet wird) und schließt ihn in ein Schließfach, das der Empfänger öffnen kann. Um das Geld auszugeben, wiederholt der neue Empfänger den Vorgang.

In diesem Artikel werden wir uns Script genauer ansehen, die Programmiersprache, die von Knoten im Bitcoin-Netzwerk interpretiert wird. Script steuert den erwähnten Sperr-/Entsperrmechanismus für die Safes.

Wie funktioniert Bitcoin?

Wenn wir unsere Analogie von oben weiterführen, könnten wir sagen, dass jede Transaktion aus zwei Teilen besteht – einem Schlüssel (um Ihre Box aufzuschließen) und einem Schloss. Mit Ihrem Schlüssel öffnen Sie die Box, in der sich der Scheck befindet, den Sie verschicken möchten, und legen dann einen neuen Schlüssel in eine neue Box mit einem anderen Schloss. Um aus der neuen Box Geld auszugeben, benötigen Sie einen weiteren Schlüssel.

Ganz einfach. Sie können auch die Schlossarten im System etwas variieren. Manche Tresore erfordern vielleicht, dass Sie mehrere Schlüssel angeben, und bei anderen müssen Sie nachweisen, dass Sie ein Geheimnis kennen. Es gibt eine Menge Bedingungen, die man festlegen kann.

Unser Schlüssel ist das, was wir scriptSig nennen. Das Schloss ist unser scriptPubKey. Wenn wir uns diese Komponenten etwas genauer ansehen, werden wir feststellen, dass sie eigentlich aus Datenbits und Codeblöcken bestehen. In Kombination ergeben sie ein kleines Programm.

Wenn Sie eine Transaktion durchführen, senden Sie diese Kombination an das Netzwerk. Jeder Knoten, der sie empfängt, überprüft das Programm und erkennt, ob die Transaktion gültig ist. Wenn nicht, wird sie einfach verworfen und Sie können die gesperrten Mittel nicht ausgeben.

Die Schecks (Münzen), die Sie besitzen, werden als nicht ausgegebene Transaktionsausgaben (UTXOs) bezeichnet. Die Mittel können von jedem verwendet werden, der den passenden Schlüssel zum Schloss bereitstellen kann. Genauer gesagt ist der Schlüssel die scriptSig und das Schloss der scriptPubKey.

Wenn sich die UTXOs in Ihrem Wallet befinden, unterliegen sie wahrscheinlich einer Bedingung, die besagt, dass nur die Person, die den Besitz dieses öffentlichen Schlüssels nachweisen kann, diese Mittel freigeben kann. Um sie freizugeben, stellen Sie ein scriptSig bereit, das eine digitale Signatur enthält, und verwenden dabei den privaten Schlüssel, der dem im scriptPubKey angegebenen öffentlichen Schlüssel entspricht. Dies alles wird in Kürze klarer.

Den Bitcoin-Stack verstehen

Skript ist eine sogenannte stapelbasierte Sprache. Das bedeutet, dass wir beim Lesen einer Reihe von Anweisungen diese in einer Art vertikaler Spalte platzieren. Die Liste A, B, C würde beispielsweise einen Stapel ergeben, bei dem A unten und C oben steht. Wenn die Anweisungen uns sagen, dass wir etwas tun sollen, bearbeiten wir ein oder mehrere Elemente, beginnend oben im Stapel.

Die Elemente A, B und C werden zum Stapel hinzugefügt und daraus entfernt.

Wir können zwischen den Daten (Dingen wie Signaturen, Hashes und öffentlichen Schlüsseln) und den Anweisungen (oder Opcodes) unterscheiden. Die Anweisungen entfernen Daten und tun etwas damit. Hier ist ein sehr einfaches Beispiel, wie ein Skript aussehen könnte:

<xyz> <md5-Hasher> <d16fb36f0911f878998c136191af705e> <auf Gleichheit prüfen>

In Rot haben wir Daten und in Blau haben wir die Opcodes. Wir lesen von links nach rechts, also legen wir zuerst die Zeichenfolge <xyz> auf den Stapel. Als nächstes kommt der Opcode <md5 hasher>. Dieser existiert in Bitcoin nicht, aber nehmen wir an, er entfernt das oberste Element des Stapels (<xyz>) und hasht es mit dem MD5-Algorithmus. Dann wird die Ausgabe wieder zum Stapel hinzugefügt. Die Ausgabe hier ist zufällig d16fb36f0911f878998c136191af705e.

Was für ein Zufall! Unser nächstes hinzuzufügendes Element ist <d16fb36f0911f878998c136191af705e>, sodass unser Stapel nun zwei identische Elemente enthält. Zuletzt nimmt <check if equal> zwei Elemente von oben und prüft, ob sie gleich sind. Wenn dies der Fall ist, fügt es <1> zum Stapel hinzu. Wenn nicht, fügt es <0> hinzu.

Wir sind am Ende unserer Anweisungsliste angelangt. Unser Skript hätte auf zwei Arten fehlschlagen können – wenn das verbleibende Element eine Null gewesen wäre oder wenn einer der Operatoren den Fehler verursacht hätte, weil bestimmte Bedingungen nicht erfüllt waren. In diesem Beispiel hatten wir keine solchen Operatoren und wir haben am Ende ein Element ungleich Null (<1>), also war unser Skript gültig. Diese Regeln gelten auch für echte Bitcoin-Transaktionen.

Das war nur ein erfundenes Programm. Schauen wir uns jetzt einige echte Programme an.

Bezahlen an Pubkey (P2PK)

Pay-to-Pubkey (P2PK) ist unglaublich unkompliziert. Dabei werden Gelder an einen bestimmten öffentlichen Schlüssel gebunden. Wenn Sie auf diese Weise Geld erhalten möchten, geben Sie dem Absender Ihren öffentlichen Schlüssel und nicht eine Bitcoin-Adresse an.

Die allererste Transaktion zwischen Satoshi Nakamoto und Hal Finney im Jahr 2009 war eine P2PK-Transaktion. Die Struktur wurde in den frühen Tagen von Bitcoin häufig verwendet, aber heutzutage wurde sie weitgehend durch Pay-to-Pubkey-Hash (P2PKH) ersetzt.

Das Sperrskript für eine P2PK-Transaktion folgt dem Format <public key> OP_CHECKSIG. Ganz einfach. Sie haben vielleicht schon erraten, dass OP_CHECKSIG eine Signatur anhand des bereitgestellten öffentlichen Schlüssels prüft. Daher wird unsere ScriptSig eine einfache <signature> sein. Denken Sie daran, dass die ScriptSig der Schlüssel zum Schloss ist.

Viel einfacher geht es nicht. Dem Stapel wird eine Signatur hinzugefügt, gefolgt von einem öffentlichen Schlüssel. OP_CHECKSIG holt beide heraus und überprüft die Signatur anhand des öffentlichen Schlüssels. Wenn sie übereinstimmen, wird dem Stapel ein <1> hinzugefügt. Andernfalls wird ein <0> hinzugefügt.

Aus Gründen, die wir im nächsten Abschnitt näher erläutern, wird P2PK nicht mehr wirklich verwendet.

Pay-to-Pubkey-Hash (P2PKH)

Pay-to-Pubkey-Hash (P2PKH) ist heute die häufigste Transaktionsart. Sofern Sie sich nicht extra die Mühe machen, veraltete Software herunterzuladen, erledigt Ihr Wallet diese wahrscheinlich standardmäßig.

Der scriptPubKey in P2PKH ist der folgende:

OP_DUP OP_HASH160 <Public-Key-Hash> OP_EQUALVERIFY OP_CHECKSIG

Bevor wir scriptSig vorstellen, wollen wir aufschlüsseln, was die neuen Opcodes bewirken:

OP_DUP

OP_DUP entfernt das erste Element und dupliziert es. Anschließend fügt es beide Elemente wieder zum Stapel hinzu. Normalerweise geschieht dies, damit wir eine Operation am Duplikat durchführen können, ohne das Original zu beeinträchtigen.

OP_HASH160

Dadurch wird das erste Element herausgenommen und zweimal gehasht. In der ersten Runde wird mit dem SHA-256-Algorithmus gehasht. Die SHA-256-Ausgabe wird dann mit dem RIPEMD-160-Algorithmus gehasht. Die resultierende Ausgabe wird wieder zum Stapel hinzugefügt.

OP_EQUALVERIFY

OP_EQUALVERIFY kombiniert zwei weitere Operatoren – OP_EQUAL und OP_VERIFY. OP_EQUAL holt zwei Elemente heraus und prüft, ob sie identisch sind. Wenn dies der Fall ist, fügt es dem Stapel eine 1 hinzu. Wenn nicht, fügt es eine 0 hinzu. OP_VERIFY holt das oberste Element heraus und prüft, ob es True (d. h. ungleich Null) ist. Wenn nicht, schlägt die Transaktion fehl. Kombiniert führt OP_EQUALVERIFY dazu, dass die Transaktion fehlschlägt, wenn die beiden obersten Elemente nicht übereinstimmen.

Dieses Mal sieht die ScriptSig folgendermaßen aus:

<Signatur> <öffentlicher Schlüssel>

Sie müssen eine Signatur und den entsprechenden öffentlichen Schlüssel bereitstellen, um P2PKH-Ausgaben freizuschalten.

Was passiert, können Sie im obigen GIF sehen. Es unterscheidet sich nicht allzu sehr von einem P2PK-Skript. Wir fügen lediglich einen zusätzlichen Schritt hinzu, um zu prüfen, ob der öffentliche Schlüssel mit dem Hash im Skript übereinstimmt.

Es gibt jedoch etwas zu beachten. In einem P2PKH-Sperrskript ist der öffentliche Schlüssel nicht sichtbar – wir können nur seinen Hash sehen. Wenn wir zu einem Blockchain-Explorer gehen und uns eine P2PKH-Ausgabe ansehen, die nicht ausgegeben wurde, können wir den öffentlichen Schlüssel nicht ermitteln. Er wird erst angezeigt, wenn der Empfänger beschließt, die Mittel zu überweisen.

Dies hat mehrere Vorteile. Der erste ist, dass der Public-Key-Hash einfach leichter weiterzugeben ist als ein vollständiger Public Key. Satoshi hat ihn 2009 genau aus diesem Grund eingeführt. Der Public-Key-Hash ist das, was wir heute als Bitcoin-Adresse kennen.

Der zweite Vorteil ist, dass Public-Key-Hashes eine zusätzliche Sicherheitsebene gegen Quantencomputer bieten könnten. Da unser Public Key erst bekannt ist, wenn wir die Mittel ausgeben, ist es für andere noch schwieriger, den Private Key zu berechnen. Sie müssten die beiden Hashing-Runden (RIPEMD-160 und SHA-256) umkehren, um ihn zu bekommen.

➠ Möchten Sie mit Kryptowährungen anfangen? Kaufen Sie Bitcoin auf Binance!

Bezahl-für-Skript-Hash (P2SH)

Pay-to-Script-Hash (P2SH) war eine sehr interessante Entwicklung für Bitcoin. Es ermöglicht dem Absender, Gelder an den Hash eines Skripts zu binden – er muss nicht wissen, was das Skript tatsächlich tut. Nehmen wir den folgenden SHA-256-Hash:

e145fe9ed5c23aa71fdb443de00c7d9b4a69f8a27a2e4fbb1fe1d0dbfb6583f1

Sie müssen die Eingabe des Hashs nicht kennen, um Gelder daran zu binden. Der Ausgeber muss jedoch das Skript bereitstellen, das zum Hashen verwendet wurde, und muss die Bedingungen dieses Skripts erfüllen.

Der obige Hash wurde aus dem folgenden Skript erstellt:

<mit 2 multiplizieren> <4> <überprüfen, ob gleich>

Wenn Sie die an diesen scriptPubKey gebundenen Münzen ausgeben möchten, müssen Sie nicht nur diese Befehle angeben. Sie benötigen auch eine scriptSig, die dafür sorgt, dass das abgeschlossene Skript als True ausgewertet wird. In diesem Beispiel ist das ein Element, das Sie mit 2> <multiplizieren, um ein Ergebnis von <4> zu erhalten. Das bedeutet natürlich, dass unsere scriptSig nur <2> ist.

In der Praxis lautet der ScriptPubKey für eine P2SH-Ausgabe:

OP_HASH160 <redeemScript-Hash> OP_EQUAL

Hier gibt es keine neuen Operatoren. Aber wir haben <redeemScript hash> als neues Element. Wie der Name schon sagt, handelt es sich um einen Hash des Skripts, das wir bereitstellen müssen, um die Mittel einzulösen (das sogenannte redeemScript). Die scriptSig ändert sich je nachdem, was im redeemScript steht. Im Allgemeinen werden Sie jedoch feststellen, dass es sich um eine Kombination aus Signaturen und den angehängten öffentlichen Schlüsseln handelt, gefolgt vom (obligatorischen) redeemScript:

<signature> <öffentlicher Schlüssel> <redeemScript>

Unsere Auswertung unterscheidet sich ein wenig von der Stack-Ausführung, die wir bisher gesehen haben. Sie erfolgt in zwei Teilen. Der erste prüft einfach, ob Sie den richtigen Hash angegeben haben.

Sie werden feststellen, dass wir mit den Elementen vor dem RedeemScript nichts machen. Sie werden an dieser Stelle nicht verwendet. Wir haben das Ende dieses Miniprogramms erreicht und das oberste Element ist ungleich Null. Das bedeutet, es ist gültig.

Wir sind jedoch noch nicht fertig. Netzwerkknoten erkennen diese Struktur als P2SH, sodass die Elemente von scriptSig tatsächlich in einem anderen Stapel warten. Dort werden die Signatur und der öffentliche Schlüssel verwendet.

Bisher haben wir das RedeemScript als Element behandelt. Aber jetzt wird es als Anweisung interpretiert, die alles Mögliche sein kann. Nehmen wir das Beispiel eines P2PKH-Sperrskripts, dem wir die <signature> und den <public key> bereitstellen müssen, die mit einem <public key hash> im <redeemScript> übereinstimmen.

Sobald Ihr RedeemScript erweitert wurde, können Sie sehen, dass wir eine Situation haben, die genau wie eine normale P2PKH-Transaktion aussieht. Von dort aus führen Sie es einfach wie eine normale Transaktion aus.

Wir haben hier ein sogenanntes P2SH(P2PKH)-Skript demonstriert, aber es ist unwahrscheinlich, dass Sie eines in freier Wildbahn finden. Nichts hindert Sie daran, eines zu erstellen, aber es bringt Ihnen keine zusätzlichen Vorteile und nimmt letztendlich mehr Platz in einem Block ein (und kostet daher mehr).

P2SH ist im Allgemeinen praktisch für Dinge wie Multisignatur- oder SegWit-kompatible Transaktionen. Multisig-Transaktionen können sehr groß sein, da sie möglicherweise mehrere Schlüssel erfordern. Vor der Implementierung von Pay-to-Script-Hash musste ein Absender alle möglichen öffentlichen Schlüssel in seinem Sperrskript auflisten.

Bei P2SH spielt es jedoch keine Rolle, wie komplex die Ausgabebedingungen sind. Der Hash des RedeemScripts hat immer eine feste Größe. Die Kosten werden daher an den/die Benutzer weitergegeben, die das Sperrskript entsperren möchten.

Die SegWit-Kompatibilität ist ein weiterer Fall, in dem P2SH nützlich ist (im nächsten Abschnitt werden wir näher darauf eingehen, wie sich die Transaktionsstruktur unterscheidet). SegWit war ein Soft Fork, der zu einer Änderung der Block-/Transaktionsformate führte. Da es sich um ein Opt-in-Upgrade handelt, erkennt nicht jede Wallet-Software die Änderungen. Es spielt keine Rolle, ob Clients den SegWit-Skript-Hash in P2SH einschließen. Wie bei allen Transaktionen dieser Art müssen sie nicht wissen, was das freischaltende RedeemScript sein wird.

SegWit-Transaktionen (P2WPKH und P2WSH)

Eine umfassendere Einführung in SegWit finden Sie im „A Beginner’s Guide to Segregated Witness“.

Um das Transaktionsformat in SegWit zu verstehen, müssen Sie nur wissen, dass wir nicht mehr nur ein scriptSig und einen scriptPubKey haben. Jetzt haben wir auch ein neues Feld namens Witness. Die Daten, die wir bisher im scriptSig aufbewahrt haben, werden in den Witness verschoben, sodass das scriptSig leer ist.

Wenn Sie auf Adressen gestoßen sind, die mit „bc1“ beginnen, handelt es sich dabei um sogenannte SegWit-native Adressen (im Gegensatz zu lediglich SegWit-kompatiblen Adressen, die mit einer „3“ beginnen, da es sich um P2SH-Adressen handelt).

Bezahlter-Zeugen-Pubkey-Hash (P2WPKH)

Pay-to-Witness-Pubkey-Hash (P2WPKH) ist die SegWit-Version von P2PKH. Unser Witness sieht so aus:

<Signatur> <öffentlicher Schlüssel>

Sie werden feststellen, dass dies dasselbe ist wie die scriptSig von P2PKH. Hier ist die scriptSig leer. Der scriptPubKey sieht dagegen wie folgt aus:

<OP_0> <öffentlicher Schlüssel-Hash>

Das sieht doch etwas seltsam aus, oder? Wo sind die Opcodes, mit denen wir die Signatur, den öffentlichen Schlüssel und seinen Hash vergleichen können?

Wir zeigen hier keine zusätzlichen Operatoren, da Knoten, die die Transaktion empfangen, anhand der Länge von <public key hash> wissen, was sie damit tun sollen. Sie berechnen die Länge und verstehen, dass sie im gleichen Stil wie eine gute alte P2PKH-Transaktion ausgeführt werden muss.

Nicht aktualisierte Knoten wissen nicht, wie sie die Transaktion auf diese Weise interpretieren sollen, aber das spielt keine Rolle. Nach den alten Regeln gibt es keinen Zeugen, also lesen sie ein leeres ScriptSig und einige Daten. Sie werten dies aus und markieren es als gültig – soweit es sie betrifft, könnte jeder die Ausgabe ausgeben. Aus diesem Grund wird SegWit als abwärtskompatibler Soft Fork angesehen.

Bezahlter Zeugen-Skript-Hash (P2WSH)

Pay-to-Witness-Script Hash (P2WSH) ist das neue P2SH. Wenn Sie es bis hierhin geschafft haben, können Sie sich wahrscheinlich vorstellen, wie das aussehen wird, aber wir gehen es trotzdem durch. Unser Witness ist das, was wir normalerweise in die scriptSig schreiben würden. In einem P2WSH, das eine P2PKH-Transaktion umschließt, könnte es beispielsweise ungefähr so ​​aussehen:

<Signatur 1> <öffentlicher Schlüssel>

Hier ist unser ScriptPubKey:

<OP_0> <Skript-Hash>

Es gelten die gleichen Regeln. SegWit-Knoten lesen die Länge des Skript-Hashes und bestimmen, dass es sich um eine P2WSH-Ausgabe handelt, die ähnlich wie P2SH ausgewertet wird. Alte Knoten hingegen betrachten es einfach als eine Ausgabe, die jeder ausgeben kann.

Abschließende Gedanken

In diesem Artikel haben wir etwas über die Bausteine ​​von Bitcoin gelernt. Lassen Sie uns sie kurz zusammenfassen:

Wenn Sie sich eingehender mit Bitcoin befassen, beginnen Sie zu verstehen, warum es so viel Potenzial hat. Transaktionen können aus vielen verschiedenen Komponenten bestehen. Durch die Manipulation dieser Bausteine ​​haben Benutzer viel Flexibilität, wenn es darum geht, Bedingungen festzulegen, wie und wann Geld ausgegeben werden kann.

➠ Fragen zum Skript? Gehen Sie zu Ask Academy!