Was ist die Skriptsprache von Bitcoin?

Bitcoin Script ist die Programmiersprache, die jede Transaktion im Bitcoin-Netzwerk steuert. Es handelt sich um eine einfache, stapelbasierte Sprache, die die genauen Bedingungen definiert, unter denen Bitcoins ausgegeben werden können, und jeder Full Node im Netzwerk führt sie bei jeder Validierung einer Transaktion aus. Ohne sie wäre Bitcoin lediglich ein Verzeichnis von Zahlen ohne Mechanismus zur Durchsetzung der Eigentumsverhältnisse.

Die meisten Nutzer kommen nie direkt mit der Bitcoin-Skriptsprache in Berührung. Ihre Wallets übernehmen das im Hintergrund. Doch jedes Mal, wenn Sie BTC senden oder empfangen, werden auf Tausenden von Computern gleichzeitig zwei kleine Programme ausgeführt, die prüfen, ob die Ausgabebedingungen erfüllt sind. Wenn man versteht, wie das funktioniert, wird viel darüber klar, warum Bitcoin so aufgebaut ist, wie es ist, und was es im Vergleich zu Plattformen wie Ethereum leisten kann und was nicht.

Dieser Artikel befasst sich mit der Funktionsweise von Bitcoin Script, gibt einen Überblick über die wichtigsten Transaktionstypen, die damit möglich sind, erläutert das Taproot-Upgrade, durch das die Skript-Ebene im Jahr 2021 modernisiert wurde, und berichtet über den aktuellen Stand der Debatte um den „Covenant“-Opcode im Juni 2026.

Verwalten Sie Ihre Bitcoins sicher mit der Selbstverwahrung Bitcoin.com Wallet-App.

Die wichtigsten Erkenntnisse

• Bitcoin Script ist eine im Bitcoin-Protokoll integrierte, stapelbasierte Programmiersprache, die die Bedingungen definiert, unter denen eine Bitcoin-Ausgabe ausgegeben werden kann.
• Jede Bitcoin-Transaktion enthält zwei Skripte: ein vom Empfänger festgelegtes Sperrskript (ScriptPubKey) und ein vom Absender bereitgestelltes Entsperrskript (ScriptSig). Beide müssen erfolgreich ausgeführt werden, damit eine Transaktion gültig ist.
• Bitcoin Script ist bewusst nicht Turing-vollständig. Es gibt keine Schleifen, keinen persistenten Zustand zwischen den Ausführungen und strenge Beschränkungen hinsichtlich der Skriptgröße. Dadurch wird gewährleistet, dass jedes Skript beendet wird – was ein Sicherheitsmerkmal und keine Einschränkung darstellt.
• Die Skriptsprache hat sich über fünf wichtige Formate weiterentwickelt: P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) und Taproot (P2TR), wobei jedes Format die Möglichkeiten erweitert und gleichzeitig abwärtskompatibel bleibt.
• Taproot (November 2021) führte Schnorr-Signaturen, MAST-basierte Ausgabepfade zum Schutz der Privatsphäre sowie Tapscript als aktualisierte Skriptsprache mit einem integrierten Mechanismus für reibungslosere zukünftige Upgrades ein.
• Zu den praktischen Anwendungsfällen, die auf Bitcoin Script basieren, gehören Multisignatur-Wallets, zeitgesteuerte Transaktionen, Hash Time-Locked Contracts (die Grundlage von Lightning), Treuhandkonten und Discreet Log Contracts.
• Im Gegensatz zu den Smart Contracts von Ethereum ist Bitcoin Script zustandslos: Jedes Skript läuft völlig isoliert ab, ohne Kenntnis von anderen Transaktionen. Dies ist eine bewusste architektonische Entscheidung.
• Der aktivste Bereich der Bitcoin-Script-Entwicklung im Jahr 2026 sind die Covenant-Opcodes, insbesondere OP_CTV (BIP-119) und OP_CAT (BIP-347), die es Skripten ermöglichen würden, Vorgaben dafür festzulegen, wie eine Ausgabetransaktion aussehen muss. Beide wurden im Mainnet noch nicht aktiviert.

Was ist Bitcoin Script?

Bitcoin Script ist eine stapelbasierte, zustandslose Skriptsprache, die in das Bitcoin-Protokoll integriert ist. Jede Transaktionsausgabe im Bitcoin-Netzwerk enthält ein Sperrscript (das sogenannte „ScriptPubKey“), das die Bedingungen für die Verwendung der Mittel festlegt. Wer diese Mittel ausgeben möchte, muss ein Entsperrscript (das sogenannte „ScriptSig“ oder bei SegWit- und Taproot-Transaktionen die „Witness-Daten“) vorlegen, das diese Bedingungen erfüllt.

