Wenn du Bitcoin verschickst, "überweist" du nicht wirklich Geld im klassischen Sinne, du erfüllst ein kleines, in sich abgeschlossenes Rätsel. Jede Bitcoin-Ausgabe ist an eine Bedingung geknüpft, formuliert in einer eigenen, sehr einfachen Programmiersprache: dem Bitcoin-Skriptsystem. Dieser Beitrag zeigt, wie dieses System seit 2009 gewachsen ist, ohne je alte Bitcoin ungültig zu machen, bis hin zu Taproot, der bislang bedeutendsten Weiterentwicklung, die Bitcoin 2021 gleichzeitig privater und effizienter gemacht hat.
Eine Bitcoin-"Adresse" ist eigentlich ein kleines Programm
Wenn du Bitcoin an eine Adresse sendest, schreibst du im Kern eine kleine Bedingung fest, unter der dieses Geld später wieder ausgegeben werden darf, meist schlicht "wer die passende digitale Signatur zu diesem öffentlichen Schlüssel vorlegen kann". Diese Bedingung ist in Bitcoins eigener, absichtlich sehr eingeschränkter Skriptsprache formuliert: eine Aneinanderreihung einfacher Befehle (Opcodes), die beim Ausgeben der Reihe nach abgearbeitet werden. Absichtlich eingeschränkt deshalb, weil eine mächtigere, "turingvollständige" Programmiersprache (wie sie z.B. andere Blockchains verwenden) unvorhersehbare Endlosschleifen und damit ganz neue Sicherheitsrisiken mit sich bringen würde; Bitcoins Skriptsprache kann das schlicht nicht, per Konstruktion.
Der Quellcode begrenzt diese Skripte bewusst eng: Ein einzelnes Element auf dem internen Rechenstapel darf höchstens 520 Byte groß sein, und ein klassisches Skript darf höchstens 201 Rechenoperationen ausführen (MAX_SCRIPT_ELEMENT_SIZE, MAX_OPS_PER_SCRIPT in src/script/script.h). Klein, überschaubar, vorhersehbar: Das ist Absicht, nicht Einschränkung aus Mangel an Möglichkeiten.
Vier Entwicklungsstufen, ohne dass je etwas kaputtging
Der Code unterscheidet vier "Versionen" dieses Skriptsystems (enum class SigVersion in src/script/interpreter.h), die zeigen, wie Bitcoin über die Jahre gewachsen ist, ohne rückwirkend ältere, bereits ausgegebene Adressen ungültig zu machen:
- Klassische Skripte, von Anfang an dabei, inklusive der 2012 eingeführten Multisig-freundlichen P2SH-Adressen.
- SegWit (2017): trennt die Signatur technisch vom Rest der Transaktion ab, was mehrere langjährige technische Probleme löste und gleichzeitig Platz in jedem Block spart.
- Taproot, Key-Path (2021): dazu gleich mehr.
- Tapscript, Script-Path (2021): die komplexere Schwester von Taproot, ebenfalls dazu gleich mehr.
Woher P2SH kam: als "einfache" Multisig-Adressen nötig wurden
Ein kurzer Blick zurück verdeutlicht, warum Skripte überhaupt komplexer werden mussten: In den ersten Jahren war eine "Mehrfachsignatur"-Bedingung (z.B. "zwei von drei Geschäftsführern müssen unterschreiben") technisch zwar möglich, aber sperrig: Der komplette, oft recht lange Bedingungs-Text musste jedem Zahlenden vorher bekannt sein und in seine eigene, abgehende Transaktion aufgenommen werden. 2012 löste "Pay to Script Hash" (P2SH) dieses Problem elegant: Statt der vollständigen Bedingung reicht dem Absender fortan nur noch deren kompakter Hash (eine kurze, feste Zeichenfolge), die eigentliche, möglicherweise komplizierte Bedingung muss erst beim späteren Ausgeben offengelegt und erfüllt werden, nicht schon beim Empfang. Das war der erste große Schritt, komplexe Bedingungen für den Zahlenden genauso einfach aussehen zu lassen wie eine gewöhnliche Adresse, ein Gedanke, den Taproot Jahre später konsequent weiterdenkt.
Zeitschlösser: ein Lehrstück darüber, wie Bitcoin sich überhaupt verändern kann
Bevor wir zu Taproot kommen, lohnt sich ein Blick auf zwei kleine, aber wunderbar lehrreiche Befehle: OP_CHECKLOCKTIMEVERIFY (kurz CLTV, sperrt eine Ausgabe bis zu einem bestimmten Kalenderdatum oder einer Blockhöhe) und OP_CHECKSEQUENCEVERIFY (CSV, sperrt relativ zur Bestätigung, also z.B. "erst 30 Tage nach Empfang ausgebbar"). Beide sind heute unverzichtbare Bausteine für Dinge wie das Lightning-Netzwerk oder Erbschafts-/Notfall-Konstruktionen bei Bitcoin-Wallets.
Das eigentlich Interessante daran ist, wie sie eingeführt wurden: Es waren ursprünglich zwei bedeutungslose Platzhalter-Befehle (OP_NOP2 und OP_NOP3, NOP steht für "no operation", tue nichts). Per sogenanntem Soft Fork bekamen sie 2015 bzw. 2016 eine neue, echte Bedeutung zugewiesen. Im Code sieht man diesen Mechanismus noch heute wörtlich: Ist das entsprechende Aktivierungs-Flag nicht gesetzt, verhält sich der Befehl exakt wie der ursprüngliche NOP, "tue nichts". Ein Node, der (theoretisch) nie aktualisiert würde, würde also die neue Bedeutung schlicht ignorieren, statt abzustürzen oder die Transaktion abzulehnen. Genau dieser Mechanismus (alte Software bleibt kompatibel, neue Software setzt strengere Regeln durch) ist die technische Grundlage dafür, dass Bitcoin sich überhaupt weiterentwickeln kann, ohne dass sich zwangsläufig das ganze Netzwerk in einem einzigen, riskanten Schritt gleichzeitig umstellen müsste.
Taproot: eine Signatur, die alles verbergen kann
2021 kam mit Taproot (technisch BIP340 bis BIP342) die bislang größte Weiterentwicklung seit SegWit. Die Kernidee lässt sich mit einem Bild greifbar machen: Stell dir vor, eine Wohnungstür könnte auf zwei völlig unterschiedliche Arten geöffnet werden, mit dem gewöhnlichen Schlüssel, oder durch das Auffinden eines von zehn verschiedenen Ersatzverfahren, die irgendwo hinterlegt sind (Nachbar mit Zweitschlüssel, Code am Schlüsselkasten, Hausmeister, …). Von außen sieht die Tür in beiden Fällen exakt gleich aus. Genau das ermöglicht Taproot für Bitcoin-Adressen:
- Key-Path-Spend: Eine einzige, gewöhnlich aussehende digitale Signatur reicht aus. Sieht auf der Blockchain identisch aus wie jede andere einfache Bitcoin-Zahlung, völlig unabhängig davon, ob im Hintergrund komplexe Bedingungen (Mehrfachsignatur, Zeitschlösser, Notfallregeln) überhaupt möglich gewesen wären.
- Script-Path-Spend: Wird stattdessen einer der hinterlegten Alternativpfade genutzt, wird nur genau dieser eine offengelegt und gegen eine im Voraus im Adress-Setup festgeschriebene Prüfsumme verifiziert (technisch ein sogenannter Merkle-Baum, verifiziert über die Funktion
VerifyTaprootCommitmentinsrc/script/interpreter.cpp). Alle anderen theoretisch möglichen Regeln bleiben für immer unsichtbar.
Der Effekt: Eine komplexe Firmen-Multisig-Wallet mit fünf Unterzeichnern und Notfallregeln sieht auf der Blockchain (solange sie regulär genutzt wird) exakt gleich aus wie die Zahlung deiner Nachbarin von ihrem Handy. Das ist ein handfester Privatsphäre-Gewinn, weil niemand von außen ablesen kann, welche Art von Wallet hinter welcher Adresse steckt, und ein Effizienzgewinn, weil komplexe Konstruktionen nicht mehr zwangsläufig mehr Platz im Block belegen als eine einfache Zahlung.
Schnorr statt ECDSA: eine kleine Änderung mit großer Wirkung
Taproot führt außerdem einen neuen Signaturtyp ein: Schnorr-Signaturen (benannt nach dem Mathematiker Claus-Peter Schnorr) statt der bis dahin ausschließlich genutzten ECDSA-Signaturen. Der entscheidende mathematische Unterschied: Schnorr-Signaturen sind "linear": Das erlaubt es, dass mehrere Personen gemeinsam eine einzige, kombinierte Signatur erzeugen können (bekannt unter dem Namen MuSig), die von außen nicht von der Signatur einer einzelnen Person zu unterscheiden ist. Das ist exakt die mathematische Grundlage, die Key-Path-Spends bei mehreren Unterzeichnern überhaupt erst so kompakt und unauffällig macht.
In Tapscript (dem Script-Path-Zweig von Taproot) gibt es außerdem einen neuen Befehl namens OP_CHECKSIGADD, der die ältere Mehrfachsignatur-Prüfung ablöst: Statt jede Signatur einzeln gegen jeden möglichen Schlüssel zu testen (was bei vielen Beteiligten aufwendig wird), wird die Zahl der bereits erfolgreich geprüften Signaturen einfach schrittweise aufaddiert, schneller und ressourcenschonender.
Nicht jede Signatur muss alles absichern: SIGHASH-Typen
Ein weiteres, seit Satoshis Originaldesign eingebautes Detail wird selten erklärt, obwohl es einige praktische Konstruktionen erst ermöglicht: Wenn du eine Bitcoin-Transaktion signierst, kannst du festlegen, WELCHE Teile davon deine Signatur überhaupt bindend absichert. Der Standardfall, SIGHASH_ALL, sichert wie der Name sagt sämtliche Ein- und Ausgänge ab, das ist die richtige Wahl für praktisch jede gewöhnliche Zahlung. Es gibt aber Alternativen: SIGHASH_NONE signiert bewusst keinen einzigen Ausgang (jemand anders könnte diese nachträglich noch festlegen), SIGHASH_SINGLE sichert nur den Ausgang mit demselben Positions-Index wie der signierte Eingang ab, und das zusätzliche Flag SIGHASH_ANYONECANPAY sichert ausschließlich den eigenen Eingang, während beliebige weitere Personen noch eigene Eingänge zur selben Transaktion hinzufügen könnten.
Diese Flexibilität ist die technische Grundlage für Konstruktionen, bei denen mehrere voneinander unabhängige Parteien gemeinsam, aber ohne sich gegenseitig vertrauen zu müssen, eine einzige Transaktion zusammenstellen, ein Prinzip, das unter anderem hinter bestimmten Formen kollaborativer, datenschutzfreundlicher Transaktionen steckt. Taproot ergänzt hier übrigens noch eine kleine, aber sinnvolle Optimierung: einen impliziten Standardwert (SIGHASH_DEFAULT), der überhaupt kein eigenes Byte mehr benötigt und dadurch jede einzelne Taproot-Signatur minimal kleiner macht, bei Millionen täglicher Transaktionen ein durchaus spürbarer Effekt auf die insgesamt benötigte Blockkapazität.
Warum das Lightning-Netzwerk ohne Zeitschlösser gar nicht existieren könnte
Ein besonders anschauliches Anwendungsbeispiel für die weiter oben beschriebenen Zeitschloss-Befehle CLTV und CSV ist das Lightning-Netzwerk, Bitcoins bekannteste "Layer 2"-Lösung für sofortige, sehr günstige Zahlungen. Ein Lightning-Kanal zwischen zwei Personen basiert im Kern auf einer gemeinsamen Bitcoin-Adresse, deren Ausgabebedingungen genau diese Zeitschlösser nutzen: Jede der beiden Parteien kann jederzeit versuchen, den zuletzt vereinbarten Kontostand einseitig auf die eigentliche Bitcoin-Blockchain zu übertragen, aber nur nach Ablauf einer vorher vereinbarten Wartezeit. Diese Wartezeit gibt der jeweils anderen Partei die Chance, einzugreifen, falls die erste Partei betrügerisch versucht, einen bereits überholten, älteren Kontostand einzureichen. Ohne die im Code fest verankerten Zeitschloss-Befehle aus diesem Beitrag gäbe es schlicht keine verlässliche technische Grundlage, auf der ein System wie Lightning überhaupt aufbauen könnte.
Fazit: Weiterentwicklung, ohne die Vergangenheit zu gefährden
Vom bewusst einfachen klassischen Skript über SegWit bis zu Taproot zieht sich ein roter Faden: Jede Erweiterung fügte neue Möglichkeiten hinzu, ohne alte Bitcoin-Adressen ungültig zu machen oder Nutzer zu zwingen, ihr Geld umzuziehen. Taproot ist dabei bislang der eleganteste Kompromiss zwischen Privatsphäre, Effizienz und Sicherheit, ein Nebeneffekt, den man auf der Blockchain selbst kaum noch sieht, was letztlich genau der Punkt ist.
Weiter geht's mit Teil 4: Der Wartesaal vor der Blockchain, Mempool, Gebühren und Replace-by-Fee erklärt.
