Manchmal sorgen ein paar Zeilen Programmcode für grosse Diskussionen. Im Oktober 2023 schlug ein Vorschlag hohe Wellen in der Bitcoin-Szene: OP_CAT, ein einfacher Befehl, der zwei Datenstücke aneinanderhängt. So schlicht die Funktion ist, so gross könnten ihre Auswirkungen sein. Was dahintersteckt, warum der Befehl einst abgeschaltet wurde und was er heute ermöglichen könnte, erkläre ich hier.
Was ist OP_CAT?
OP_CAT ist ein vorgeschlagener Befehl für Bitcoin Script, die einfache Programmiersprache, mit der Bitcoin-Überweisungen abgesichert werden. «CAT» steht für «concatenate», auf Deutsch verketten. Der Befehl nimmt zwei Datenstücke und fügt sie zu einem zusammen – etwa so, wie man aus «Bit» und «coin» das Wort «Bitcoin» bildet.
Der Vorschlag wurde 2023 als Bitcoin Improvement Proposal eingereicht und hat inzwischen die Nummer BIP 347. Die eigentliche Änderung am Programmcode umfasst nur rund ein Dutzend Zeilen. Gerade diese Schlichtheit macht ihn für viele attraktiv.
Kurz zu Bitcoin Script
Jeder Betrag in der Blockchain ist mit einem kleinen Skript gesperrt, das festlegt, wer ihn wieder ausgeben darf. Meist prüft dieses Skript einfach eine digitale Unterschrift: Wer den passenden privaten Schlüssel besitzt, darf ausgeben. Ein Skript kann aber verschiedene Befehle kombinieren und so auch andere Bedingungen ausdrücken, etwa eine Zeitsperre oder mehrere Unterschriften. Welche Möglichkeiten Bitcoin Script bietet, hängt davon ab, welche Befehle zur Verfügung stehen. Mehr dazu in Bitcoin-Adressen: Wo sind die Unterschiede?
Ein Beispiel: Ein gewöhnliches Skript für eine ältere Bitcoin-Adresse besteht aus fünf Befehlen. Es verdoppelt den mitgelieferten öffentlichen Schlüssel (OP_DUP), berechnet dessen Hash (OP_HASH160), vergleicht ihn mit dem Hash in der Adresse (OP_EQUALVERIFY) und prüft schliesslich die Unterschrift (OP_CHECKSIG). Jeder dieser Befehle ist ein «Opcode» – ein Baustein der Sprache. OP_CAT wäre ein weiterer solcher Baustein.
Die Geschichte: einst da, dann abgeschaltet
OP_CAT ist kein neuer Gedanke. In den allerersten Versionen von Bitcoin war der Befehl bereits enthalten. Satoshi Nakamoto befürchtete jedoch, die Skriptsprache könnte zu mächtig werden und unvorhergesehene Probleme verursachen. 2010 schaltete er OP_CAT und einige andere Befehle aus Sicherheitsgründen stillschweigend ab.
Hintergrund war eine Reihe von Fehlern, die 2010 entdeckt wurden. Unter anderem liess sich mit einem bestimmten Skript jede beliebige Überweisung ausgeben, und eine andere Schwachstelle erlaubte es, auf einen Schlag über 184 Milliarden Bitcoin zu erzeugen. Beide Fehler wurden innert Stunden behoben. Satoshi entschied sich danach, vorsichtshalber eine ganze Reihe von Befehlen zu deaktivieren, deren Folgen schwer abzuschätzen waren – darunter OP_CAT, aber auch Befehle für Multiplikation und Division.
Die grösste Sorge: Wer Datenstücke immer wieder mit sich selbst verkettet, verdoppelt ihre Grösse bei jedem Schritt. Nach wenigen Dutzend Schritten wären die Daten so riesig, dass sie den Speicher jedes Knotens sprengen würden. Ein Angreifer hätte so mit einer einzigen Überweisung das ganze Netzwerk lahmlegen können.
Warum diese Sorge heute nicht mehr gilt
Seit damals ist die Grösse der Datenstücke in Bitcoin Script ohnehin begrenzt, auf 520 Bytes. Der neue Vorschlag sieht vor, dass OP_CAT nur in der mit Taproot eingeführten Skriptsprache Tapscript verfügbar ist und das Ergebnis diese Grenze nicht überschreiten darf. Wird sie überschritten, ist das ganze Skript ungültig. Der Befehl schlägt ausserdem fehl, wenn weniger als zwei Datenstücke vorhanden sind. Die einstige Gefahr eines explodierenden Speicherbedarfs ist damit gebannt.
Wie OP_CAT eingeführt werden könnte
Mit dem Upgrade Taproot wurde 2021 ein cleverer Mechanismus eingeführt: In der neuen Skriptsprache sind bestimmte, noch unbenutzte Befehlsnummern reserviert. Für ältere Software bedeutet ein solcher Befehl einfach «gültig». Erhält einer dieser Platzhalter eine neue Bedeutung mit strengeren Regeln, ist das eine Verschärfung – also eine Soft Fork, bei der Knoten mit alter Software nichts falsch machen. OP_CAT würde genau einen dieser Platzhalter belegen.
Was OP_CAT ermöglichen könnte
So einfach der Befehl ist, so vielfältig sind die Ideen dafür:
- Neue Signaturverfahren: zum Beispiel Lamport-Signaturen, die als widerstandsfähig gegen künftige Quantencomputer gelten.
- Tresore (Vaults): Bitcoin, die bei einem Diebstahl nicht sofort weg sind. Eine Auszahlung kann erst nach einer Wartezeit erfolgen, in der der rechtmässige Besitzer sie mit einem Notfallschlüssel stoppen kann. Stiehlt jemand deinen Schlüssel und versucht abzuheben, siehst du das, brichst den Vorgang ab und leitest die Bitcoin auf eine sichere Notfall-Adresse um.
- Covenants: Bedingungen, die festlegen, wohin ein Betrag später fliessen darf – nicht nur, wer ihn ausgeben darf. Darauf bauen viele weitere Ideen auf.
- Skalierung: Konzepte wie «Ark», die viele Nutzerinnen und Nutzer gemeinsam eine einzige Überweisung teilen lassen und auf Covenants angewiesen sind.
- BitVM: ein 2023 vorgestelltes Verfahren, mit dem sich beliebige Berechnungen über Bitcoin prüfen lassen. Mit OP_CAT würde es einfacher und effizienter.
- Sichere unbestätigte Zahlungen: Nach Aussage eines Ark-Entwicklers liesse sich mit OP_CAT verhindern, dass unbestätigte Zahlungen doppelt ausgegeben werden. Zahlungen könnten so sofort als sicher gelten, ähnlich wie im Lightning-Netzwerk.
Der bekannte Bitcoin-Entwickler Andrew Poelstra brachte es so auf den Punkt: Die meisten Ideen, die man mit Bitcoin Script umsetzen möchte, würden mit OP_CAT funktionieren – und für den Rest bräuchte es nicht viel mehr.
Was Covenants genau sind
Heute legt ein Bitcoin-Skript nur fest, wer einen Betrag ausgeben darf – meist der Besitzer eines bestimmten Schlüssels. Was er danach damit macht, ist ihm überlassen. Ein Covenant geht weiter: Er kann bestimmen, wohin der Betrag fliessen darf. Ein Beispiel ist der oben beschriebene Tresor: Die Bitcoin dürfen zunächst nur an eine Zwischenadresse mit Wartezeit fliessen, nicht direkt an irgendeine Adresse. Mit OP_CAT lassen sich solche Bedingungen bauen, indem ein Skript die geplante Überweisung zusammensetzt und mit einer Unterschrift prüft. Das ist eine der Fähigkeiten, die Entwicklerinnen und Entwickler seit Jahren für Bitcoin diskutieren.
Risiken und Einwände
Jede neue Funktion dieser Art erfordert eine Soft Fork, also eine Änderung der Konsensregeln. Das will gut geplant sein. Am Vorschlag gelobt wird, dass er klein ist und sich auf eine einzige Änderung beschränkt.
Aber gerade ein so vielseitiger Befehl birgt auch Gefahren: Je mehr Möglichkeiten er eröffnet, desto eher übersieht man Risiken. Am umstrittensten sind die Covenants. Kritiker befürchten etwa, dass Bitcoin damit dauerhaft an Bedingungen geknüpft werden könnten, die sich über alle künftigen Besitzer fortpflanzen – sogenannte rekursive Covenants. Befürworter halten dem entgegen, dass OP_CAT zusammen mit den Signaturen von Taproot allein solche Einschränkungen nicht praktikabel durchsetzen kann. Ähnliche Debatten gab es schon um andere Vorschläge wie BIP 119 (CTV).
Ein Argument der Befürworter: Auf der Sidechain Liquid und bei einigen anderen Kryptowährungen gibt es OP_CAT seit Jahren, ohne dass es zu Sicherheitsproblemen gekommen wäre.
Fazit
Die Entwicklung von Bitcoin ist bewusst langsam. Keine Änderung geschieht über Nacht, und am Ende entscheiden die Nutzerinnen und Nutzer, welche Software sie laufen lassen. Bei OP_CAT scheint das Verhältnis von Aufwand und Nutzen vielversprechend, offensichtliche Nachteile sind bisher keine aufgetaucht. Aktiviert wurde OP_CAT bisher nicht; die Diskussion darüber und über ähnliche Vorschläge läuft weiter. Gut möglich, dass sie noch neue Vor- oder Nachteile ans Licht bringt.