Die Sprache lehnt sich in ihrer Struktur an Forth an, eine minimalistische, stapelbasierte Programmiersprache, die in den 1960er Jahren entwickelt wurde. Wie Forth wird Bitcoin Script von links nach rechts gelesen, arbeitet mit einer als Stack bezeichneten Datenstruktur und verwendet die umgekehrte polnische Notation (RPN), bei der die Operatoren ihren Operanden folgen, anstatt ihnen vorangestellt zu sein. Es führt jeweils eine Anweisung aus, kennt keine Schleifen und behält zwischen den Ausführungen keinen persistenten Speicher bei.

Dieser letzte Punkt ist das Erste, worauf die meisten Menschen stoßen, wenn sie sich auf Protokollebene mit Bitcoin Script beschäftigen: Die Sprache ist bewusst nicht Turing-vollständig. Eine Turing-vollständige Sprache kann bei ausreichender Zeit und ausreichenden Ressourcen jede beliebige Berechnung ausführen. Bitcoin Script kann dies aufgrund seiner Konzeption nicht, und die Gründe für diese Entscheidung sind für die Funktionsweise des Netzwerks von großer Bedeutung.

So funktioniert Bitcoin Script: Das Stack-Modell

Um zu verstehen, wie Bitcoin Script funktioniert, muss man den Stack verstehen. Ein Stack ist eine Datenstruktur, die nach dem Prinzip „Last-In, First-Out“ (LIFO) arbeitet. Stellen Sie sich einen Stapel Teller vor: Sie können nur von oben etwas hinzufügen oder entfernen. In Bitcoin Script werden Daten auf den Stack geschoben, und Opcodes (Operationscodes) bearbeiten das, was sich gerade ganz oben befindet.

Wenn ein Bitcoin-Knoten eine Transaktion validiert, führt er nacheinander zwei Skripte aus:

1. Das Entsperrskript (ScriptSig oder Witness) die von der Person bereitgestellt werden, die die Coins ausgibt. Dadurch werden Daten auf den Stack geschoben, in der Regel eine digitale Signatur und ein öffentlicher Schlüssel.
2. Das Sperrskript (ScriptPubKey) die mit der Ausgabe verbunden ist, die ausgegeben wird. Diese enthält Opcodes, die auf die Daten im Stack einwirken und prüfen, ob die Ausgabebedingungen erfüllt sind.

Wenn das Skript fehlerfrei ausgeführt wird und am Ende einen Wert ungleich Null (TRUE) auf dem Stack hinterlässt, ist die Transaktion gültig. Wenn es fehlschlägt oder den Wert FALSE hinterlässt, wird die Transaktion vom Knoten abgelehnt und gelangt niemals in einen Block.

Diese Ausführung erfolgt vollständig zustandslos. Das Skript hat keinerlei Kenntnis von früheren Transaktionen, keine Kenntnis der aktuellen Salden und kein Gedächtnis, das nach Beendigung der Skriptausführung weiterbesteht. Jedes Skript wird jedes Mal von Grund auf neu und isoliert ausgeführt.

Schritt für Schritt: Eine Standard-P2PKH-Transaktion

„Pay-to-Public-Key-Hash“ (P2PKH) ist der ursprüngliche Bitcoin-Transaktionstyp, der seit 2009 verwendet wird. P2PKH-Adressen beginnen mit „1“. So sehen ScriptPubKey und ScriptSig in der Praxis aus:

Entsperrskript (ScriptSig):

<Signatur> <öffentlicher Schlüssel>

Sperrskript (ScriptPubKey):

OP_DUP OP_HASH160 <Hash des öffentlichen Schlüssels> OP_EQUALVERIFY OP_CHECKSIG

Wenn der Knoten beide miteinander verknüpft und gemeinsam ausführt, laufen die Stapeloperationen Schritt für Schritt ab:

