Derzeit gibt es einen neuen Vorschlag für ein Bitcoin Improvement Proposal (BIP) unter dem Namen "OP_CAT", das in den vergangenen Tagen vermehrt auf Plattformen wie 𝕏, aber auch innerhalb der Entwickler-Community diskutiert wurde. Die Änderung selbst besteht gerade einmal aus 13 Zeilen Code, und auch die Funktionsweise ist auf den ersten Blick ähnlich überschaubar.
Was es mit diesem neuen, aber gleichzeitig alten Vorschlag auf sich hat, welche Möglichkeiten für Bitcoin geboten werden und ob es nicht doch noch irgendwo einen Haken gibt, klären wir in diesem Beitrag!
OP_CAT
Kaum ein anderer Änderungsvorschlag für Bitcoin ist auf rein technischer Ebene so einfach zu erklären wie OP_CAT. Zwar geht es bei diesem Opcode leider nicht um Katzen – auch wenn sich das 😺-Emoji schnell als Markenzeichen etabliert hat – sondern um Konkatenation (en. concatenation), also das Verknüpfen oder Aneinanderhängen von zwei Eingabewerten zu einem Ausgabewert.
Wir erinnern uns: Sämtliche Bitcoin-Outputs werden mit einem kleinen Mini-Programm, das mithilfe der Bitcoin-Script Sprache erstellt wurde, abgesichert. Ein solches Programm besteht klassischerweise aus der Überprüfung, ob eine digitale Signatur gültig ist, kann aber auch komplexere Kombinationen aus diversen Befehlen (Opcodes) nutzen, um andere Anwendungsfälle abzudecken.
OP_CAT ist also genau ein solcher Opcode, mit der ziemlich simplen, aber umso mächtigeren Funktion, zwei Werte aneinanderzuhängen. Liegen auf dem Stack beispielsweise die beiden Werte "Block" und "trainer", nimmt OP_CAT diese beiden Eingaben in die Hand und hängt sie einfach aneinander, sodass nun das Ergebnis "Blocktrainer" gespeichert wird. Zunächst wirkt diese Funktionsweise fast schon zu langweilig, als dass irgendwelche spannenden Funktionen damit ermöglicht werden könnten, doch der Schein trügt...
Ein alter Bekannter
Tatsächlich ist der CAT-Opcode nichts Neues, ganz im Gegenteil, er war schon einmal in einer sehr frühen Version von Bitcoin ein Teil des offiziellen Befehlssatzes von Bitcoin-Script. Satoshi Nakamoto hatte damals aber berechtigte Sorgen, dass die kleine Programmiersprache, die er sich mehr oder weniger zusammengebastelt hat, am Ende zu mächtig werden und für Probleme sorgen könnte. Deshalb fiel unter anderem die Entscheidung, OP_CAT sicherheitshalber still und heimlich zu deaktivieren.
Den aktuellen Vorschlag deshalb vehement abzulehnen, da sich schließlich der Bitcoin-Erfinder selbst dagegen entschieden hatte, ist allerdings ein etwas zu voreiliges Fazit. Einer der Hauptgründe für die damalige Deaktivierung war die potenzielle Möglichkeit, durch geschickte und wiederholte Anwendung für ein exponentiell wachsendes Speicherproblem zu sorgen, da sich einzelne Elemente auf dem Stack immer weiter aufblähen könnten.
Mittlerweile, genau genommen seit der Deaktivierung damals, ist allerdings eine maximale Größe von 512 Byte für Stackelemente vorgesehen und diese wird auch heute innerhalb von Tapscript, also Bitcoin-Script unter dem Taproot-Update, aktiv durchgesetzt. Das Problem von damals findet hier also keine wirkliche Anwendung, da ein Script, das Elemente über diesem Limit erzeugen möchte, einfach ungültig wäre.
OP_CAT schlägt fehl, wenn weniger als zwei Werte auf dem Stack liegen oder wenn der konkatenierte Wert eine kombinierte Größe von mehr als die für Stackelemente maximalen 520 Byte hätte.
Aus dem BIP-Entwurf
Die Möglichkeiten
Es stellt sich heraus, dass das Aneinanderhängen von zwei Eingaben eine derart fundamentale Operation ist, dass man fast schon nicht mehr hinterherkommt, wenn damit angefangen wird, potenzielle Anwendungsfälle für Bitcoin aufzuzählen. Der BIP-Entwurf nennt dabei beispielsweise neue Möglichkeiten für Signaturen, darunter sogar Quantensichere Lamport-Signaturen oder auch Bitcoin-Vaults, um einen zusätzlichen Schutz gegen die Kompromittierung der eigenen Bitcoin-Wallet einzubauen.
Lese-Tipp: Wie funktionieren Bitcoin Vaults?
Mithilfe von OP_CAT können prinzipiell sogenannte Covenants umgesetzt werden, also vorab festgelegte Bedingungen, an wen ein bestimmter Bitcoin-Output ausgegeben werden kann. Damit wiederum eröffnen sich die Tore für neue Skalierungsmethoden wie Ark und viele weitere Ansätze, die eben von Covenants abhängig sind. Auch das erst kürzlich vorgestellte Konzept von BitVM, um beliebige Berechnungen auf Bitcoin zu verifizieren, würde mit OP_CAT um ein Vielfaches einfacher umgesetzt und effizienter werden können.
Lese-Tipp: BitVM: Beliebige Smart Contracts direkt auf Bitcoin umsetzen?
Eine weitere sehr interessante Möglichkeit ist es, die Gültigkeit einer Transaktion nicht nur an eine gültige Signatur, sondern an eine bestimmte gültige Signatur zu knüpfen und damit einen effektiven Schutz für unbestätigte Transaktionen zu ermöglichen. Hiervon würde beispielsweise auch das bereits erwähnte Konzept von Ark profitieren...
Ich persönlich freue mich besonders auf die Prävention von Double-Spend [bei unbestätigten Transaktionen]. Das würde dazu führen, dass Ark-Zahlungen sofort abgewickelt werden, ähnlich wie auch bei Lightning.
Ark-Entwickler Burak auf 𝕏
Bevor wir uns aber zu sehr im Schlaraffenland der Anwendungsmöglichkeiten verirren, können wir uns einfach auf das Fazit einigen, dass es OP_CAT sicherlich nicht an potenziellen Möglichkeiten mangeln wird. Neben den bereits bekannten Funktionen könnten sich außerdem auch viele neue Ideen und Ansätze entwickeln, die bisher frühzeitig durch fehlende Rahmenbedingungen im Keim erstickt wurden.
Beim Brainstorming über Möglichkeiten, coole Dinge mit Bitcoin-Script zu machen, würde ich sagen, dass es in etwa 90% der Fälle damit endet, dass wir es tun könnten, wenn wir doch nur OP_CAT hätten. Und die verbleibenden 10% benötigen normalerweise nicht viel mehr.
Andrew Poelstra in einer Antwort auf den Entwurf
Wo ist der Haken?
Eigentlich klingt das alles viel zu vielversprechend, um wahr zu sein und man könnte meinen, dass es doch sicherlich einen offensichtlichen Nachteil geben muss. Klar, natürlich ist für eine tatsächliche Wiedereinführung von OP_CAT eine Soft Fork, also eine Veränderung der Konsensregeln von Bitcoin notwendig, was grundsätzlich immer sorgfältig geplant und abgewogen werden sollte – zusammen mit einer extra Prise Vorsicht.
Doch der aktuelle BIP-Vorschlag ist nun mal recht simpel, überschaubar und ist, zumindest auf der grundlegenden Ebene, für jeden verständlich. Eine solche Soft Fork ist außerdem begrüßenswert, weil der Fokus klar auf einer einzelnen Anpassung liegt und man nicht zig verschiedene Konzepte gemeinsam in einen Topf wirft. Kombiniert mit den angesprochenen festen Limitierungen, fallen auch die offensichtlichen Sorgen weg, die damals noch zur Deaktivierung geführt hatten.
Auch wenn OP_CAT für sich gesehen extrem simpel ist, sollte man die Mächtigkeit der Funktion aber nicht unterschätzen. Wenn eine winzige Funktion eine derartige Flut an Möglichkeiten eröffnet, kann man schnell den Überblick über potenzielle Risiken verlieren und eventuell sogar kritische Aspekte komplett übersehen. Vor allem die kontrovers diskutierten Covenants dürften den ein oder anderen skeptisch werden lassen. In der Vergangenheit waren diese schließlich schon häufiger im Gespräch, beispielsweise im Zuge von BIP-119.
Die Angst vor sogenannten rekursiven Covenants, also der fortlaufenden Festlegung und effektiven Sperrung, wie bestimmte Bitcoin ausgegeben werden dürfen, ist allerdings unbegründet. So wie es aktuell aussieht, ist OP_CAT in Kombination mit Taproots Schnorr-Signaturen nicht in der Lage, eine solch komplexe Beschränkung umzusetzen.
Ferner ist OP_CAT bereits seit Längerem auch Teil einiger Altcoins sowie der Liquid-Sidechain, ohne dass diesbezüglich Sicherheitslücken aufgetreten sind.
Fazit
Auch wenn es für engagierte Entwickler sicherlich manchmal nervig sein kann, ist das Schöne (und wichtige) an der Entwicklung von Bitcoin das kontrolliert langsame Tempo. Keine Änderung, egal ob OP_CAT oder doch etwas völlig anderes, kann und wird von heute auf morgen umgesetzt werden. Selbst wenn, müssen am Ende des Tages immer noch die Nutzer selbst entscheiden, ob sie ein bestimmtes Update benutzen oder gar unterstützen wollen.
Das Verhältnis zwischen Aufwand und möglichen Anwendungsfällen ist bei OP_CAT jedenfalls sehr vielversprechend, während es aktuell, von den genannten Grundsätzen abgesehen, eigentlich keine offensichtlichen Nachteile gibt. Man darf bei all dem aber nicht vergessen, dass wir aktuell noch bei einem Entwurf für einen Vorschlag stehen und eine tatsächliche Aktivierung im Bitcoin-Netzwerk in jedem Fall noch relativ weit entfernt ist.
Es bleibt also noch viel Zeit, über OP_CAT zu philosophieren und dabei vielleicht doch noch den ein oder anderen Nachteil oder gar positiven Nebeneffekt zu entdecken.