Newsticker

Bitcoin Core 24.0: Full-RBF, Miniscripts und zufällige UTXO-Auswahl

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.

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.

Über Christoph Bergmann (2443 Artikel)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder ---

5 Kommentare zu Bitcoin Core 24.0: Full-RBF, Miniscripts und zufällige UTXO-Auswahl

  1. abgehoben

  2. …irgendwie ja – abgehoben – in den letzten beiden Absätzen steckt aber wohl die wesentliche Info…die aber nicht leicht zu erfassen ist….trotzdem danke für den Wissenszuwachs.

  3. Wo ist 3.?

  4. 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.

    Vorsicht! Gerade das kann die Privatsphäre erheblich einschränken, sogar sweep_all bei Monero ist entsprechend umstritten, denn man baut aus allen seinen Outputs eine Transaktion und verbindet sie damit wieder (obwohl sie z.B. von Chainanalyse Tools vielleicht als an Fremde ausgegeben markiert wurden). Man bestätigt also seine gesamte History zu einem Wallet und das nicht nur mit einer Wahrscheinlichkeit, sondern zu 100%, wenn man seine gesamten Wechselgeld Outputs wieder verbindet. Auch bei Ring Signaturen ist das durchaus ein Thema, deswegen werden selbst bei kleinen Transaktionen oft zwei Inputs verbunden, obwohl das nicht notwendig gewesen wäre… Hier hat jeder Input zwar seinen eigenen Ring mit aktuell 16 möglichen Kandidaten, aber wenn jemand auf die Idee kommt und z.B. 100 seiner Wechselgelder da reinpackt, ist ein Tracking deutlich wahrscheinlicher, da in jedem dieser mindestens einer dem Wallet zugeschrieben werden kann.

    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.

    Man zwingt die User praktisch zu Lightning oder anderen Off-Chain Lösungen (ohne dass diese reibungslos laufen) bevor sich ein Fee Markt bilden konnte, der aber für das Fortbestehen Bitcoins essentiell ist. Böse Zungen könnten behaupten, „man“ will Liquid auch etwas schmackhafter machen, das nicht nur 0-conf fähig ist, eine absolute Finalität nach zwei Blöcken hat, die dazu alle 60 Sekunden entstehen und dazu noch eine etwas verbesserte Privatsphäre bietet, aber bisher sich keine Sau darum schert, weil es ein zentralisierter Shitcoin ist.

    Gerade recht innovative Zahlungsservices wie Bitrefill oder Cake Pay, die sogar Geschenkkarten mit exakten Beträgen anbieten, die man selbst mit Nachkommastellen definieren kann, macht das unattraktiv, denn oft ist LN mit den Beträgen schlicht überfordert und wenn man im Laden steht, will man nicht auf mehrere Bestätigungen warten, bevor man seine Ware bezahlen kann.

    • > Vorsicht! Gerade das kann die Privatsphäre erheblich einschränken, sogar sweep_all bei Monero ist entsprechend umstritten, denn man baut aus allen seinen Outputs eine Transaktion und verbindet sie damit wieder

      Daher steht im Text auch: „oder ausgewählter UTXO“. Man sollte es nur mit Coin Control verwenden. Hätte das vielleicht klarer sagen sollen.

      Zu RBF: Das wird es ganz nebenbei einfacher machen, mit Quantencomputern anzugreifen, falls es mal soweit ist. Ist mir erst vorhin eingefallen.

Kommentar verfassen

%d Bloggern gefällt das: