Scripts

Einstieg: Transaktionen, UTXO und Inputs & Outputs

Inhalt

• Was sind Scripts?
• Warum verwendet Bitcoin Scripts?
• Wie ist ein Script aufgebaut?
• ScriptPubKey
• ScriptSig
• Witness
• Script-Muster
  • P2PK
  • P2PKH
  • Bare Multisig (P2MS)
  • P2SH
  • P2SH-Multisig
  • P2WPKH
  • P2SH-P2WPKH
  • P2SH-P2WSH
  • P2WSH
  • P2TR
  • OP_RETURN

Was sind Scripts?

Bitcoin Script ist eine einfache, stackbasierte Programmiersprache innerhalb des Bitcoin-Protokolls.

Ein Script besteht aus einer Folge von Opcodes (Befehlen) und Daten. Während der Ausführung werden die Opcodes nacheinander abgearbeitet und können Daten auf dem Stack lesen, verändern oder überprüfen.

Scripts ermöglichen es, Bedingungen und Logik direkt in Transaktionen zu speichern.

Beispiele für solche Bedingungen sind:

• Eine gültige Signatur muss vorgelegt werden.
• Mehrere Signaturen (P2MS) müssen vorhanden sein.
• Eine Ausgabe darf erst nach einem bestimmten Zeitpunkt ausgegeben werden (Timelock).
• Es muss ein bestimmter Hashwert nachgewiesen werden.

Scripts definieren die Bedingungen, unter denen ein UTXO später ausgegeben werden darf.

Je nach Verwendungszweck kommen Scripts an unterschiedlichen Stellen einer Transaktion vor.

Die bekanntesten Script-Typen sind:

Beim Ausgeben eines UTXOs werden ScriptSig, Witness und ScriptPubKey gemeinsam ausgeführt.

Erst wenn die Ausführung erfolgreich endet, gilt die Ausgabe in der Validierung als gültig ausgegeben.

Ein bekanntes Beispiel ist P2PKH (Pay-to-Public-Key-Hash).

Der ScriptPubKey eines solchen Outputs enthält die Bedingung:

"Lege einen Public Key vor, dessen Hash diesem Wert entspricht, und liefere eine gültige Signatur."

Beim Ausgeben liefert die spätere Transaktion die erforderlichen Daten im ScriptSig.

Erst wenn beide Scripts gemeinsam erfolgreich ausgeführt werden, darf der UTXO ausgegeben werden.

Warum verwendet Bitcoin Scripts?

Bitcoin muss festlegen können, unter welchen Bedingungen ein UTXO später ausgegeben werden darf.

Eine einfache Lösung wäre gewesen, jedem Output direkt einen Public Key zuzuordnen, wie bei P2PK.

Dadurch ließen sich jedoch nur sehr einfache Ausgabebedingungen abbilden.

Mit Bitcoin Script können dagegen unterschiedliche Bedingungen definiert werden:

• eine gültige Signatur
• mehrere Signaturen (P2MS)
• Zeitbedingungen
• Hashbedingungen
• Kombinationen aus mehreren Regeln

Scripts machen Bitcoin dadurch flexibel, ohne dass für jede neue Ausgabebedingung eine Änderung des Transaktionsformats erforderlich ist.

Technisch gesehen kennt Bitcoin keine Besitzer von Bitcoin.

Das Netzwerk speichert lediglich UTXOs und die Bedingungen, unter denen diese ausgegeben werden dürfen.

Ein UTXO enthält deshalb nicht den Besitzer eines Betrags, sondern ein kleines Script, das die Voraussetzungen für seine spätere Ausgabe beschreibt.

Wie ist ein Script aufgebaut?

Bitcoin Script besteht aus einer Folge von Bytes.

Die Script Engine liest diese Bytes von links nach rechts und interpretiert jedes Byte anhand einer globalen Opcode-Tabelle.

Je nach Bytewert kann ein Byte zwei unterschiedliche Bedeutungen haben:

• Es steht für einen Opcode (Befehl)
• Es beschreibt die Länge eines folgenden Datenblocks

Beispielsweise:

Beim Einlesen betrachtet die Script Engine immer zunächst das aktuelle Byte.

Liegt der Wert in der Opcode-Tabelle, wird der entsprechende Befehl erkannt.

Bei Werten zwischen 0x01-0x4b (1-75) wird das Byte dagegen als Längenangabe interpretiert. Der Zahlenwert des Bytes bestimmt dann, wie viele Bytes anschließend als Daten gelesen werden.

Dadurch kann die Engine allein anhand der Bytefolge erkennen, wo Opcodes enden und wo Datenblöcke beginnen.

