Wie steht es um CTV und CSFS?

Zwei der derzeit am heißesten diskutierten Bitcoin-Protokollerweiterungen OP_CHECKTEMPLATEVERIFY (CTV) und OP_CHECKSIGFROMSTACK (CSFS) versprechen nicht weniger als einen deutlichen Entwicklungsschub für zahlreiche Bitcoin-Anwendungen: vom Lightning-Netzwerk über Vaults bis hin zu BitVM und zukünftigen Protokollen wie Ark oder DLCs. 

Doch trotz ausgereifter Konzepte, realer Anwendungsfälle und zahlreicher Unterstützer kommen die Vorschläge in der Bitcoin-Core-Entwicklung kaum voran. Ein kürzlich veröffentlichter, offen formulierter Unterstützungsbrief von mehr als 40 Entwicklern und Bitcoin-Unternehmern hat die Debatte erneut angeheizt – und zugleich wieder einmal deutlich gemacht, wie gespalten die Community in der Frage ist, wie solche Upgrades priorisiert und umgesetzt werden sollten.

OP_CHECKTEMPLATEVERIFY und OP_CHECKSIGFROMSTACK sind Bitcoin-Befehle („Opcodes“), die zusätzliche Möglichkeiten für intelligente, sichere und flexible Bitcoin-Transaktionen eröffnen würden.

CTV erlaubt es, sehr genau festzulegen, wie eine bestimmte Bitcoin-Ausgabe in Zukunft ausgegeben werden darf – man spricht hierbei von sogenannten „Covenants“. Das kann helfen, neue Funktionen wie Vaults, Zahlungskanäle oder skalierbare Multi-Parteien-Wallets effizienter umzusetzen.

CSFS hingegen ermöglicht es, eine Signatur nicht nur auf eine Bitcoin-Transaktion, sondern auf beliebige Nachrichten zu prüfen. Dadurch lassen sich neue Anwendungsfälle realisieren, etwa bezahlte Signaturen, vertrauenswürdige Orakel, Delegationsmechanismen oder detaillierte Bedingungen für Ausgaben. Technisch gesehen erweitert CSFS die Art und Weise, wie Signaturen in Bitcoin überprüft werden können – was in Kombination mit CTV viele neue Anwendungsfälle möglich macht.

Ein zentrales Argument für CTV und CSFS liegt in ihrer Bedeutung für das Lightning-Netzwerk – genauer gesagt für die Implementierung sogenannter Point Time-Locked Contracts (PTLCs), die langfristig die aktuell eingesetzten HTLCs ersetzen sollen. Gregory Sanders („instagibbs“), ein langjähriger Bitcoin-Entwickler, betont in der laufenden Debatte:

CTV+CSFS würde die Aktualisierung des Lightning-Netwerks auf PTLCs beschleunigen, selbst wenn LN-Symmetry [auch „Eltoo“; d. Red] als solches nie übernommen wird.

PTLCs sind zwar auch mit bestehenden Mitteln möglich, doch CSFS erleichtert zentrale kryptografische Abläufe, insbesondere bei sogenannten Adaptor-Signaturen. Diese wiederum sind für PTLCs essenziell. Sanders’ Vorschlag zielt darauf ab, die Komplexität und Fehleranfälligkeit bestehender Umgehungslösungen deutlich zu verringern – zugunsten eines robusteren und wartungsärmeren Lightning-Protokolls.

Anthony Towns, ebenfalls einer der aktivsten Bitcoin-Entwickler der vergangenen Jahre, lenkt den Fokus auf einen oft übersehenen Aspekt: das Fehlen entsprechender Tools. Für viele der theoretisch möglichen Konstrukte, etwa PTLC-Reveals in Verbindung mit musig2-Signaturen, fehlen sowohl Standards als auch Implementierungen:

Selbst grundlegende Adaptor-Signaturen für Schnorr-Signaturen sind im secp256k1-Code nicht enthalten – weder im Standard-Repo noch in experimentellen Forks wie secp256k1-zkp.

Das bedeutet konkret: Auch wenn ein Protokoll wie PTLC bereits „möglich“ ist, fehlen die praktischen Werkzeuge, um es sicher und effizient umzusetzen. CTV und CSFS könnten diese Lücke teilweise schließen – jedoch auf Kosten gewisser On-Chain-Effizienz. Towns schätzt: Mit CTV+CSFS wäre der Implementierungsaufwand deutlich geringer als bei einer reinen Adaptor-Signatur-basierten Lösung.

Auch für das Ende 2023 vorgestellte Konzept BitVM – eine Art virtuelle Maschine für Bitcoin – könnten die beiden Opcodes eine zentrale Rolle spielen. In einer Diskussion auf Basis früherer Entwürfe wurde klar: Durch CTV könnten Transaktionsgrößen um den Faktor zehn reduziert werden. Zudem würden nicht-interaktive Peg-ins ermöglicht, also Einzahlungen in das BitVM-System ohne Rückkanal zum Einzahler. Einige dieser Ideen wurden bereits in einer Testumgebung umgesetzt und damit praktische Nachweise für die Machbarkeit geliefert.