• Die Signatur und der öffentliche Schlüssel aus dem ScriptSig werden auf den Stack geschoben
• OP_DUP kopiert den öffentlichen Schlüssel an den Anfang des Stacks
• OP_HASH160 berechnet den Hashwert des Duplikats (SHA-256, gefolgt von RIPEMD-160) und erzeugt dabei einen 20-Byte-Hashwert
• Der Hash des öffentlichen Schlüssels aus dem Sperrskript wird auf den Stack geschoben
• OP_EQUALVERIFY überprüft, ob die beiden Hashes übereinstimmen. Ist dies nicht der Fall, wird die Ausführung abgebrochen und die Transaktion schlägt fehl.
• OP_CHECKSIG überprüft, ob die Signatur für den öffentlichen Schlüssel gültig ist

Wenn alle Schritte erfolgreich abgeschlossen sind, endet der Stapel mit TRUE und die Mittel werden freigegeben. Der gesamte Vorgang dauert nur Millisekunden und läuft auf jedem Knoten im Netzwerk identisch ab.

Bitcoin-Opcodes erklärt

Bitcoin-Opcodes sind die einzelnen Befehle, aus denen sich ein Skript zusammensetzt. Jeder Opcode besteht aus einem einzelnen Byte, sodass insgesamt 256 mögliche Opcode-Slots zur Verfügung stehen. Davon sind derzeit etwa 80 im Mainnet aktiv. Die übrigen sind entweder reserviert, deaktiviert oder dem mit Tapscript eingeführten Mechanismus zur Vorwärtskompatibilität „OP_SUCCESS“ zugewiesen.

Opcodes lassen sich in mehrere Kategorien einteilen:

• Opcodes zum Einlesen von Daten Werte wie öffentliche Schlüssel, Signaturen und Hashes auf den Stack schieben
• Arithmetische Opcodes Additions-, Subtraktions- und Vergleichsoperationen durchführen. Dabei ist zu beachten, dass Multiplikation und Division deaktiviert sind.
• Kryptografische Opcodes darunter OP_SHA256, OP_HASH160 und OP_SHA1 für die Hash-Berechnung sowie OP_CHECKSIG für die Signaturprüfung
• Opcodes zur Ablaufsteuerung Bedingte Logik aktivieren: OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Opcodes zur Stapelbearbeitung Dazu gehören OP_DUP (das oberste Element duplizieren), OP_DROP (das oberste Element entfernen) und OP_SWAP (die beiden obersten Elemente vertauschen)

Im Jahr 2010 wurden mehrere Opcodes von Satoshi Nakamoto deaktiviert, nachdem in ihren ursprünglichen Implementierungen Sicherheitslücken entdeckt worden waren. Dazu gehören OP_CAT (zwei Stapelelemente verketten), OP_MUL (multiplizieren) und OP_DIV (dividieren). Ihr Fehlen hat nachhaltige Auswirkungen darauf gehabt, was mit Bitcoin Script ausgedrückt werden kann, und einige der im Jahr 2026 am intensivsten diskutierten Vorschläge für Bitcoin-Upgrades befassen sich mit der Frage, ob einige dieser Opcodes wieder aktiviert werden sollen.

Die vollständige Opcode-Referenz einschließlich Hexadezimalwerten und Beschreibungen finden Sie unter Seite „Bitcoin-Wiki-Skript“ ist die maßgebliche Quelle.

Warum Nicht-Turing-Vollständigkeit ein Vorteil ist

Die gängige Erklärung lautet, dass Bitcoin Script keine Schleifen kennt, sodass Skripte garantiert beendet werden und das Netzwerk somit vor einer unendlichen Ausführung geschützt ist. Das ist zwar richtig, lässt den Kern der Sache jedoch außer Acht.

Das tiefergehende Argument betrifft die Angriffsfläche. Eine Turing-vollständige Sprache kann beliebige Berechnungen ausdrücken. Diese Ausdruckskraft ist zugleich der Raum, in dem sich Fehler einnisten. Ethereums Solidity hat einige der kostspieligsten Software-Sicherheitslücken der Geschichte hervorgebracht. Der DAO-Hack von 2016 nutzte eine Reentrancy-Sicherheitslücke in einem Smart Contract aus und verursachte Verluste in Höhe von rund 60 Millionen US-Dollar zu damaligen Preisen, was letztendlich zu einer umstrittenen Hard Fork des Ethereum-Netzwerks führte. Im gesamten DeFi-Ökosystem sind über mehrere Jahre hinweg Hunderte Millionen Dollar durch Angriffe auf Smart Contracts abgeflossen.

Bitcoin-Skripte machen diese Art von Angriffen strukturell unmöglich. Es ist nicht möglich, ein Bitcoin-Skript zu schreiben, das andere Skripte aufruft, so lange in einer Schleife läuft, bis sich eine Bedingung ändert, oder den Status zwischen Transaktionen speichert. Jedes Skript ist ein begrenztes, endliches und überprüfbares Programm. Die maximale Skriptgröße beträgt 10.000 Byte. Die maximale Anzahl an Nicht-Push-Opcodes pro Skript beträgt 201. Ein Validator kann vor der Ausführung des Skripts stets den Ausführungsaufwand im schlimmsten Fall berechnen.

Für ein Netzwerk mit einem Wert von Hunderten von Milliarden Dollar ist diese Vorhersehbarkeit mehr wert als die Flexibilität, auf die man verzichtet. Ethereum löst das Problem der unbegrenzten Rechenleistung durch Gaslimits, indem es den Nutzern jeden ausgeführten Opcode in Rechnung stellt und Skripte stoppt, deren Budget aufgebraucht ist. Das funktioniert zwar, bringt aber eigene Komplexitäten und Fehlerquellen mit sich. Bitcoin umgeht das Problem von Grund auf durch seine Konzeption.

Allerdings bedeutet „nicht Turing-vollständig“ nicht, dass „keine komplexe Logik möglich ist“. Bitcoin Script unterstützt Anforderungen für Zahlungen mit mehreren Beteiligten, zeitbasierte Bedingungen, die Offenlegung von Hash-Präbildern sowie Kombinationen aus all diesen Elementen. Das Lightning-Netzwerk, über das täglich Millionen von Zahlungen abgewickelt werden, basiert vollständig auf den Grundelementen von Bitcoin Script.

Skripttypen: Die Entwicklung von P2PKH zu Taproot

Die Skript-Ebene von Bitcoin hat sich seit 2009 erheblich weiterentwickelt, wobei mit jedem Upgrade ein neues Transaktionsformat eingeführt wurde, das jedoch stets abwärtskompatibel mit allen vorherigen Versionen blieb.

P2PK (Pay-to-Public-Key, 2009)

Das ursprüngliche Format, das bei den ersten Bitcoin-Transaktionen verwendet wurde, darunter auch Satoshis Zahlung an Hal Finney in Block 170. Die Gelder wurden direkt an einen vollständigen öffentlichen Schlüssel gebunden und nicht an dessen Hash. Wird heute bei neuen Transaktionen nur noch selten verwendet, da dadurch der öffentliche Schlüssel vor der Ausgabe in der Blockchain offengelegt wird, was als sicherheitsmässig schwächer gilt als das vorherige Hashen des Schlüssels.

P2PKH (Pay-to-Public-Key-Hash, 2009)

Seit mehr als einem Jahrzehnt das Standardformat. Bei P2PKH werden die Guthaben an einen Hash des öffentlichen Schlüssels statt an den Schlüssel selbst gebunden, wodurch der öffentliche Schlüssel bis zum Zeitpunkt der Ausgabe geheim bleibt, eine kürzere 20-Byte-Adresse entsteht und die Grundlage für alle Adressen gebildet wird, die mit „1“ beginnen. Laut On-Chain-Daten von Unchained (April 2026) befinden sich derzeit etwa 43 % des geschürften Bitcoin-Bestands auf P2PKH-Adressen.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

P2SH wurde am 1. April 2012 per Soft Fork eingeführt und verlagerte die Last komplexer Ausgabeskripte vom Absender auf den Empfänger. Anstatt ein vollständiges Sperrskript in die Ausgabe einzubetten, gibt P2SH eine Verpflichtung gegenüber einem 20-Byte-Hash eines „Einlöseskripts“ aus. Das vollständige Skript wird erst bei der Ausgabe der Coins offengelegt. Dadurch wurde Multisig für normale Nutzer praktikabel: Bei einer 2-von-3-Multisig-Konfiguration mussten dem Absender zum Zeitpunkt der Zahlung nicht mehr alle drei öffentlichen Schlüssel bekannt sein. P2SH-Adressen beginnen mit „3.“

Eine detaillierte Darstellung der Funktionsweise der P2SH-Validierung auf Protokollebene finden Sie unter: Leitfaden zu Transaktionen auf developer.bitcoin.org führt Schritt für Schritt durch den Mechanismus des „redeem“-Skripts.

P2WPKH und P2WSH (Native SegWit, 2017, BIP 141)