Ein typisches Beispiel ist der ScriptPubKey eines P2PKH-Outputs:

Hier werden zunächst die Opcodes OP_DUP und OP_HASH160 erkannt.

Anschließend folgt das Byte 0x14.

Da 0x14 im Bereich 0x01 bis 0x4b liegt, interpretiert die Engine dieses Byte nicht als Opcode, sondern als Zahl.

0x14 entspricht dezimal 20.

Die Engine liest deshalb die nächsten 20 Bytes als Hash160-Datenblock ein und setzt danach mit dem nächsten Byte fort.

An diesem Beispiel lässt sich gut erkennen, woher die Script Engine weiß, welche Bytes Opcodes sind und welche zu einem Datenblock gehören.

Jeder Schritt zeigt, wie das aktuelle Byte interpretiert wird und welche Bytes anschließend eingelesen werden.

ScriptPubKey

Der ScriptPubKey ist das Script eines Outputs.

Er definiert die Bedingungen, unter denen dieser Output später ausgegeben werden darf.

Welche Bedingungen genau definiert werden, hängt vom verwendeten Script-Muster ab.

Die häufigsten ScriptPubKey-Muster sind P2PK, P2PKH, Bare Multisig (P2MS), P2SH, P2WPKH, P2WSH und P2TR.

ScriptSig

Der ScriptSig befindet sich in einem Input.

Er enthält Daten, die benötigt werden, um die Bedingungen des referenzierten ScriptPubKey zu erfüllen.

Typische Inhalte sind:

• Signaturen
• Public Keys
• Redeem Scripts

Welche Daten erforderlich sind, hängt vom verwendeten Script-Muster ab.

Witness

Der Witness ist ein zusätzlicher Datenbereich von SegWit- und Taproot-Transaktionen.

Er übernimmt die Rolle des ScriptSig für moderne Script-Typen und enthält die Daten, die zum Erfüllen der Ausgabebedingungen benötigt werden.

Typische Inhalte sind:

• Signaturen
• Public Keys
• Witness Scripts

Script-Muster

Bitcoin Script ist flexibel und erlaubt unterschiedliche Arten von Ausgabebedingungen.

In der Praxis haben sich jedoch einige standardisierte Script-Muster etabliert, die von Wallets, Nodes und anderen Anwendungen unterstützt werden.

Ein Script-Muster beschreibt das Zusammenspiel zwischen den Bedingungen im Output (ScriptPubKey) und den Nachweisen im späteren Input (ScriptSig oder Witness).

Die meisten dieser Muster verfolgen dasselbe Ziel: Sie legen fest, welche Nachweise erbracht werden müssen, damit ein UTXO ausgegeben werden darf.

Sie unterscheiden sich hauptsächlich darin:

• welche Bedingungen ein Output enthält
• welche Daten später im Input vorgelegt werden müssen
• wie viel Platz die Transaktion benötigt
• welche zusätzlichen Funktionen unterstützt werden

Einfaches Beispiel

Angenommen, ein Output enthält folgendes Script:

Dieses Script fordert:

Lege eine Zahl vor, die gleich 5 ist.

Der spätere Input muss daher eine passende Zahl bereitstellen.

Da am Ende true auf dem Stack liegt, gilt das Script als erfolgreich und der Output kann ausgegeben werden.

Da das Ergebnis false ist, schlägt das Script fehl und der Output kann nicht ausgegeben werden.

P2PK (Pay to Public Key)

P2PK (Pay to Public Key, Zahle an einen Public Key) ist das einfachste Script-Muster in Bitcoin.

Der Output enthält direkt den Public Key, der später zum Ausgeben berechtigt ist.

Als Beispiel dient die Block-170-Transaktion f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16, oft als erste dokumentierte Bitcoin-Zahlung beschrieben.

ScriptPubKey

Output 0 dieser Transaktion: 10 BTC an einen P2PK-Output mit unkomprimiertem Public Key.

Vereinfacht bedeutet dieses Script:

Lege eine gültige Signatur für diesen Public Key vor.

Die frühen P2PK-Outputs enthielten meist unkomprimierte Public Keys (65 Bytes).

Heute werden fast ausschließlich komprimierte Public Keys (33 Bytes) verwendet, wodurch Transaktionen kleiner werden.

ScriptSig

Zum Ausgeben muss der Input lediglich eine Signatur bereitstellen:

Input 0 derselben Transaktion: eine DER-Signatur zum Ausgeben eines älteren P2PK-UTXOs.

Eigenschaften

• einfachstes Bitcoin-Script-Muster
• Public Key wird bereits im Output veröffentlicht
• benötigt nur eine Signatur zum Ausgeben
• wurde häufig in frühen Bitcoin-Blöcken verwendet
• heute weitgehend durch P2PKH, SegWit und Taproot ersetzt