Vor einigen Wochen veröffentlichte der Entwickler James O’Beirne einen offenen Brief an die Bitcoin-Dev-Mailingliste. Unterzeichnet wurde er von mehr als 40 Personen – darunter viele namhafte Entwickler und Projektverantwortliche im Bitcoin-Ökosystem. Der Brief forderte:

Wir bitten die Bitcoin-Core-Entwickler, die Überprüfung und Integration von CTV und CSFS in den nächsten sechs Monaten zu priorisieren.

Die Unterzeichner betonten, dass es sich nicht um eine Forderung nach sofortiger Aktivierung handle, sondern um eine respektvolle Bitte, dem Thema endlich die notwendige Aufmerksamkeit zu schenken.

Wir sind der Ansicht, dass dieser Zeitraum eine gründliche abschließende Prüfung und eine entsprechende Aktivierungsplanung ermöglicht. Diese Bitte soll nicht den Eindruck erwecken, dass die Mitwirkenden den Konsensprozess diktieren. Vielmehr erkennen wir damit an, dass diese Opcodes vor einer möglichen Aktivierung zunächst im am weitesten verbreiteten Bitcoin-Client implementiert sein müssen.

Die Reaktionen aus dem Core-Team ließen natürlich nicht lange auf sich warten – und die fielen teilweise scharf aus. Gregory Sanders, selbst Unterstützer der CTV/CSFS-Funktionalität, kritisierte den Ton und die Methodik des Briefes:

Ich lehne dieses Framing ab – ebenso wie ein Ultimatum, das sich an undeployte BIPs richtet, die seit Jahren keine Updates erhalten haben. CTV+CSFS sind weiter eine Überlegung wert, aber so wird das sicher nichts.

Anthony Towns äußerte sich ähnlich kritisch. Er sieht in der Kampagne eine langfristige Schwächung der technischen Glaubwürdigkeit des Vorschlags:

Die CTV-Diskussion hat wichtige Zwischenschritte übersprungen. Statt sie nachzuholen, versucht man, mit öffentlichem Druck die Entscheidung zu erzwingen. Das schafft Anreizprobleme, statt sie zu lösen.

Antoine Poinsot ging sogar noch weiter und bezeichnete den Brief als kontraproduktiv:

Die Folge dieses Briefs war – wie zu erwarten – ein erheblicher Rückschritt. Es fehlt jemand, der das technische Feedback aufgreift und echte Use-Cases demonstriert. Der Weg führt nur über objektive, technische Argumente, nicht über Unterschriftenlisten.

Ein konkreter Anwendungsfall, der in der Diskussion häufig genannt wurde, sind sogenannte Vaults – also spezielle Sicherheitsmechanismen zur Aufbewahrung von Coins mit verzögerter Freigabe. Jameson Lopp erklärte dazu:

Ich bin vor allem an Vaults interessiert. Und CTV scheint dafür brauchbar zu sein – allerdings mit ähnlichen Schwächen wie bestehende presigned Vaults.

Sowohl Vaults mit CTV als auch solche mit vorab unterschriebenen Transaktionen (presigned Vaults) haben ein Sicherheitsproblem: Wenn jemand den sogenannten „Staging Key“ stiehlt – also den Schlüssel für eine Auszahlung in Vorbereitung –, kann er die Coins klauen, bevor sie ihr eigentliches Ziel erreichen. Weiterentwickelte Vault-Systeme könnten solche Angriffe verhindern, bräuchten dafür aber neue Regeln im Bitcoin-Protokoll, die es heute noch nicht gibt.

Ein Vorteil von CTV-Vaults ist, dass man dabei keine privaten Schlüssel löschen muss, um die Sicherheit zu gewährleisten. Bei presigned Vaults ist das oft notwendig, weil man verhindern will, dass weitere Transaktionen mit diesen Schlüsseln signiert werden. Bei CTV kann man alles über das Skript regeln – das ist besonders nützlich für Backups, weil man dann alle nötigen Informationen aus einem statischen Zustand wiederherstellen kann.

CTV und CSFS haben das Potenzial, eine neue Generation Bitcoin-naher Protokolle deutlich robuster, sicherer und effizienter zu machen. Sie würden wichtige Innovationen wie PTLCs, Vaults oder BitVM nicht nur ermöglichen, sondern auch praktikabler gestalten. Gleichzeitig zeigen die Reaktionen auf den offenen Brief, wie sensibel der Bitcoin-Core-Prozess gegenüber öffentlichen Druckmitteln reagiert – und wie stark Wert auf technische Sorgfalt, Review-Prozesse und Community-Konsens gelegt wird.

Ob und wann CTV und CSFS tatsächlich ihren Weg in Bitcoin finden, bleibt offen. Der aktuelle Zustand zeigt: Technisch ist vieles bereit – politisch und prozessual hingegen steht der Weg noch offen. Es bleibt zu hoffen, dass die Debatte nun in konstruktivere Bahnen zurückfindet – und aus technischer Reife schließlich auch Standard wird.