Segregated Witness, das im August 2017 bei Block 481.824 aktiviert wurde, verlagert Signaturdaten aus dem Hauptteil der Transaktion in eine separate Witness-Struktur. Witness-Daten erhalten einen Gewichtsrabatt von 75 %, wodurch SegWit-Transaktionen deutlich günstiger werden. Eine standardmäßige P2WPKH-Transaktion mit einem Eingang und zwei Ausgängen wiegt laut Angaben etwa 141 virtuelle Bytes, verglichen mit 226 vbytes bei einer entsprechenden P2PKH-Transaktion. Analyse der Bitcoin-Adresstypen durch Spark ab März 2026. Mit SegWit wurde zudem die Transaktionsverformbarkeit behoben, was eine Voraussetzung für das Lightning-Netzwerk war. Native SegWit-Adressen beginnen mit „bc1q.“

P2TR (Pay-to-Taproot, 2021, BIPs 340/341/342)

Taproot wurde im November 2021 bei Block 709.632 aktiviert und ist das bedeutendste Upgrade der Skript-Ebene von Bitcoin seit SegWit. Es führte Schnorr-Signaturen, einen neuen Output-Typ mit MAST-Unterstützung sowie Tapscript als aktualisierte Skriptsprache ein. Taproot-Adressen beginnen mit „bc1p.“

Taproot und Tapscript: Wie sich die Bitcoin-Skriptsprache im Jahr 2021 verändert hat

Taproot ist keine einzelne Änderung. Es handelt sich um drei Bitcoin Improvement Proposals, die gemeinsam entwickelt und gleichzeitig aktiviert wurden.

BIP 340: Schnorr-Signaturen

Bitcoin verwendete ursprünglich ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi entschied sich unter anderem deshalb dafür, weil Schnorr-Signaturen zu dieser Zeit patentrechtlich geschützt waren. Dieses Patent lief 2008 aus, und mit Taproot wurden Schnorr-Signaturen schließlich in das Protokoll integriert.

Schnorr-Signaturen sind mit 64 Byte kleiner als ECDSA-Signaturen, die 71 bis 73 Byte groß sind. Noch wichtiger ist, dass sie die Schlüsselaggregation über ein Schema namens MuSig2 unterstützen. Die Schlüsselaggregation ermöglicht es mehreren Unterzeichnern, ihre individuellen Schlüssel und Signaturen zu einem einzigen aggregierten Schlüssel und einer einzigen aggregierten Signatur zu kombinieren, die in der Blockchain nicht von einer gewöhnlichen Zahlung mit einer einzigen Signatur zu unterscheiden ist. Eine 2-von-3-Multisig-Wallet, die über den kooperativen Schlüsselpfad von Taproot Ausgaben tätigt, sieht in der Blockchain identisch aus wie eine Standardzahlung. Das ist ein echter Gewinn an Privatsphäre für jeden, der Bitcoin in einer komplexen Verwahrungsstruktur hält.

BIP 341: Pay-to-Taproot und MAST

P2TR führt einen neuen Ausgabetyp mit zwei Ausgabepfaden ein:

• A Schlüsselpfad Ausgabe mittels einer Schnorr-Signatur, die zum Einsatz kommt, wenn sich alle Beteiligten einig sind und den einfachsten und kostengünstigsten Weg wählen möchten
• A Skriptpfad Ausgaben über MAST (Merkelized Abstract Syntax Tree, die Taproot-Implementierung dieses Konzepts) abwickeln

MAST ermöglicht es, dass eine einzelne Ausgabe über eine Merkle-Root in einen Baum aus mehreren Ausgabeskripten eingebunden wird. Bei der Ausgabe wird in der Blockchain nur die tatsächlich verwendete Bedingung offengelegt. Alle anderen möglichen Ausgabepfade im Baum bleiben dauerhaft verborgen. Für einen Nutzer, der eine komplexe Ausgaberichtlinie konfiguriert hat – beispielsweise: „Ich kann normal ausgeben, oder zwei von drei Treuhändern können nach sechs Monaten ausgeben, oder ein Wiederherstellungsschlüssel kann nach zwei Jahren ausgeben“ –, erscheint in der Blockchain stets nur der Pfad, der tatsächlich ausgeführt wird.

Bis zum Jahr 2024 war der Anteil von Taproot an den Bitcoin-Transaktionen auf rund 42 % gestiegen, was laut Daten von Glassnode, auf die sich Spark im März 2026 berief, vor allem auf die Aktivitäten im Zusammenhang mit Ordinals und BRC-20-Inschriften zurückzuführen war. Dieser Anteil schwankte seitdem je nach Marktlage, doch die Infrastruktur ist mittlerweile bei allen großen Wallets und Börsen Standard. Die Taproot-Themenseite von Bitcoin Optech verfolgt die laufende Protokollentwicklung rund um Taproot.

