Bitcoin Core veröffentlicht die Version 24.0 des Bitcoin-Client. Diese wartet mit einigen interessanten Änderungen auf, darunter auch eine, die eher kontrovers diskutiert wird.
Bitcoin-Core-Versionen mit einer vollen Zahl sind meistens „Major Releases“ – sie bringen umfangreiche Neuerungen, an denen die Entwickler durch die folgenden Versionen bis zur nächsten vollen Nummer feilen. So ist es auch mit der 24.0.
Der Release 24.0 wird von einer Kontroverse um Replace-By-Fee überschattet. Dabei aber enthält die Version einige weitere spannende Neuigkeiten, die wir zunächst vorstellen, bevor wir uns der Kontroverse zuwenden.
1. Miniscript
Eine der vielversprechendsten Neuerung ist die Implementierung von Miniscript. Miniscript ist eine Art Programmiersprache, um Bitcoin-Scripte zu schreiben.
Natürlich kann man Bitcoin-Transaktionen schon heute durch Scripte „programmieren“. Dies ist aber komplex, mühsam und in unerfahrenen Händen auch unsicher. Miniscript vereinfacht und strukturiert dies, indem es sogenannte Deskriptoren einführt, die bestimmte Scripte abbilden.
Die für Bitcoin 24.0 eingeführte erste Implementierung ist sehr rudimentär. User können eine neue Wallet erzeugen, die Miniscript-Deskriptoren für P2SWH-Adressen importieren kann. Die Wallet kann Bitcoins empfangen, aber noch nicht versenden.
Das Feature ist damit nur für experimentierfreudige Entwickler gedacht. Bis zur umfänglichen Einführung in die Userpraxis dürfte es noch ein weiter Weg sein. Aber der erste Schritt ist schon mal gemacht.
2. Sendall und zufällige Inputs
Mit den folgenden zwei Änderungen gibt Core Usern Werkzeuge zur Hand, um ihre Privatsphäre zu stärken.
Erstens gibt es den RPC-Call „Sendall“. Dieser sendet sämtliche Bitcoins der gesamten Wallet oder in ausgewählten UTXOs an eine Empfangsadresse. Dies kann praktisch sein. Vor allem aber hilft es, die Privatsphäre zu verbessern, da dabei kein Wechselgeld entsteht.
Zweitens wählt Core nun die UTXOs, die eine Transaktion ausgibt, zufällig aus. Dies macht es für Blockchain-Analysten schwieriger, eine Wallet anhand der UTXO-Selektion zu identifizieren und Muster zu erkennen, die das Wechselgeld identifizieren.
Hierfür wählt die Wallet eine zufällige Zahl zwischen der einfachen und der dreifachen Größe der Zahlung. Diese Zahl wird dann bestimmen, welchen UTXO sie ausgibt. Damit wird der UTXO manchmal nur ein wenig größer sein als der Betrag, manchmal dagegen deutlich größer.
4. Full RBF
Nun kommen wir zur kontroversen Neuerung von Core 24.0: Dem Ausbau von Replace-By-Fee (RBF) zu Full-RBF.
Falls es euch kein Begriff ist: RBF erlaubt es, eine Transaktion durch eine andere mit einer höheren Gebühr zu ersetzen. Dies ist an sich schon immer möglich – auch mit einem anderen Empfänger -, da die Miner sich aussuchen können, welche Transaktionen sie bestätigen. Es wurde jedoch lange erschwert, etwa durch die Regel, dass Nodes nur die Transaktion weiterleiten, die sie als erstes gesehen haben (First-Seen-Rule).
RBF baut nun auf der einen Seite diese Regel ab, und erlaubt es Usern auf der anderen, Transaktionen als RBF zu markieren und durch eine andere zu ersetzen. Dies hilft etwa, die Gebühren nachträglich zu erhöhen, was Core durch einen „bumb Fee“-Knopf in der Benutzeroberfläche abbildet.
Core 24.0 bringt nun zwei Neuigkeiten ins Spiel, die der Begriff „Full-RBF“ bezeichnet: Erstens können User ihre Knoten so konfigurieren, dass sie auch dann Transaktionen ersetzen, wenn diese nicht mit der RBF-Flagge markiert wurden. Diese Option ist standardmäßig ausgeschalten. Zweitens werden RBF-Transaktionen zum Standard, anstatt wie bisher aktiviert zu werden.
Diese Neuerung wurde schon im Oktober lebhaft und kontrovers diskutiert. Wir haben bereits darüber berichtet. So klagt etwa Sergej Kotlar von Bitrefill, dass sein Marktplatz für Gutscheinkarten durch Core 24.0 gezwungen wird, keine unbestätigten Onchain-Transaktionen zu akzeptieren, sondern die User zu instruieren, entweder eine Treuhand-Wallet oder Lightning zu verwenden.
Generell war die Änderung für Core ungewöhnlich kontrovers. John Carvalho, ebenfalls von Bitrefill, beschwert sich etwa, dass mehrere angesehene Entwickler, etwa Suhas Daftuar, David Harding, Antoine Raird und Jon Atack finden, dass es falsch war, Full-RBF in Core 24.0 einzuführen. Da der Mempool derzeit so leer ist wie lange nicht, hätte es keine Not gegeben, dies zu erzwingen.
Here's Jon Atack, an experienced & respected Core dev giving feedback about the mempoolfullrbf feature.
Other Core devs that agree it was the wrong move to include this in Core v24: Suhas Daftuar, David Harding and Antoine Raird, the original author of the controversial change. pic.twitter.com/jXumiZpYS2
— John Carvalho (@BitcoinErrorLog) November 26, 2022
So kommt es, dass Core in den Release Notes die Änderung argumentativ begründet, was sehr selten geschieht: Manche Bitcoin-Dienstleister, so die Release Notes, erwarteten, dass die erste Version einer unbestätigten Transaktion, die sie sehen, auch bestätigt werde. Dies werde aber nicht durch das Bitcoin-Protokoll gedeckt. Miner könnten diese Transaktion jederzeit ersetzen. Dennoch verließen sich mehrere Händer und Dienstleister heute auf diese Annahme. Die Core-Entwickler rieten davon entschieden ab.
Die Core-Entwickler übernehmen damit also für die Händler und Dienstleister eine Risikoeinschätzung. Diese trifft sich, wie Sergej Kotlar in der Mailing-Liste ausführt, nicht wirklich mit der Realität: „Ich denke, wir hatten einen einzigen Vorfall in acht Jahren des Betriebs, dass jemand erfolgeich unseren Server getäuscht hat, so dass wir eine Zahlung akzeptierten, die am Ende nicht bestätigt wurde.“ Es ist in den meisten Fällen, selbst beim eher heiklen Handel mit Gutscheinkarten, möglich, das Risiko eines Double Spends zu kontrollieren. Anders gesagt: es war. Core 24.0 macht diese Risikokontrolle sehr viel schwieriger, wenn nicht unmöglich.
Langfristig ist Full-RBF jedoch weniger kontrovers als es erscheinen mag. So gut wie alle sind sich einig, dass Echtzeit-Transaktionen über Lightning anstatt onchain laufen sollen, und dass es, gerade mit dem abnehmenden Block-Reward, notwendig sein wird, die Risiken von Double-Spends transparent zu machen, anstatt User in einem falschen Gefühl der Sicherheit zu wiegen. Die Frage ist lediglich, ob es jetzt schon nötig gewesen wäre.