Warum wurde P2PK ersetzt?

Bei P2PK wird der vollständige Public Key bereits im Output gespeichert.

Spätere Script-Muster wie P2PKH speichern stattdessen zunächst nur einen Hash des Public Keys und veröffentlichen den eigentlichen Public Key erst beim ScriptSig.

Beim Ausgeben dieses UTXOs führt die Script Engine ScriptSig und ScriptPubKey nacheinander aus und prüft, ob die Signatur zum im Output hinterlegten Public Key passt.

P2PKH (Pay to Public Key Hash)

P2PKH (Pay to Public Key Hash, Zahle an den Hash eines Public Keys) war über viele Jahre das am häufigsten verwendete Script-Muster in Bitcoin.

Im Gegensatz zu P2PK wird nicht der vollständige Public Key im Output gespeichert, sondern nur dessen Hash160.

Dadurch werden Outputs kleiner und der eigentliche Public Key bleibt zunächst verborgen.

Als Beispiel dient die Block-728-Transaktion 6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516, einer der frühesten dokumentierten P2PKH-Zahlungen.

ScriptPubKey

Ein typischer P2PKH-Output sieht folgendermaßen aus:

Output 0 dieser Transaktion: 100 BTC an einen P2PKH-Output mit 20-Byte Public-Key-Hash.

Vereinfacht bedeutet dieses Script:

Lege den Public Key vor, dessen Hash diesem Wert entspricht, und beweise mit einer gültigen Signatur, dass du den zugehörigen Private Key besitzt.

ScriptSig

Zum Ausgeben eines P2PKH-Outputs müssen zwei Daten im ScriptSig bereitgestellt werden:

Der Public Key wird also erst beim Ausgeben veröffentlicht.

Input 1 der Transaktion 12e753ef5cc30925a6eee2c457aa7f53022443ca013ea81882a6b59b69e342a6: DER-Signatur und unkomprimierter Public Key zum Ausgeben des P2PKH-UTXOs aus Block 728.

Eigenschaften

• lange Zeit Standard-Script-Muster von Bitcoin
• speichert nur den Hash des Public Keys im ScriptPubKey
• Public Key wird erst beim Ausgeben veröffentlicht
• benötigt Signatur und Public Key im ScriptSig
• verwendet HASH160 = RIPEMD160(SHA256(PublicKey)) (Hash160)
• bildet die Grundlage klassischer Bitcoin-Adressen

P2PK vs. P2PKH

Adressen

Die bekannten Bitcoin-Adressen, die mit 1 beginnen, repräsentieren P2PKH-Outputs.

Beispielsweise:

1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

Die Adresse selbst wird nicht im ScriptPubKey gespeichert.

Sie ist lediglich eine menschenfreundliche Darstellung des Public-Key-Hashes.

Intern enthält das ScriptPubKey immer nur den 20-Byte-langen Hash160-Wert.

Warum wurde P2PKH später ersetzt?

Mit SegWit wurden Signaturen aus dem klassischen ScriptSig ausgelagert und Transaktionen effizienter gestaltet.

Neue Script-Muster wie:

• P2WPKH
• P2WSH
• Taproot

reduzieren den Speicherbedarf weiter und beheben verschiedene Einschränkungen älterer Script-Typen.

P2PKH ist dennoch bis heute vollständig gültig und wird weiterhin von allen Bitcoin-Nodes unterstützt.

Bare Multisig (P2MS)

Bare Multisig (P2MS) (Pay to Multisig, Zahle an mehrere Public Keys) ist ein frühes Script-Muster, bei dem die Multisig-Bedingung direkt im Output gespeichert wird.

Ein Output kann dadurch mehrere Public Keys enthalten und festlegen, wie viele davon eine gültige Signatur liefern müssen.

Beispielsweise kann ein Output verlangen:

Mindestens 2 von 3 hinterlegten Public Keys müssen signieren.

Als Beispiel dient die Transaktion 60a20bd93aa49ab4b28d514ec10b06e1829ce6818ec06cd3aabd013ebcdc4bb1 mit einem 1-von-2-P2MS-Output.

ScriptPubKey

Ein typischer P2MS-Output sieht folgendermaßen aus:

Output 0 dieser Transaktion: 0,01 BTC an einen 1-von-2-P2MS-Output mit zwei unkomprimierten Public Keys.

Vereinfacht bedeutet dieses Script:

Lege mindestens 1 gültige Signatur für diese 2 Public Keys vor.

ScriptSig

Zum Ausgeben müssen die erforderlichen Signaturen im ScriptSig bereitgestellt werden:

Input 0 der Transaktion 23b397edccd3740a74adb603c9756370fafcde9bcc4483eb271ecad09a94dd63: führendes OP_0 und eine DER-Signatur zum Ausgeben des P2MS-UTXOs aus Block 164467.

Das führende OP_0 ist eine Besonderheit von OP_CHECKMULTISIG.

Aufgrund eines historischen Implementierungsfehlers wird dabei ein zusätzliches Stack-Element verbraucht, das durch OP_0 ausgeglichen werden muss.

Eigenschaften

• ermöglicht mehrere Berechtigte für einen Output
• verwendet OP_CHECKMULTISIG
• Anzahl benötigter Signaturen frei wählbar (m-von-n)
• Public Keys werden direkt im ScriptPubKey gespeichert
• historischer OP_CHECKMULTISIG-Bug erfordert ein zusätzliches OP_0
• heute nur noch selten verwendet

Warum wurde P2MS ersetzt?

Bei P2MS müssen alle Public Keys direkt im ScriptPubKey gespeichert werden.

Dadurch werden Transaktionen größer und alle Beteiligten bereits beim Erzeugen des Outputs sichtbar.

Später wurde deshalb häufig P2SH verwendet.

Dabei wird zunächst nur ein Hash des eigentlichen Scripts gespeichert und das vollständige P2MS-Script erst beim Ausgeben im ScriptSig veröffentlicht.

Historische Besonderheit

P2MS wird von Bitcoin bis heute unterstützt und kann weiterhin gültige UTXOs erzeugen. Moderne Wallets verwenden dieses Script-Muster jedoch praktisch nicht mehr. Stattdessen kommen heute meist P2SH, SegWit oder Taproot zum Einsatz.

P2SH (Pay to Script Hash)

P2SH (Pay to Script Hash, Zahle an den Hash eines Scripts) ermöglicht es, beliebige Bitcoin-Scripts hinter einem Hash zu verbergen.

Anstatt das vollständige Script direkt im Output zu speichern, enthält der Output lediglich einen Hash des später benötigten Scripts.

Das eigentliche Script wird erst beim Ausgeben veröffentlicht.

P2SH wurde mit BIP16 eingeführt und ab April 2012 im Netzwerk aktiviert.

Als Beispiel für den ScriptPubKey dient die Transaktion 9c08a4d78931342b37fd5f72900fb9983087e6f46c4a097d8a1f52c74e28eaf6, als Beispiel für den ScriptSig die Transaktion e5779b9e78f9650debc2893fd9636d827b26b4ddfa6a8172fe8708c924f5c39d.

ScriptPubKey

Ein typischer P2SH-Output sieht folgendermaßen aus:

Output 1 dieser Transaktion: 0,004 BTC an einen P2SH-Output mit 20-Byte Script-Hash.

Vereinfacht bedeutet dieses Script:

Lege ein Script vor, dessen HASH160 diesem Wert entspricht.

ScriptSig

Zum Ausgeben werden die erforderlichen Daten sowie das vollständige RedeemScript bereitgestellt:

Input 0 der Transaktion e5779b9e78f9650debc2893fd9636d827b26b4ddfa6a8172fe8708c924f5c39d: ein 2-Byte-RedeemScript (OP_3 · OP_7) zum Ausgeben eines P2SH-UTXOs aus Block 174719.

Eigenschaften

• ermöglicht beliebig komplexe Scripts
• Output enthält nur einen Hash des Scripts
• vollständiges Script wird erst beim Ausgeben veröffentlicht
• reduziert die Größe vieler Outputs
• unterstützt Multisig-, Timelock- und andere komplexe Scripts
• eingeführt durch BIP16

Adressen

P2SH-Adressen beginnen mit:

3

Beispielsweise:

3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC

Die Adresse ist lediglich eine menschenfreundliche Darstellung des Script-Hashes.

Im eigentlichen ScriptPubKey wird nur der 20 Byte lange HASH160-Wert gespeichert.

Warum wurde P2SH eingeführt?

Vor P2SH mussten komplexe Scripts direkt im Output gespeichert werden.

Dadurch wurden Outputs größer und alle Details des Scripts waren bereits beim Erzeugen des UTXOs sichtbar.

P2SH verschiebt das vollständige Script in den späteren Spend und speichert zunächst nur dessen Hash.

Dadurch werden Outputs kleiner und komplexe Script-Konstruktionen deutlich praktischer nutzbar.

P2SH-Multisig

P2SH-Multisig (Pay to Script Hash Multisig, Zahle an den Hash eines Multisig-Scripts) kombiniert die Vorteile von P2MS und P2SH.