BIP 342: Tapscript

Tapscript ist die aktualisierte Skriptsprache, die für „Script-Path“-Ausgaben innerhalb von Taproot verwendet wird. Sie hat die meisten Opcodes mit dem bisherigen Bitcoin-Script gemeinsam, weist jedoch einige wesentliche Änderungen auf:

• OP_CHECKMULTISIG und OP_CHECKMULTISIGVERIFY sind veraltet. Der alte Multisig-Opcode wies eine Eigenart auf, die als Workaround das Einfügen eines Dummy-Elements in den Stack erforderte. Tapscript entfernt diese Eigenart und ersetzt sie durch OP_CHECKSIGADD, das Schnorr-Signaturen nacheinander überprüft und einen Zählwert ermittelt. Schwellenwert-Multisig-Verfahren werden dadurch übersichtlicher und kostengünstiger in der Ausführung.
• Die Beschränkungen hinsichtlich der Skriptgröße pro MAST-Blatt wurden aufgehoben. Einzelne Skripte innerhalb eines Taproot-Zweigs können beliebig groß sein.
• OP_SUCCESS-Opcodes stellen die zukunftsweisendste Neuerung dar. Im herkömmlichen Script führt das Auftreten eines undefinierten Opcodes zum Fehlschlagen des Skripts. In Tapscript führen Opcodes im OP_SUCCESS-Bereich dazu, dass das Skript bedingungslos erfolgreich ist. Zukünftige Soft Forks können diesen Opcodes ein konkretes Verhalten zuweisen, indem sie Einschränkungen hinsichtlich der Bedingungen für ihren Erfolg hinzufügen, ohne dass eine neue Skriptversion oder ein vollständiger Neubereitstellungszyklus im gesamten Ökosystem erforderlich ist. Neue Funktionen lassen sich nun sauberer in die Skript-Ebene von Bitcoin integrieren als jemals zuvor in der Geschichte des Protokolls.

Miniscript

Neben Tapscript gewinnt ein verwandtes Projekt namens Miniscript für Entwickler zunehmend an Bedeutung. Miniscript ist eine strukturierte Methode zum Schreiben einer Teilmenge von Bitcoin Script, die analysierbar, kombinierbar und generisch signierbar ist. Während rohes Script eine manuelle Erstellung erfordert und schwer zu prüfen ist, lassen sich Miniscript-Skripte automatisch auf Korrektheit überprüfen und zu größeren Richtlinien kombinieren. Es erweitert zwar nicht die Möglichkeiten von Script, macht dessen bestehende Funktionen jedoch für Entwickler, die Wallets und Verwahrungstools erstellen, deutlich zugänglicher.

Was Bitcoin Script ermöglicht: Anwendungsfälle aus der Praxis

Die folgenden Transaktionsarten sind derzeit im Bitcoin-Mainnet aktiv und basieren alle auf Bitcoin-Script-Primitiven:

Multisignatur-Wallets (Multisig-Wallets) erfordern M-von-N-Privatschlüssel, um eine Ausgabe zu autorisieren. Die Finanzabteilung eines Unternehmens könnte für jede Auszahlung 3 von 5 Genehmigungen verlangen. Ein Ehepaar könnte für gemeinsame Ersparnisse 2 von 2 verwenden. Dank Taproot und der Schnorr-Schlüsselaggregation sind kooperative Multisig-Ausgaben auf der Blockchain nun nicht mehr von Standardtransaktionen mit einer einzigen Signatur zu unterscheiden.

Zeitgebundene Transaktionen Verwenden Sie OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, kurz CLTV) und OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, kurz CSV), um zu verhindern, dass Gelder vor Erreichen einer bestimmten Blockhöhe oder nach Ablauf einer bestimmten Zeit transferiert werden. Zu den Anwendungsbereichen gehören die Nachlassplanung, Zeitpläne für die Unverfallbarkeit von Mitarbeiter-Token, Zwangssparmechanismen sowie Straftransaktionen, die innerhalb von Lightning-Network-Kanälen verwendet werden.

