Die Bitcoin-Szene debattiert gerade erhitzt über BIP-119, das eine neue Funktion in das Bitcoin-Protokoll einführen soll. In der Diskussion sind Politik und Technologie eng verflochten. Wir erklären, worum es geht – und warum es so wichtig ist.
Eine der hervorragendsten Eigenschaften von Bitcoinern ist, dass sie extrem emotional auf technologische Details reagieren können. Dinge, die für den Rest der Welt böhmische Weiler sind, können bei Bitcoinern Stürme der Begeisterung oder Empörung hervorrufen. Nirgendwo sonst wird Technologie so politisch.
Das neueste Schlachtfeld ist BIP-119, das OP_CHECKTEMPLATEVERIFY (CTV) einführt. Seit etwa zwei Wochen erhitzt es die Szene.
Vermutlich versteht ihr nicht, was diese Wörter bedeuten. Und vermutlich versteht ihr noch weniger, warum es so ein Geschieß darum gibt. Daher arbeiten wir uns Stück für Stück durch das Drama durch.
BIP-119
Zunächst einmal ist BIP-119 ein „Bitcoin Improvement Proposal“. Wer Bitcoin verändern will, muss seinen Vorschlag in einem bestimmten Format einreichen, so dass es von den Core-Entwicklern diskutiert werden kann. Nur was ein BIP ist, hat eine Chance, in Bitcoin Wirklichkeit zu werden.
Mit BIP-119 schlägt der Entwickler Jeremy Rubin vor, einen neuen Op_Code einzuführen, nämlich OP_CHECKTEMPLATEVERIFY (CTV). Das BIP wurde Mitte 2020 im offiziellen Repositorium von Bitcoin Core veröffentlicht.
Ein Op_Code meint eine Art Befehl der Skriptsprache von Bitcoin. In jeder Transaktion stecken diverse Op_Codes. Diese definieren Bedingungen, wie die überwiesenen Coins weiter ausgegeben werden können. Im einfachsten Fall bestimmen die OP_Codes, dass man die Folgetransaktion mit einem bestimmten Schlüssel signieren muss. Das ist die Standardtransaktion.
Jeremy Rubin möchte mit BIP-119 also einen neuen OP_Code hinzufügen. Er möchte der Skriptsprache von Bitcoin erlauben, eine Operation auszuführen, die vorher nicht möglich war: OP_CHECKTEMPLATEVERIFY (CTV).
Aber was ermöglicht CTV? Die Antwort lautet „Covenants“.
Covenants
Covenants ist ein Fachbegriff aus dem britischen Rechtswesen. Er bezeichnet laut Wikipedia „ein einseitig bindendes Versprechen, das man in der besonderen Privatbeurkundungsform des deed abgibt.“
Für Bitcoin bedeutet dies: Man kann mit CTV, erklärt das BIP, „Transaktionen bilden, die künftig eine beschränkte Nutzung haben“. Man kann nicht nur definieren, mit welchem Schlüssel die Folgetransaktion zu signieren ist, sondern auch, welche Eigenschaften sie haben soll. Man bestimmt also nicht nur, WER das Geld ausgeben kann – sondern auch WIE.
Auf rein technischer Ebene macht der Op_Code das Folgende: Er lädt ein Objekt von 32 Byte und prüft, ob der Hash der Transaktion diesem Objekt entspricht. Nur wenn er dies tut, ist die Transaktion valide.
CTV erlaubt es, sehr präzise Bedingungen für Folgetransaktionen zu formulieren. Dies kann fast jedes Element einer Transaktion betreffen: Inputs und Outputs, Locktime, die Skripte, den Wert und vieles mehr.
Covenant sind, erklärt Jeremy Rubin im BIP, „Beschränkungen, wie ein Coin außer durch den Besitz des Schlüssels ausgegeben werden kann“. Aber wofür sind sie gut?
Tresorräume, Staukontrollen, nicht-interaktive Channels
Jeremy Rubin erklärt an ein paar Beispielen, was man mit Covenants machen kann:
- Man kann einen Vault bilden (wörtlich: einen Tresorraum): Eine Transaktion ist nur gültig, wenn der Empfänger eine bestimmte Adresse ist oder einem Set an Adressen angehört.
- Man kann „nicht-interaktive Payment Channels“ konstruieren. Bisher müssen im Lightning-Netzwerk beide Seiten agieren, damit eine Transaktion durch einen Payment Channel fließt. Mit Covenants ist es möglich, Payment Channels zu bilden, bei der nur eine Seite aktiv sein muss, so dass die andere sogar offline sein kann. Wie genau dies funktioniert, ist komplex, aber wenn es funktioniert, wäre es ein Knüller.
- Eine Börse kann eine „Staukontrolle“ bilden, wie Rubin es nennt: Sie sendet eine Transaktion, die viele Transaktionen bündelt, wartet aber, bis die Gebühren gesunken sind, um sie dann mit einer anderen, kleineren Transaktion zu triggern.
- Man könnte Mining-Pools bilden, bei denen die Auszahlung der Erlöse nicht vom Betreiber abhängt: Pools ohne zentrale dritte Partei, der man vertrauen muss.
- Etwas esoterischer ist der Vorschlag, Wetten auf Softforks abzugeben, oder auf sicherere Weise größere Hashed Time Locked Contracts (HTLCS) zu schaffen (HTLCS sind ein essentieller Bestandteil von Lightning).
Braucht man das wirklich?
Die Offline-Transaktionen für Lightning scheinen ein gewaltiger Gewinn zu sein. Sie wären ein Gamechanger. Ich würde sagen, sie allein reichen aus, um BIP-119 zu wollen.
Bei allen anderen der von Rubin skizzierten Anwendungen ist aber fraglich, ob man sie wirklich braucht.
Die Vaults klingen auf den ersten Blick gut. Aber sind sie wirklich etwas anderes als ein zeitversetztes Multisig? Haben sie wirklich Vorteile gegenüber dem, was bereits möglich ist?
Und brauchen Börsen die von Jeremy skizzierte Staukontrolle? Können sie nicht einfach warten, bis die Gebühren niedrig sind, um eine Transaktion zu bilden?
Mit P2Pool und Braiins von Slush haben wir bereits Modelle von etwas dezentraleren Mining-Pools. Bringt CTV hier wirklich einen nennenswerten Vorteil? Und ist die Veruntreuung von Block-Erträgen durch Pools überhaupt ein Problem?
Und so weiter. Braucht es CTV also wirklich? Vor allem, nachdem Bitcoin erst Taproot erhalten hat, das noch längst nicht in den Wallets angekommen und, wie das brillante Taro zeigt, auch noch bei weitem nicht ausgeschöpft ist?
Und überhaupt: Warum verschweigt Jeremy Rubin die offensichtliche und naheliegendste Anwendung – zweckgebundene Transaktionen? Also Whitelists? Liegt es daran, dass CTV ein mächtiges Instrument ist, um Kontrolle auszuüben – und dass genau dies viele eher erschreckt als begeistert?
Rekursive Blacklists
Der Diskurs zu CTV, der in den letzten Wochen ausgebrochen ist, teilt sich auf eine merkwürdige Weise: Auf der einen Seite diskutieren technisch kompetente Entwickler die Politik, und auf der anderen Seite diskutieren politisch begabte Influencer die Technologie.
Die naheliegendste und vielleicht stärkste Kritik äußert die Mutter aller Bitcoin-Influencer, Andreas Antonopolous. Bei ihm gewinnt sie jene Heftigkeit, mit der nur Bitcoiner auf technologische Details reagieren können.
Andreas befürchtet, dass Covenants Whitelists einführen. Die von Rubin vorgeschlagenen Vaults machen das ja bereits, und von dort aus ist es nur noch ein Sprung dahin, dass Regierungen Banken und Börsen verpflichten, nur noch Überweisungen zu tätigen, die an Adressen auf einer Whitelist gehen.
Schlimmer noch ist, dass auch rekursive Whitelists möglich werden: Eine Folgetransaktion ist nur gültig, wenn sie an eine Adresse auf der Whitelist geht UND wenn sie ebenfalls eine Whitelist setzt. Einmal überwiesen könnten Bitcoins niemals aus diesem „Walled Garden“, diesem ummauerten Garten, entkommen. CTV drohe daher, sagt Andreas dramatisierend, Bitcoin zu töten.
Update-Anmerkung: Offenbar sind rekursive Whitelists nicht möglich. Ob das nun daran liegt, dass sie es niemals waren, oder ob es nach Kritik geändert wurde, weiß ich gerade noch nicht.
Der Blocktrainer dreht diese Kritik noch etwas weiter: Auch er fürchtet, dass BIP-119 Bitcoin zerstören könnte. Dabei tauscht er Whitelists durch Blacklists aus.
Der Unterschied zwischen schwarz und weiß ist fundamental. Eine Whitelist enthält Adressen, an die man senden darf, ein Blacklist Adressen, an die man nicht senden darf. Bei einer Blacklist ist alles erlaubt, was nicht verboten ist; bei einer Whitelist alles verboten, was nicht erlaubt wurde.
Vor allem aber: Soweit ich es sehe, ermöglicht CTV keine Blacklists, da es nur positive, aber keine negativen Bedingungen erlaubt. Das räumt der Blocktrainer in einem nachfolgenden Video auch ein.
„Wenn dich jemand dazu zwingen kann, eine andere Währung zu verwenden, bist du bereits verloren.“
Der Unterschied zwischen White- und Blacklists ist entscheidend. Eine Blacklist ist viel weniger schlimm – und darum viel schlimmer.
Eine Blacklist ist ertragbar und würde vermutlich von den Usern akzeptiert werden. Wie viele Leute sind wirklich davon betroffen, keine Bitcoins an eine Adresse senden zu können, die auf den Blacklists des US-Finanzministeriums stehen? Eine Minderheit. Und selbst wenn – die Betroffenen können einfach eine neue Adresse bilden, die nicht auf einer Blacklist steht.
Mit Blacklists könnten sich onchain-Beschränkungen Stück für Stück und mit dem Wohlwollen der Community in Bitcoin fressen. Es wäre so wie mit dem Frosch im Kochtopf, der langsam aufheizt. Darum wären sie schlimmer als Whitelists.
Whitelists hingegen sind unerträglich. Sie sind wie ein Topf, der sofort aufheizt, so dass derf Frosch heraushüpft. Ein Coin, der durch rekursive Covenants für immer eingeschränkt ist, wird zwingend weniger wert sein als andere Coins. Eine Börse, die ihn verkauft, ohne ihren Kunden zu informieren, macht sich im schlimmsten Fall strafbar und wird in jedem Fall das Vertrauen der Kunden verlieren.
In der Mailinglist bringt dies Darosier perfekt auf den Punkt: „Wie unterscheidet sich das davon, wenn man dich mit einem Altcoin bezahlt? Es kommt mir vor, als sei die Fähigkeit, zu sagen ‚Sorry, dein Geld ist mir hier nicht gut genug‘ im Kern von Bitcoins Sicherheit […] Wenn dich jemand dazu zwingen kann, eine andere Währung zu verwenden, bist du bereits verloren.“
Überhaupt fragt man sich, wie das skalieren soll. Wenn man nur 10-20 mögliche Adressen in die Whitelist schreibt, ist der Coin vollkommen unbrauchbar; wenn man beispielsweise 1000 reinschreibt, bläht das die Transaktion um 32 Kilobyte auf, was eine ziemlich teure Übung wird und überhaupt nicht skaliert.
Ohnehin ermöglicht CTV hier nichts fundamental neues. Man könnte mit einfachen Multisig-Transaktionen ebenfalls „Walled Gardens“ einrichten, indem etwa die BaFin oder die FATF jede Transaktion mitsignieren muss. Das wäre in der Praxis ebenso effektiv wie eine Whitelist mit CTV, würde viel besser skalieren und wäre auch viel praktischer, da man die Black- oder Whitelists auch forlaufend aktualisieren kann.
Aus diesen Gründen spielen die rekursiven Whitelists in den Diskussionen der Entwickler so gut wie gar keine Rolle. Heftig ist die Diskussion dennoch.
„Ich verstehe nicht, warum du meinst, CTV sei ‚ bereit für den Einsatz‘ in Bitcoin.“
Leicht toxisch wurde die Debatte bereits im Januar 2022. Jeremy Rubin hat zu dieser Zeit versucht, die Core-Entwickler zu überzeugen, die Aktivierung von CTV einzuleiten.
Mehrere prominente Entwickler verpassten ihm daraufhin eine Abfuhr. So schrieb etwa Blockstream-CEO Adam Back am 3. Januar 2022, es seien weitere Analysen des Protokolls und von „gut durchdachten Alternativen“ notwendig.
Review of a specific proposal for a part of covenants (CTV) does not need crowd funding. What is needed is protocol analysis and well-thought out alternatives, like more work on TLUV and systematic thinking about the problem space. Cultivating that would be useful.
— Adam Back (@adam3us) January 3, 2022
Schärfer drückte sich Matt Corallo von ChainCodeLabs aus: „Ich verstehe nicht, warum du meinst, CTV sei ‚ bereit für den Einsatz‘ in Bitcoin. Zu keinem Zeitpunkt in Bitcoins Geschichte war es ok, Dinge in den Konsens zu bringen […] ohne über Alternativen nachzudenken. Der Push für CTV fühlt sich … falsch an, auf jede erdenkliche Art. Anstatt kollaboratives Entwickeln fühlt es sich an wie ‚Ich habe das gebaut, lasst es uns tun‘, während jedes Feedback ignoriert wird. Ehrlich gesagt sollte es allein deswegen beim Versuch eingehen …“
I don't understand at all why you think CTV is "ready to go" into Bitcoin, at no point in Bitcoin's history has it been okay to propose shipping things into consensus (which can then never ever ever be removed from the consensus rules) without considering alternatives.
— Matt Corallo (@TheBlueMatt) January 3, 2022
Dem stimmt Bob McElrath zu: „Ich will sehen, dass CTV die beste und richtige Lösung für ein Problem ist.“
This basically sums up my hesitance around CTV. It's a solution in search of a problem and one man's push to make his work relevant. I want to see that CTV is the best and right solution to a problem, not an arbitrary thingamabob that can be used in lots of different ways. https://t.co/XDOfkiDtji
— Bob McElrath (@BobMcElrath) January 3, 2022
Und auch der Entwickler Mark Erhardt (Murch) ist skeptisch: „Protokoll-Änderungen müssen sicher, nützlich, erwünscht und die beste Variante sein. Die Abwesenheit von Kritik als stille Unterstützung zu verkaufen ist irreführend. Ein Vorschlag muss Interesse hervorrufen, um Reviews zu bekommen. Dieser Vorschlag würde die Philosophie ändern, wie Transaktionen funktionieren, und ich sehe nicht, dass Experten dies unterstützen.“
Protocol changes need to be safe, useful, demanded, and the best choice. Casting absence of criticism as tacit support is misplaced. A proposal needs to garner interest to get review.
This proposal would change the philosophy of how txns work, but I see no support among experts.— Murch (@murchandamus) April 21, 2022
Ähnlich geht es in der Mailing-Liste weiter. Peter Todd nennt BIP-119 etwa eine „unreife Idee“ und Jeremys Implementierung „unzureichend.“ Er beharrt darauf, dass sie mögliche DoS-Angriffe ermögliche.
Man könnte noch lange weitermachen. Es hagelte Kritik und Ablehnung im Januar. Dabei fällt auch, dass es an keiner Stelle darum geht, ob Covenants an sich erwünscht sind oder nicht. Es scheint ein Konsens zu bestehen, dass ihr Nutzen den möglichen Schaden überwiegt.
Auch die inhaltlich-technische Kritik fällt spärlich aus. Es geht weniger um den Inhalt, sondern um die Form – darum, WIE man das Bitcoin-Protokoll verändert.
Jeremy Rubin versuchte in den folgenden Monaten, die anderen Entwickler zu überzeugen. Doch dies gelang ihm offenbar nicht. Und damit erreichte die Debatte die heiße, toxische Phase.
„Das ist, wie es sein muss.“
Auf seinem Blog kündigt Jeremy an, eine Version von Bitcoin Core zu veröffentlichen, die den neuen OP_Code sowie einen Aktivierungsmechanismus enthält.
Man sollte das Folgende wissen: Ein neuer Op_Code stellt eine Änderung des Protokolls dar. Dies ist ein nicht unerheblicher Eingriff, der bei Core gewöhnlich durch eine Softfork stattfindet, wie bei SegWit oder Taproot. Eine Softfork bedeutet, dass ALLE Miner den Code benutzen müssen, da Blöcke, die mit dem alten Code erzeugt werden, ungültig werden.
Um die Softfork zu aktivieren, nutzt Rubin den Speedy Trial Mechanismus. Dieser wurde bereits bei Taproot genutzt. Er funktioniert so: Wenn 90 Prozent der Miner über einen Zeitraum von etwa zwei Wochen (2016 Blöcke oder eine Difficulty-Epoche) Zustimmung signalisieren, wird das Upgrade aktiviert. Vergehen hingegen drei Monate, ohne dass diese Schwelle erreicht wird, gilt der Versuch als gescheitert.
Speedy Trial erlaube es, erklärt Rubin, rasch zu einer Entscheidung zu kommen. Und er will diese Entscheidung. Er halte sich schon lange mit CTV auf, und er habe auch andere Ziele und Pläne (mit Bitcoin). Das Upgrade ist programmiert, und er möchte dieses Kapitel abschließen, anstatt in endlosen Diskussionen stecken zu bleiben.
Rubin ist offenbar frustriert von den Core-Entwicklern: „Ich habe die Maintainer um klare Aussagen gebeten, welche Anforderungen sie an das CTV-Pull-Request stellen, aber ich wurde abgewiesen ohne klare Kriterien, doch mit der Erklärung, dass Diskussionen über Softforks nicht in der Verantwortung der Maintainer liegen.“
Er sei zuerst überrascht gewesen, habe dann aber begriffen: „Es ist nicht die Schuld der Maintainer, dass sie mir keine Führung geben können. Das ist, wie es sein muss.“ Denn wenn die Core-Entwickler darüber entscheiden, wie man das Protokoll verändert, bringen sie sich selbst in eine gefährliche Lage. „Der einzige Weg, wie Bitcoin Core apolitisch bleiben kann, ist, indem Softforks unabhängig veröffentlicht und durch die weite Community akzeptiert werden.“
Klingt fair und überzeugend, oder? Doch die Core-Entwickler sehen das anders.
Es geht nicht um die Technik, sondern um die Politik
Matt Corallo findet sehr klare Worte in der Mailinglist: „CTV zu aktivieren oder einen Weg zu suchen, es in Bitcoin zu zwingen, ist in dieser Phase verletzend und kurzsichtig. Schlimmer noch, es setzt einen unglaublich ungünstigen Präzedenzfall darüber, wie wir über Änderungen von Bitcoin und dem Erhalt von Bitcoins Kultur des sicheren und sorgfältigen Designs denken.“
Und Adam Back tritt auf Twitter nach: „Es ist enttäuschend, zu sehen, wie jemand versucht, Reviews und andere rationale Argumente zu übergehen oder zu ignorieren.“ Und so weiter. Das ganze heizte sich bis zu den oben genannten Videos auf, in denen Jeremy beschuldigt wird, mit BIP-119 Bitcoins zu zerstören.
Der Entwickler hat offenbar eine rote Linie überschritten. Dabei geht es aber, zumindest bei seinen Kollegen, nicht um das Ziel von BIP-119, und es geht auch nicht um technische Mängel.
Es geht vielmehr – und das ist natürlich frustrierend für Jeremy – um den Prozess. Nicht um Technik, sondern um Politik.
Die Entzauberung der Softfork
In gewisser Weise rächt sich nun, dass die Bitcoin-Community Softforks verherrlicht. Dies begann im Zuge der Blocksize-Kriege, als die Szene eine Hardfork zur Erhöhung der Blockgröße ablehnte.
Softforks wurden dabei als sanfte, harmlose Alternative zu Hardforks dargestellt. Dabei war schon lange klar, dass sie ein sehr gefährliches und auch undemokratisches Instrument sind.
Man muss den Unterschied zwischen Soft- und Hardforks kennen. Eine Hardfork ist ein „nicht abwärtskompatibles“ Upgrade. Jeder Knoten, der nicht mitzieht, verliert den Konsens. Er ist draußen. Um erfolgreich zu sein, benötigt eine Hardfork nicht nur die Unterstützung der Miner, sondern auch der Community und der Full Nodes. Das macht sie in gewisser Weise demokratisch.
Eine Softfork hingegen ist für die Full Nodes „abwärtskompatibel“. Lediglich die Miner müssen mitziehen. Die Full Nodes bekommen gar nichts davon mit, wenn sie das Upgrade nicht mitmachen. Sie bilden sich weiterhin ein, alle Transaktionen zu verstehen und zu validieren, obwohl sie das bei den Transaktionen, die durch die Softfork ermöglicht werden, nicht mehr tun.
Wenn Bitcoiner behaupten, ihr Full Node bewahre die Stabilität der Regeln, dann trifft dies nur auf Regeln zu, die per Hardfork geändert werden. Eine Softfork untergräbt diesen Mechanismus. Sie gaukelt dem Full Node vor, die Gültigkeit einer Transaktion zu verifizieren, während er den wesentlichen Teil in ihr gar nicht versteht. Das, worum es geht, schleicht sich durch den Radar des Ful Nodes. Eine Softfork entzieht dem Full Node das Mitspracherecht. Wenn man Bitcoin angreifen will, etwa durch die Einführung von Onchain-Whitelists, wäre eine Softfork eine sehr viel zielführendere Methode.
Jeremy Rubin hat damit die Diskussion ausgelöst, welche in der Bitcoin-Community schon lange fällig war. Sein Vorstoß hat die Softfork entzaubert, auch wenn dies erst noch in der breiten Szene ankommen muss.
Warum darf CTV nicht das, was Taproot durfte?
Man könnte die Ideologie, gegen die Jeremy rennt, auch so formulieren: Ein Upgrade mit weitreichenden Folgen – jede Protokolländerung – SOLL toxisch sein. Der Dissens SOLL der Standard sein, Konsens für Regeländerungen SOLL hart zu erringen sein.
Nicht Funktionsreichtum oder Flexibilität, sondern Stabilität ist das, worauf es bei Bitcoin ankommt. Das ist die Ideologie. Das Ideal ist das verknöcherte Protokoll, das niemals wieder geändert wird.
Aber warum entzündet sich diese Diskussion an BIP-119? Warum ging Taproot so gut durch, obwohl es ebenfalls eine Softfork ist, die ebenfalls mit Speedy Trial aktiviert wurde?
Die Antwort liegt erneut in der Form: Taproot wurde länger geplant und intensiver diskutiert, einschließlich des Verfahrens, die Softfork zu aktivieren. Taproot wurde zudem von weitbekannten Bitcoin-Veteranen – Gregory Maxwell und Pieter Wuille – erdacht und umgesetzt.
CTV hingegen ist von Jeremy Rubins, einem engagierten, aber viel weniger bekannten Entwickler. Er hat die Diskussion nicht ausgesessen, sondern abgeschnitten, indem er auf die Aktivierung drängt und nun sogar versucht, sie gegen den Konsens der Entwickler zu erzwingen. Das weckt Erinnerungen an Mike Hearn und BitcoinXT …
Die Art und Weise, wie CTV aktiviert wird, wirkt wie ein Angriff. Vielleicht nicht wie ein Angriff per se. Aber sie wirkt wie eine Methode, die man auch für einen Angriff missbrauchen kann. Daher ist Ablehnung, Dissens und Drama die einzige Option, so unangenehm dies für Jeremy und alle ist, die Covenants wollen.
Christoph hat vor kurzem sein zweites Buch veröffentlicht: „Das Bitcoin-Kompendium: Netzwerk und Technologie“. Es ist eine überarbeitete Auslese seiner besten Artikel für dieses Blog. Ihr könnt das Kompendium direkt auf der Webseite Bitcoin-Buch.org bestellen – natürlich auch mit Bitcoin – oder auch per Amazon.
Tipps für Stories sind an christoph.bergmann@mailbox.org immer erwünscht. Für verschlüsselte Nachrichten nutzt bitte meinen PGP-Schlüssel — Auf Telegram! könnt ihr unsere News abonnieren.