Anstatt die Multisig-Bedingung direkt im Output zu speichern, wird das vollständige Multisig-Script als RedeemScript hinter einem Hash verborgen.

Dadurch bleiben die Public Keys zunächst verborgen und der Output wird deutlich kleiner.

Als Beispiel dient die Transaktion 450c309b70fb3f71b63b10ce60af17499bd21b1db39aa47b19bf22166ee67144 mit einem 1-von-2-P2SH-Multisig-Output. Input 11 der Transaktion 30c239f3ae062c5f1151476005fd0057adfa6922de1b38d0f11eb657a8157b30 gibt dieses UTXO aus.

ScriptPubKey

Der Output enthält lediglich den Hash des RedeemScripts:

Output 1 dieser Transaktion: 0,1 BTC an einen P2SH-Multisig-Output mit 20-Byte Script-Hash.

Vereinfacht bedeutet dieses Script:

Lege ein RedeemScript vor, dessen HASH160 diesem Wert entspricht.

ScriptSig

Zum Ausgeben werden die erforderlichen Signaturen sowie das RedeemScript bereitgestellt:

Input 11 der Transaktion 30c239f3ae062c5f1151476005fd0057adfa6922de1b38d0f11eb657a8157b30: führendes OP_0, eine DER-Signatur und das 1-von-2-Multisig-RedeemScript zum Ausgeben des P2SH-Multisig-UTXOs aus Block 183729.

Das führende OP_0 ist aufgrund einer historischen Besonderheit von OP_CHECKMULTISIG erforderlich.

RedeemScript

Ein typisches 1-von-2-Multisig-RedeemScript sieht folgendermaßen aus:

Vereinfacht bedeutet dieses Script:

Lege mindestens 1 gültige Signatur für diese 2 Public Keys vor.

P2MS vs. P2SH-Multisig

Eigenschaften

• unterstützt m-von-n-Multisig
• Public Keys zunächst verborgen
• kleinerer Output als P2MS
• lange Zeit Standard für Multisig-Wallets
• basiert auf P2SH und RedeemScripts

P2WPKH (Pay to Witness Public Key Hash)

P2WPKH (Pay to Witness Public Key Hash, Zahle an den Witness-Hash eines Public Keys) ist die SegWit-Variante von P2PKH.

Die Ausgabebedingung basiert weiterhin auf einem Public-Key-Hash, Signatur und Public Key werden jedoch nicht mehr im ScriptSig gespeichert, sondern im Witness-Bereich der Transaktion.

P2WPKH wurde mit SegWit eingeführt und ab August 2017 im Bitcoin-Netzwerk aktiviert.

Als Beispiel dienen zwei Transaktionen: Output 0 von c178d8dacdfb989f9d4fa45828ed188cd54a0414d625c3e61e75c5e3ac15a83a (nativer P2WPKH-ScriptPubKey) und Input 0 von 1674761a2b5cb6c7ea39ef58483433e8735e732f5d5815c9ef90523a91ed34a6 (Ausgeben desselben UTXOs).

ScriptPubKey

Ein typischer P2WPKH-ScriptPubKey ist ein Witness Program Version 0:

Output 0 der Beispiel-Transaktion: nativer P2WPKH-Output mit 20-Byte Public-Key-Hash 841b80d2….

Vereinfacht bedeutet dieses Script:

Lege eine gültige Signatur und den passenden Public Key für diesen Public-Key-Hash im Witness-Bereich der Transaktion vor.

ScriptSig

Bei nativen P2WPKH-Inputs ist das ScriptSig leer:

Input 0 der Spend-Transaktion: leeres ScriptSig. Die benötigten Daten befinden sich vollständig im Witness.

Witness

Im Gegensatz zu P2PKH befindet sich die Signatur nicht mehr im ScriptSig.

Stattdessen enthält der Witness:

Input 0 der Spend-Transaktion: DER-Signatur und komprimierter Public Key im Witness-Stack.

Eigenschaften

• SegWit-Version von P2PKH
• Signatur befindet sich im Witness
• ScriptSig bleibt leer
• geringere Transaktionsgröße
• behebt Transaction Malleability
• Grundlage moderner Single-Signature-Wallets

P2PKH vs. P2WPKH

Adressen

Native P2WPKH-Adressen verwenden das Bech32-Format und beginnen mit:

bc1q

Beispielsweise:

bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kygt080

Die Adresse repräsentiert den 20 Byte langen Public-Key-Hash.

Warum wurde P2WPKH eingeführt?

P2WPKH übernimmt die Funktion von P2PKH, verschiebt jedoch Signaturen in einen separaten Witness-Bereich.

Dadurch:

• werden Transaktionen effizienter gespeichert
• sinken die Gebühren
• wird Transaction Malleability behoben
• werden Lightning und weitere Layer-2-Protokolle möglich