Hash-Time-Locked-Verträge (HTLCs) Kombinieren Sie eine Anforderung bezüglich des Urbilds eines Hashs mit einer zeitgesteuerten Sperre. Die Auszahlungsbedingung funktioniert wie folgt: Das Urbild dieses Hashs muss vor Erreichen dieser Blockhöhe offengelegt werden, andernfalls fließen die Gelder an den Absender zurück. HTLCs sind die zentrale Grundkomponente des Lightning-Netzwerks und ermöglichen eine vertrauenslose Zahlungsabwicklung über Kanalketten hinweg zwischen Parteien, die keine direkte Beziehung zueinander haben.

Treuhandkonto Bei diesen Vereinbarungen werden Gelder in einem P2SH- oder Taproot-Skript gesperrt, wobei vor der Freigabe die Zustimmung mehrerer Parteien erforderlich ist; in der Regel verfügt ein unabhängiger Schlichter über einen Schlüssel zur Entscheidung bei Stimmengleichheit.

Diskrete Protokollverträge (DLCs) Verwendung von Oracle-basierten Schnorr-Adapter-Signaturen, um Finanzkontrakte zu ermöglichen, die anhand von Daten aus der realen Welt wie Kursdaten oder Ereignisausfällen abgewickelt werden, ohne dass das Oracle Gelder verwahren muss. DLCs sind im Bitcoin-Mainnet live und werden für mit Bitcoin abgewickelte Options- und Terminprodukte verwendet.

Bitcoin-Skript vs. Ethereum-Smart Contracts

Sowohl das Bitcoin-Skript als auch Solidity von Ethereum legen Bedingungen fest, unter denen Gelder transferiert werden können, doch sie stehen für grundlegend unterschiedliche architektonische Entscheidungen. Es lohnt sich, diesen direkten Vergleich anzustellen, da die Unterschiede viel über die Kompromisse aussagen, die jedes Netzwerk eingegangen ist.

Die grundlegende Unterscheidung liegt in der Zustandsfähigkeit. Ethereum-Verträge speichern und ändern Daten, die über Transaktionen hinweg bestehen bleiben, wodurch Kreditprotokolle, dezentrale Börsen, On-Chain-Governance und Token-Standards ermöglicht werden. Bitcoin Script verfügt über keine entsprechende Funktion. Jedes Skript läuft isoliert ab, ohne Kenntnis von anderen Transaktionen.

Dies ist eine bewusste architektonische Entscheidung und keine Lücke, die es zu schließen gilt. Die Skript-Ebene von Bitcoin wurde für eine ganz bestimmte Aufgabe entwickelt: die Bedingungen für die Ausgabe von Bitcoin vorhersehbar, sicher und in großem Maßstab durchzusetzen. Für diese Aufgabe ist die Zustandslosigkeit eine Stärke. Die Angriffsfläche ist kleiner, die Ausführung ist über Millionen unabhängiger Validatoren hinweg deterministisch, und es gibt keine Kategorie von Smart-Contract-Exploits auf Protokollebene, da es auf Protokollebene keine zustandsbehafteten Verträge gibt.

Projekte, die zusätzlich zu Bitcoin mehr Programmierbarkeit anstreben, bauen diese in Schichten auf. Das Lightning Network wickelt Zahlungen ab. DLC-Protokolle dienen der Abwicklung von Finanzkontrakten, die auf externe Daten Bezug nehmen. Layer-2-Systeme wie Ark und das Liquid Network sind auf unterschiedliche Skalierbarkeitsanforderungen ausgerichtet. All dies erfordert keine Änderung des Skriptmodells der Basisebene.

Die Debatte um „The Covenant“: Was könnte sich im Bitcoin-Script ändern?

Die Weiterentwicklung von Bitcoin Script verlief stets langsam und konservativ. Der derzeit aktivste Entwicklungsbereich sind die sogenannten „Covenant-Opcodes“ – Vorschläge, die es einem Skript ermöglichen würden, nicht nur festzulegen, wer einen Output ausgeben darf, sondern auch, wie die daraus resultierende Transaktion aussehen muss. Dies stellt eine bedeutende Erweiterung der Ausdrucksmöglichkeiten von Script dar.

Die führenden Vorschläge im Juni 2026 sind:

• OP_CTV (BIP-119, CheckTemplateVerify), verfasst von Jeremy Rubin, fügt einen einzigen Opcode hinzu, der ein UTXO an eine bestimmte, vorab festgelegte Ausgabevorlage bindet, einschließlich der Transaktionsversion, der Locktime, der Anzahl der Eingaben, der Sequenzen, der Anzahl der Ausgänge und der Ausgänge. Er ist von seiner Konzeption her nicht-rekursiv, gilt als der konservativste der großen Vorschläge und zielt in erster Linie auf Tresore, Staukontrolle und bestimmte Verbesserungen des Lightning-Netzwerks ab. Seit April 2026 liegen für OP_CTV konkrete Einsatzparameter auf dem Tisch, die ein „Speedy Trial“-Signalisierungsfenster festlegen, doch der für die Aktivierung erforderliche breite Konsens der Community wurde laut Analyse der Kreditauflagen von BlockEden für April 2026.
• OP_CAT (BIP-347), vorgeschlagen von Ethan Heilman und Armin Sabouri, würde einen Opcode wieder aktivieren, den Satoshi im Jahr 2010 deaktiviert hatte. OP_CAT verkettet zwei Stapelelemente – was sich zwar einfach beschreiben lässt, aber weitreichende Auswirkungen hat. In Kombination mit Schnorr-Signaturen ermöglicht es eine „Covenant“-ähnliche Transaktionsintrospektion. Im Bitcoin-Signet-Testnetzwerk hatte OP_CAT laut der On-Chain-Analyse von sCrypt aus dem späten Jahr 2024 deutlich mehr Entwicklertransaktionen generiert als APO oder CTV. OP_CAT ist bereits im Liquid Network und bei Fractal Bitcoin aktiv, ohne dass ihm Exploits zugeschrieben wurden. BIP-347 verfügt über eine offizielle Vorschlagsnummer und wird aktiv erforscht, doch die Aktivierung im Mainnet erfordert einen Konsens der Community, der bislang noch nicht besteht.
• LNHANCE kombiniert OP_CTV mit OP_CHECKSIGFROMSTACK (CSFS) und OP_INTERNALKEY und zielt dabei auf spezifische Verbesserungen beim Aufbau von Lightning-Network-Kanälen ab, darunter die nicht-interaktive Eröffnung von Kanälen und eine effizientere Verwaltung von Kanälen mit mehreren Teilnehmern.

Bis Juni 2026 wurde keine dieser Funktionen im Bitcoin-Mainnet aktiviert. Die technischen Meinungsverschiedenheiten zwischen den Beteiligten sind größtenteils lösbar. Das schwierigere Problem ist die Mechanik der Aktivierung. Der Soft-Fork-Prozess von Bitcoin erfordert einen breiten Konsens, und die Debatte um die „Covenants“ ist nach wie vor von Spannungen geprägt, die aus früheren umstrittenen Upgrades herrühren. Aus der Debatte geht klar hervor, dass die Skriptsprache von Bitcoin innerhalb ihres konservativen Rahmens erheblichen Spielraum für Weiterentwicklung bietet. Die Frage, an der derzeit gearbeitet wird, betrifft die Reihenfolge der Schritte und die Einigung innerhalb der Community – nicht, ob die Skriptsprache eine Zukunft hat.

Fazit

Bitcoin Script ist die unsichtbare Infrastruktur, die jeder Transaktion im Netzwerk zugrunde liegt. Die meisten Nutzer kommen nie direkt damit in Berührung. Wallets erstellen gültige Skripte, signieren sie und senden sie, ohne dabei jemals die technischen Details preiszugeben. Doch jede Zahlung, jeder Lightning-Kanal, jeder zeitgesteuerte Plan und jeder Multisig-Tresor läuft über dieselbe stapelbasierte Bitcoin-Skriptsprache, die 2009 mit dem Protokoll eingeführt wurde.

Die Skript-Ebene hat sich seitdem erheblich weiterentwickelt: P2SH hat komplexe Auszahlungen praktikabel gemacht, SegWit hat die Gebühren gesenkt und Lightning ermöglicht, und Taproot hat Schnorr-Signaturen, MAST-basierten Datenschutz sowie das zukunftsfähige Opcode-Design von Tapscript eingeführt. Die derzeit intensiv diskutierten „Covenant“-Vorschläge stellen das nächste potenzielle Kapitel dar. Ob und wann diese in Kraft treten, ist Mitte 2026 noch völlig offen.

Um Bitcoin Script zu verstehen, muss man kein Entwickler sein. Man muss jedoch erkennen, dass der Konservativismus von Bitcoin, die bewussten Einschränkungen, der langsame Rhythmus der Upgrades und die fehlende Turing-Vollständigkeit keine Mängel darstellen. Die Eigenschaften, die Bitcoin Script vorhersehbar machen, sind genau dieselben, die die Konsensschicht seit sechzehn Jahren sauber gehalten haben.