Mit Beginn des neuen Jahres 2024 stellen sich viele Nutzer und vor allem Entwickler des Bitcoin-Netzwerks die Frage, ob es vielleicht schon dieses Jahr wieder so weit sein könnte: Eine Soft-Fork und damit ein neues Upgrade für Bitcoin. Die letzte große Änderung, das Taproot-Upgrade aus 2021, wird dieses Jahr seinen dritten Geburtstag feiern, während seit dessen Vorgänger, dem Segwit-Upgrade aus 2017, mittlerweile sechs Jahre vergangen sind. Alleine schon die Zeitabstände werfen also die Frage auf, wann denn der nächste große Schritt für das Bitcoin-Netzwerk ansteht – oder ob es dafür nicht doch noch zu früh ist.
Die Debatte um das nächste Bitcoin-Upgrade ist nämlich alles andere als entschieden. Weder gibt es einen klaren Favoriten unter gleich zahlreichen Vorschlägen, noch ist man sich überhaupt über deren Notwendigkeit einig. Der grundsätzliche Bedarf nach mehr Funktionalität und damit auch neuen Skalierungsmöglichkeiten für Bitcoin, findet sich jedoch bei vielen Stimmen wieder. Wir schauen uns daher das BIP-119 (Bitcoin Improvement Proposal) mit Check Template Verify (CTV) etwas genauer an, das noch im Jahr 2022 für viel Diskussion in der Community sorgte und mittlerweile wieder verstärkt auf Plattformen wie 𝕏 befürwortet, aber auch kritisch diskutiert wird.
Ich kenne keine verbleibenden technischen Einwände gegen CTV.
Ich wünschte, CTV wäre leistungsstärker, aber das ist kein technischer Einwand. Wir werden in Zukunft für leistungsstärkere Covenants kämpfen müssen, egal ob das nun ein neuer Opcode oder eine Erweiterung von CTV sein wird.
Also. Lasst uns CTV aktivieren.
@callebtc auf 𝕏
Covenants
Ein Stichwort, das keineswegs exklusiv auf Jeremy Rubins Vorschlag in BIP-119 zutrifft, sind sogenannte Covenants (dt. Abkommen oder Verpflichtungen). Ganz allgemein handelt es sich dabei um einen Überbegriff für komplexere Einschränkungen, die festlegen, wie eine bestimmte Menge Bitcoin ausgegeben werden darf. Während diese allgemeine Definition auch schon heute auf bestehende Funktionen zutrifft, versteht man im Bitcoin-Kontext unter Covenants meistens solche Einschränkungen, die konkret über das "wohin" bei der Ausgabe von Bitcoin entscheiden, also Bedingungen an eine zukünftige Transaktion stellen. So könnte man beispielsweise Bitcoin an eine Adresse schicken, von der wiederum ausschließlich an eine vordefinierte andere Adresse ausgegeben werden darf.
Diese Funktionalität kann aktuell mit den technischen Gegebenheiten im Bitcoin-Netzwerk, genauer gesagt mit der Bitcoin-Script Sprache, nicht realisiert werden. Genau hier wollen also diverse Vorschläge, darunter auch Check Template Verify, ansetzen.
Lese-Tipp: Die Bitcoin Script Sprache einfach erklärt
Check Template Verify
Konkret schlägt BIP-119 einen neuen Befehl (Opcode) für die Bitcoin-Script Sprache vor: OP_CHECKTEMPLATEVERIFY. Dieser Befehl "führt einen einfachen Covenant ein, der eine begrenzte Anzahl äußerst wertvoller Anwendungsfälle ermöglicht, ohne dabei ein signifikantes Risiko einzugehen" – heißt es in der Motivation des Vorschlags.
Denn ein häufiger Streitpunkt um Covenants ist die Gefahr, Bedingungen permanent und unwiderruflich an eine bestimmte Menge Bitcoin zu knüpfen. Solche "rekursiven" Covenants würden es beispielsweise ermöglichen, Bitcoin, die von einer Krypto-Börse ausgezahlt werden, niemals an eine vorab definierte "schwarze Liste" von Adressen weitersenden zu können. Für die Zensurresistenz und den freien Grundgedanken von Bitcoin ist das berechtigterweise für viele ein ziemliches No-Go. Ganz allgemein sind die konkreten Risiken von solch mächtigen Covenants noch nicht ausreichend benannt.
Genau aus diesem Grund sind Covenants mit CTV von vorneherein recht simpel und eingeschränkt gestaltet. Festgelegt werden kann ein sogenanntes "Template", also eine Vorlage, wie eine zukünftige Transaktion auszusehen hat. Wie der Name "Check Template" schon andeutet, wird bei der Verifizierung einer solchen künftigen Transaktion überprüft, ob diese dem vorab festgelegten Template entspricht. Falls nicht, schlägt die Verifizierung fehl und die Transaktion ist ungültig. Falls doch, wurde die Bedingung des Covenants erfüllt und die Bitcoin können ausgegeben werden. Die Bedingung des Covenants "erlischt" dabei aber und kann sich nicht automatisiert auf beliebig viele darauf folgende Transaktionen übertragen.
Anwendungsfälle
Einer der Vorteile von CTV, nämlich recht spezifisch und eingeschränkt zu sein, überträgt sich auf der anderen Seite etwas negativ auf die eigentlichen Möglichkeiten. Mit CTV kann zwar einiges umgesetzt werden, allerdings müssen im Vergleich zu „universelleren“ Funktionen wie OP_CAT dennoch Abstriche gemacht werden.
Lese-Tipp: OP_CAT: Simples Upgrade für Bitcoin mit endlosen Möglichkeiten?
Eine der prominentesten Anwendungsfälle sind sogenannte Vaults, also besondere Bitcoin-Wallets, die Ausgaben nur schrittweise und mit einem Mechanismus für Notfälle ermöglichen. Damit sollen die eigenen Bitcoin gut vor Angreifern geschützt werden, ohne dafür allzu große Abstriche bei der Nutzerfreundlichkeit machen zu müssen. Sowohl für den einfachen Bitcoin-Nutzer als auch für große Verwalter von Vermögen eine interessante Funktion.
Lese-Tipp: Wie funktionieren Bitcoin Vaults?
Ganz grundlegend ermöglicht die Einführung von Covenants auch sogenannte "Congestion Control" Transaktionen, was auch eine ausschlaggebende Motivation für CTV ist. Das Grundprinzip dabei: Eine einzelne Transaktion (bzw. ein einzelner UTXO) kann, nach ausreichender Bestätigung, gleich mehreren Nutzern versichern, dass sie bezahlt werden können, da dies durch den Covenant verifizierbar festgelegt werden kann – ohne dass die Zahlung direkt stattfinden muss. So können Zahlungen zunächst abgesichert, aber erst zu günstigeren Zeitpunkten tatsächlich durchgeführt werden. Dieses Grundprinzip kann weiterführend auch auf komplexere Skalierungsmethoden wie Ark angewendet werden, dessen Funktionalität im Grunde sehr ähnlich ist.
Lese-Tipp: Ark: Vielversprechender neuer Ansatz zur Skalierung von Bitcoin?
Vereinfacht gesagt gibt es also Potenzial für Skalierung, auch in Kombination mit dem Lightning-Netzwerk durch sogenannte Channel Factories, indem Zahlungskanäle durch das eben schon erwähnte Grundprinzip effizienter verwaltet werden können. Auch von Verbesserungsmöglichkeiten bezüglich CoinJoin-Transaktionen und Privatsphäre im Allgemeinen ist teilweise die Rede.
Und was nun?
Die entscheidende – aber nach wie vor unklare – Frage bleibt: Die Möglichkeiten sind zwar schön und gut, doch warum sollte man gerade Check Template Verify zur Realisierung wählen, wenn es doch auch andere Vorschläge gibt. Mit OP_CAT würden die eben genannten Beispiele auch umgesetzt werden können, und das mit einem weniger komplexen Upgrade, das potenziell sogar mehr universelle Funktionen bietet. Auf der anderen Seite wird argumentiert, dass CTV keine offensichtlichen technischen Nachteile hat und die bewussten Einschränkungen auch für ein geringes Risiko sorgen. Woran sollte man also konkret festmachen, welcher Vorschlag jetzt der Beste für das Bitcoin-Netzwerk ist bzw. ob es einen solchen Vorschlag überhaupt gibt? Keine einfache Frage, für die vorerst wohl noch ausreichend Diskussionsbedarf vorhanden ist.
Das zweite, ebenso wichtige, Argument, ist außerdem die grundsätzliche Frage, ob ein Upgrade für das Bitcoin-Netzwerk überhaupt so dringend notwendig ist – zumindest für den Moment. Die einen sehen spannende neue Möglichkeiten, die für die Skalierung von Bitcoin unausweichlich sind, die anderen wiederum vermissen konkrete Umsetzungen oder Vorteile, wie sie noch bei Segwit oder Taproot "out of the box" mitgeliefert wurden. Check Template Verify, aber auch andere Ansätze für Covenants sind zunächst nur Bausteine, um die tatsächlichen Vorteile erst durch deren Entwicklung zu ermöglichen. Da Upgrades für das Bitcoin-Netzwerk zunächst immer für mehr Komplexität sorgen, kann es schwierig sein, diese zu rechtfertigen, solange noch keine einsatzbereiten Anwendungen darauf aufbauen. Hierauf wird oftmals entgegnet, dass es kaum einen Anreiz gibt, Funktionen zu entwickeln, die womöglich nie zum Einsatz kommen, sollte eine entsprechende Soft Fork nicht aktiviert werden. Handelt es sich also um das altbekannte Henne-Ei-Problem?
So oder so ist es wichtig, sich über zukünftige Änderungen des Bitcoin-Netzwerks Gedanken zu machen und darüber zu debattieren – egal auf welcher Seite man steht. Die langsame und vorsichtige Entwicklung von Bitcoin sollte dabei eher als Vorteil und nicht als Störfaktor angesehen werden. Eine Änderung der Regeln von Bitcoin in Form einer Soft-Fork ist grundsätzlich nicht auf die leichte Schulter zu nehmen, und sollte nicht durch den Zwang einfach "irgendetwas zu ändern" angetrieben werden, sondern durch echte Problemlösungen und Verbesserungen.