P2SH-P2WPKH

P2SH-P2WPKH (Pay to Script Hash Pay to Witness Public Key Hash, Zahle an den Hash eines Witness-Public-Key-Scripts) ist eine Übergangslösung zwischen P2SH und P2WPKH.

Anstatt das Witness-Programm direkt im Output zu speichern, wird es zunächst in einem P2SH-RedeemScript verpackt.

Dadurch konnten Wallets bereits SegWit verwenden, obwohl viele Dienste und Wallets native Bech32-Adressen noch nicht unterstützten.

Als Beispiel dient die SegWit-Beispieltransaktion aus Block 481824 auf der Seite Transaktionen: d09e2a5edbb6a0ac390a52a1b5292d88667f5445eb8e507441737a7bdd7157ee. Beide Inputs geben P2SH-P2WPKH-UTXOs aus.

ScriptPubKey

Der referenzierte Output ist ein gewöhnlicher P2SH-Output:

Prevout von Input 0: P2SH-ScriptPubKey mit 20-Byte Script-Hash 5ea98f34… (HASH160 des Witness-Programms).

Vereinfacht bedeutet dieses Script:

Lege ein RedeemScript vor, dessen HASH160 diesem Wert entspricht. Dieses RedeemScript verweist auf einen Public-Key-Hash, für den später ein passender Public Key und eine gültige Signatur im Witness-Bereich vorgelegt werden müssen.

ScriptSig

Das ScriptSig enthält lediglich das P2WPKH-Witness-Programm als Redeem Script:

Input 0: Redeem Script 0014 + 20-Byte Public-Key-Hash c314c21e…. Signaturen und Public Key liegen nicht im ScriptSig.

Witness

Die eigentlichen Nachweise befinden sich im Witness:

Input 0: DER-Signatur und komprimierter Public Key im Witness-Stack.

Aufbau

Eigenschaften

• kombiniert P2SH und SegWit
• ScriptSig enthält nur das Witness-Programm
• Signaturen befinden sich im Witness
• Übergangslösung für ältere Wallets
• weitgehend durch natives P2WPKH ersetzt

P2SH-P2WSH

P2SH-P2WSH (Pay to Script Hash Pay to Witness Script Hash, Zahle an den Hash eines Witness-Scripts) ist die SegWit-Variante komplexer P2SH-Scripts.

Anstatt den Hash eines RedeemScripts direkt im Output zu speichern, verweist P2SH auf ein Witness-Programm, das wiederum auf ein Witness Script verweist.

Dadurch können komplexe Scripts wie Multisig, Timelocks oder Lightning-Scripts mit den Vorteilen von SegWit kombiniert werden.

Als Beispiel dienen zwei Transaktionen aus Block 657066 und 657156: Output 0 von c57007980fabfd7c44895d8fc2c28c6ead93483b7c2bfec682ce0a3eaa4008ce und Input 0 von 55c7c71c63b87478cd30d401e7ca5344a2e159dc8d6990df695c7e0cb2f82783.

ScriptPubKey

Der Output ist zunächst ein gewöhnlicher P2SH-Output:

Output 0: P2SH-ScriptPubKey mit 20-Byte Script-Hash 257014ce… (HASH160 des Witness-Programms).

Vereinfacht bedeutet dieses Script:

Lege ein RedeemScript vor, dessen HASH160 diesem Wert entspricht. Dieses RedeemScript verweist auf den SHA256-Hash eines Witness Scripts, für das später die erforderlichen Signaturen und das vollständige Witness Script im Witness-Bereich vorgelegt werden müssen.

ScriptSig

Das ScriptSig enthält lediglich das P2WSH-Witness-Programm als Redeem Script:

Input 0: Redeem Script 0020 + 32-Byte Witness-Script-Hash 973cfd44…. Signaturen und Witness Script liegen nicht im ScriptSig.

Witness

Die eigentlichen Nachweise befinden sich im Witness:

Input 0: leeres OP_0-Element, zwei DER-Signaturen und ein 2-von-3-Multisig-Witness-Script im Witness-Stack.

Witness Script

Das Witness Script definiert die eigentliche Ausgabebedingung und wird erst beim Ausgeben vollständig im Witness-Stack veröffentlicht:

Vereinfacht bedeutet dieses Script:

Lege mindestens 2 gültige Signaturen für diese 3 Public Keys vor.

Aufbau

Die drei Ebenen bilden eine Hash-Kette:

Eigenschaften

• kombiniert P2SH und SegWit
• unterstützt komplexe Scripts
• Signaturen befinden sich im Witness
• häufig für SegWit-Multisig verwendet
• Übergangslösung vor nativen P2WSH-Adressen

P2WSH (Pay to Witness Script Hash)

P2WSH (Pay to Witness Script Hash, Zahle an den SHA256-Hash eines Witness Scripts) ermöglicht es, beliebige Bitcoin-Scripts hinter einem SHA256-Hash zu verbergen.

Anstatt das vollständige Script direkt im Output zu speichern, enthält der Output lediglich dessen SHA256-Hash.

Das eigentliche Script wird erst beim Ausgeben im Witness-Bereich veröffentlicht.

P2WSH wurde mit SegWit in BIP141 eingeführt und ist die native SegWit-Variante von P2SH.

Als Beispiel dienen zwei Transaktionen aus Block 630000: Output 1 von 46ebe264b0115a439732554b2b390b11b332b5b5692958b1754aa0ee57b64265 und Input 0 von b38a88b073743bcc84170071cff4b68dec6fb5dc0bc8ffcb3d4ca632c2c78255.

ScriptPubKey

Ein typischer nativer P2WSH-ScriptPubKey ist ein Witness Program Version 0:

Output 1 der Beispiel-Transaktion: nativer P2WSH-Output mit 32-Byte Witness-Script-Hash 65f91a53….

Vereinfacht bedeutet dieses Script:

Lege ein Witness Script vor, dessen SHA256-Hash diesem Wert entspricht, und liefere die erforderlichen Signaturen und Daten im Witness-Bereich.

ScriptSig

Bei nativen P2WSH-Inputs ist das ScriptSig leer:

Input 0 der Spend-Transaktion: leeres ScriptSig. Signaturen und Witness Script liegen vollständig im Witness.

Witness

Die eigentlichen Nachweise befinden sich im Witness:

Input 0: leeres OP_0-Element, zwei DER-Signaturen und ein 2-von-3-Multisig-Witness-Script im Witness-Stack.

Witness Script

Das Witness Script definiert die eigentliche Ausgabebedingung und wird erst beim Ausgeben vollständig im Witness-Stack veröffentlicht:

Vereinfacht bedeutet dieses Script:

Lege mindestens 2 gültige Signaturen für diese 3 Public Keys vor.

Der Output selbst enthält dagegen nur den SHA256-Hash dieses Scripts.

Aufbau

Eigenschaften

• native SegWit-Variante von P2SH
• unterstützt komplexe Scripts wie Multisig oder Lightning
• Signaturen befinden sich im Witness
• ScriptSig bleibt leer
• Bitcoin-Adressen beginnen mit bc1q

P2TR (Pay to Taproot)

P2TR (Pay to Taproot, Zahle an einen Taproot Output) wurde mit dem Taproot-Upgrade in BIP341 eingeführt.

Taproot kombiniert mehrere Bitcoin-Techniken:

• Schnorr-Signaturen
• Merkle Trees
• Script Trees
• Key Aggregation

Dadurch können viele Ausgabebedingungen effizienter und privater dargestellt werden.

Als Beispiel dient die Transaktion a7115c7267dbb4aab62b37818d431b784fe731f4d2f9fa0939a9980d581690ec aus Block 861957.

ScriptPubKey

Ein typischer nativer P2TR-ScriptPubKey ist ein Witness Program Version 1:

Output 0 dieser Transaktion: 20.000 sats an einen P2TR-Output mit 32-Byte Taproot Output Key.

Vereinfacht bedeutet dieses Script:

Lege einen gültigen Nachweis für diesen Taproot Public Key vor.

Im Gegensatz zu P2PKH oder P2WPKH enthält ein P2TR-Output keinen Hash eines Public Keys, sondern direkt einen 32-Byte Taproot Public Key.

Dieser Public Key wird abhängig von den gewünschten Ausgabebedingungen erzeugt. Er kann entweder nur auf einem Schlüssel basieren oder zusätzlich versteckte Scripts berücksichtigen, die später über den Script Path ausgegeben werden können.

Von außen ist dabei nicht erkennbar, ob hinter dem Taproot Public Key überhaupt zusätzliche Scripts hinterlegt wurden.

Zwei Ausgabepfade

Ein Taproot-Output kann auf zwei Arten ausgegeben werden:

P2TR
 
├─ Key Path Spend (Key-Pfad Ausgabe)
└─ Script Path Spend (Skript-Pfad Ausgabe)

Key Path Spend (Key-Pfad Ausgabe)

Der normale Ausgabepfad.

Der Besitzer erzeugt eine gültige Schnorr-Signatur für den Taproot Output Key.

Als Beispiel dient Input 0 der Transaktion 091d2aaadc409298fd8353a4cd94c319481a0b4623fb00872fe240448e93fcbe aus Block 861970. Er gibt den P2TR-Output 0 aus a7115c7267dbb4aab62b37818d431b784fe731f4d2f9fa0939a9980d581690ec aus.

ScriptSig

Bei Taproot Key Path Spends ist das ScriptSig leer:

Input 0: leeres ScriptSig. Der Nachweis liegt vollständig im Witness.

Witness

Der Witness enthält nur die Schnorr-Signatur:

Input 0: 64-Byte Schnorr-Signatur im Witness-Stack. Kein Script, kein Public Key und kein Control Block.

Script Path Spend (Skript-Pfad Ausgabe)

Taproot ermöglicht alternative Ausgabebedingungen neben der normalen Signaturprüfung.

Diese Bedingungen werden als Scripts in einem Merkle Tree hinterlegt und sind von außen nicht sichtbar.

Wird ein Output über den Script Path ausgegeben, veröffentlicht der Witness:

• die Signatur
• das verwendete Tapleaf Script
• den Control Block

Dadurch kann jeder Node prüfen, dass das Script zu diesem Taproot-Output gehört, ohne dass andere hinterlegte Bedingungen offengelegt werden.

Als Beispiel dient Input 0 der Transaktion 797505b104b5fb840931c115ea35d445eb1f64c9279bf23aa5bb4c3d779da0c2 aus Block 863508. Er gibt den P2TR-Output 0 aus d1c40446c65456a9b11a9dddede31ee34b8d3df83788d98f690225d2958bfe3c per Script Path aus.

ScriptSig

Bei Taproot Script Path Spends ist das ScriptSig ebenfalls leer:

Input 0: leeres ScriptSig. Signatur, Tapleaf Script und Control Block liegen im Witness.

Witness

Der Witness enthält drei Elemente:

Input 0: Schnorr-Signatur mit SIGHASH-Byte, Tapleaf Script und Control Block im Witness-Stack.

Tapleaf Script

Das veröffentlichte Tapscript definiert die Ausgabebedingung:

Input 0: Tapscript mit x-only Public Key und OP_CHECKSIG.

Die Signaturprüfung erfolgt mit Schnorr.

Vorteile von Taproot

• Kleinere Transaktionen
• Geringere Gebühren
• Schnorr-Signaturen statt ECDSA
• Mehr Privatsphäre
• Effizientere Multisig-Konstruktionen
• Versteckte alternative Ausgabebedingungen

Aufbau

OP_RETURN

OP_RETURN ist ein Opcode, der die Ausführung eines Scripts sofort beendet.

Alle nachfolgenden Bytes bleiben zwar Teil des ScriptPubKeys und werden in der Blockchain gespeichert, werden jedoch niemals ausgeführt.

Dadurch können kleine Datenmengen dauerhaft in einem Output abgelegt werden, ohne dass dieser jemals wieder ausgegeben werden kann.

Als Beispiel dient Output 2 der Transaktion 6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75 aus Block 325001.

ScriptPubKey

Ein typischer OP_RETURN-ScriptPubKey speichert einen kurzen Datenblock:

Output 2 dieser Transaktion: 0 sats, OP_RETURN mit 11-Byte-ASCII-Payload hello world.

Bedeutung

Die Script Engine liest ein Script normalerweise von links nach rechts und führt dabei Opcode für Opcode aus.

Bei OP_RETURN endet dieser Prozess sofort:

OP_RETURN → Script ungültig → Ausführung beendet

Alle nachfolgenden Bytes werden zwar gespeichert, aber niemals als Script ausgeführt.

Dadurch können hinter OP_RETURN beliebige Daten abgelegt werden, ohne dass daraus eine ausgebbare Bedingung entsteht.

ASCII-Darstellung

Die Daten hinter OP_RETURN werden als Bytes gespeichert.

Explorer und Analysewerkzeuge zeigen diese Bytes häufig zusätzlich als ASCII-Text an.

Jedes Byte der Daten wird als Hex-Wert gespeichert und kann als ASCII-Zeichen gelesen werden. Aus 68656c6c6f20776f726c64 wird so der Text hello world.

Input

Da ein OP_RETURN-Output nicht ausgegeben werden kann, existieren keine gültigen Inputs dafür.

Input
└─ nicht möglich

Typische Anwendungen

OP_RETURN wird häufig verwendet, um Daten dauerhaft in der Blockchain zu verankern:

• Dokument-Hashes
• Zeitstempel
• Digitale Zertifikate
• Asset-Protokolle
• Metadaten anderer Systeme

Die eigentlichen Daten liegen dabei meist außerhalb der Blockchain. Im OP_RETURN-Output wird lediglich ein Hash oder Verweis gespeichert.