Bitcoin Core 24.0 wird Full-RBF ermöglichen – droht damit das Ende unbestätigter Transaktionen?

Unbestätigte Transaktionen können nützlich sein. Unter anderem für Lightning-Zahlungen mit der Muun-Wallet. Deren Gründer fürchtet, dass ein geplantes Update von Bitcoin Core dies unmöglich machen wird. Daraus entspinnt sich eine spannende Diskussion in der Mailing-List, die grundsätzliche weltanschauliche Unterschiede offenlegt.

Über den Oktober hinweg zog sich eine spannende Diskussion durch die Bitcoin-Mailing-List. In ihr ging es über den geplanten Release von Bitcoin Core 24.0 und das durch diesen eingeführte “Full RBF”. Die Diskussion ist technisch, das liegt in der Natur der Sache, doch sie ist überschaubar kompliziert.

Dario Sneidermanis, der Gründer der Lightning-Wallet Muun, eröffnete die Diskussion, indem er sein Unbehagen mit 24.0 zum Ausdruck brachte:

“Während der letzten Tage haben wir den neuesten Bitcoin Core Release Kandidat untersucht, und wir fanden einige besorgniserregende Fakten zum Deployment von Opt-in Full-RBF.” Die Folge davon sei, “dass Zero-Conf Apps (wie Muun) nun augenblicklich die Zero-Conf features abschalten muss.”

Da schon allein dieser Satz eine Handvoll Fremdwörter enthält, werden wir zunächst diese erklären, bevor wir uns mit der Diskussion auseinandersetzen.

Zero-Conf, RBF, Opt-In, First Seen

Zero-Conf meint, dass eine Bitcoin-Transaktion akzeptiert wird, noch bevor die Miner sie in einen Block gepackt und damit bestätigt haben. Diese unbestätigten Transaktionen sind in den allermeisten Fällen sicher genug und werden daher auch weithin akzeptiert.

Ein Beispiel ist die Muun-Wallet. Sie bildet mithilfe von unbestätigten Transaktionen “submarine swaps“, welche ausgehende Lightning-Zahlungen unterstützen und in vielen Fällen erst ermöglichen. Andere Beispiele sind Bitrefill, die Gutscheinkarten zum Teil gegen unbestätigte Transktionen verkaufen, oder manche Bitcoin-Automaten, die Bargeld für Bitcoin ausgeben.

RBF hingegen ist die Abkürzung von Replace By Fee. Dies meint die Funktion von Bitcoin Core und anderen Wallets, dass man eine unbestätigte Transaktion durch eine andere ersetzen kann. Der Zweck ist, die Gebühren einer Transaktion nachträglich zu erhöhen. Dies kann einen effizienteren Gebührenmarkt für Platz auf der Blockchain ermöglichen. RBF ist eine elegante und effiziente Methode dafür, hat aber den Nachteil, dass damit nicht nur die Gebühr, sondern auch der Adressat der Transaktion geändert wird.

Aus diesem Grund ist RBF Opt-In. Der Begriff kommt aus dem Direktmarketing und meint, dass man einem Vorgang – etwa dem Erhalt von Werbematerialien – vorher explizit zustimmen muss. Der Standard in Bitcoin-Core sind Nicht-RBF-Transaktionen. Um sie ersetzbar zu machen, muss man eine Einstellung aktivieren.

RBF-Transaktionen tragen zudem eine Flagge, so dass jeder erkennen kann, dass sie ersetzbar sind. Üblicherweise werden solche Transaktionen erst akzeptiert, wenn sie eine Bestätigung haben.

Schließlich gilt bei Bitcoin Core weiterhin die “First Seen” Regel: Wenn ein Core Node eine Transaktion empfängt, die einer anderen Transaktion widerspricht – also ein Double Spend – wird er sie akzeptieren. Er wird sie nicht in den Mempool der unbestätigten Transaktionen aufnehmen, und er wird sie nicht an die anderen Nodes weiterleiten.

Dies macht es sehr viel anspruchsvoller, RBF zu nutzen, um zu betrügen, indem man beispielsweise eine Transaktion rückwirkend umleitet.

Wie Core 24.0 unbestätigte Transaktionen unsicher macht

Der Release-Kandidat für Bitcoin Core 24.0 ändert nun zwei Details an RBF.

1.) User können einstellen, dass ihr Knoten auch widersprüchliche Transaktionen weiterleitet, wenn die Gebühren höher sind. Sie können die “First Seen”-Regel ausschalten. Dies wird es auch erlauben, Transaktionen zu ersetzen, selbst wenn diese nicht explizit als ersetzbar markiert werden. Dies wird “Full RBF” genannt.

2.) Core wird die Option “-walletrbf” automatisch auf “true” stellen, was bedeutet, dass Opt-in-RBF der Standard ist (was das Konzept von Opt-in und Opt-out auf den Kopf stellt).

Dario und das Team von Muun-Wallet haben den Release-Kandidat untersucht und kamen zum Schluss, dass dieser sie zwingen wird, die Submarine-Swaps für Lightning auszuschalten.

Bisher nehmen Muun und andere Anwendungen, erklärt Dario, “Onchain-Transaktionen entgegen, bei denen sie nicht die Inputs kontrollieren, und entscheiden auf Basis einer Risikoanalyse, ob sie diese Zahlung ohne Bestätigung akzeptieren.”

Die Risikoanalyse ist nicht allzu kompliziert und wurde schon von Satoshi am Beispiel eines Snack-Automaten beschrieben: Wenn eine (Nicht-RBF) Transaktion weit genug im Netzwerk propagiert wurde, braucht der Sender die Unterstützung der Miner, um sie zu ersetzen. Das Risiko dafür geht bei kleineren Zahlungen, wie für ATMs, Gutscheincodes und Swaps üblich, mehr oder weniger gegen Null. Es lässt sich in der Praxis hervorragend kontrollieren.

Core 24.0, fürchtet Dario, ändere dies. Mit Full-RBF “kann eine Anwendung nicht kontrollieren, ob eine eingehende Transaktion durch Full-RBF weitergeleitet wurde” oder nicht, weshalb sie “annehmen muss, dass jede eingehende Transaktion von einer Partei, zu der kein Vertrauensverhältnis besteht, durch Full-RBF ersetzt werden kann.” Das Sicherheitsmodell ändert sich fundamental: Nicht nur die Miner können angreifen, sondern “jeder, und das mit einem einfach zu benutzenden Interface.” Damit scheitern die bisherigen Modelle der Risikoanalyse.

Die Folge: “Wir von Muun werden ausgehende Lightning-Zahlungen für mehr als 100.000 User ausschalten müssen, was derzeit einen guten Anteil an allen nicht-treuhänderischen Lightning-Zahlungen ausmacht.”

Full-RBF, wie von Core für Version 24.0 geplant, würde damit Lighting noch stärker in ein System von Treuhand-Wallets drücken. Auch gut gemeinte Updates können verheerende Nebenwirkungen haben.

Ändert Full-RBF überhaupt wirklich etwas?

In der Mailing-List folgt darauf natürlich eine Diskussion. Nicht jeder teilt Darios Bedenken.

David Harding, der technische Autor von Bitcoin Core, erklärt, dass Full-RBF standardmäßig ausgeschaltet sei. Es gebe Pläne einiger Entwickler, dies standardmäßig zu aktivieren, doch diese stehen für Version 24.0 nicht zur Debatte. Das Upgrade ändere daher “die Ersetzbarkeit von Transaktionen in keiner signifikanten Weise.”

Ähnlich argumentiert Bitcoin-Core-Entwickler Pieter Wuile. Jeder, der sich mit Bitcoin auskenne, könne schon heute Full-RBF einrichten. Der Entwickler Luke Dashjr ergänzt, dass seine Software, Bitcoin Knots, bereits seit langem Full-RBF integriert habe und User seit langem Full-RBF anwenden könnten. Die Risikoanalysen von Anwendungen, die mit unbestätigten Transaktionen arbeiteten, vermittelten lediglich ein falsches Gefühl der Sicherheit.

Andere in der Mailing-List bestätigen dagegen die Sorge von Dario. Etwa John Carvalho vom Gutscheinkartenhändler Bitrefill. Carvalho erklärt, dass unbestätigte Transaktionen mit “einem hochgradig managbaren Risiko einhergehen, weshalb Händler Best-Practice-Methoden nutzen” und in der Praxis unbestätigte Transaktionen mit demselben Erfolg, aber weniger Komplexität als Lightning akzeptieren. RBF “verursacht mehr Probleme, als es löst”.

Die Diskussion kam bisher aber zu keinem Ergebnis. Es scheint unter den Entwicklern zwei Parteien zu geben: Die eine hält unbestätigte Transaktionen für grundsätzlich unsicher, meint, User könnten bereits heute per Full-RBF betrügen, und verlangt, für solche Anwendungen Lightning zu verwenden. Die andere Seite erkennt diese Probleme und Ziele an sich an, möchte aber, dass unbestätigte Transaktionen da, wo sie beherrschbar sind, auch beherrschbar bleiben.

Was bedeutet ‘ehrlich’?

Jeremy Rubin versucht, diesen Graben, der sich durch die Entwickler zieht, auf eine fundamentalere Weise einzuordnen. Er beginnt mit einem Zitat aus dem Bitcoin-Whitepaper, in dem Satoshi beschreibt, wie die “ehrlichen Knoten” sich gegen einen Angriff feindlicher Knoten behaupten. Damit die Blockchain sicher ist, sei eine Mehrheit der ehrlichen Knoten notwendig.

Dieses Konzept der “ehrlichen Knoten” hat seitdem immer wieder für Verwirrung gesorgt, da es einen moralischen Begriff zum Bestandteil einer technischen Analyse macht, ohne zu definieren, was konkret gemeint ist. Jeremy versteht “ehrlich” so, “dass man einer vorher spezifizierten Regel folgt, ob rational oder nicht”, während andere “ehrlich” mit “rational” gleichsetzen: Ein ehrlicher Knoten macht das, was profitabel ist.

Viele Protokoll-Entwickler streben danach, das ehrliche Verhalten rational zu machen, indem sie vorsichtig Anreize setzen. Dies sei in der Theorie eine gute Idee, meint Jeremy. In der Praxis gebe es allerdings widersprüchliche Vorstellungen davon, welches “ehrliche Verhalten” gut für das Netzwerk sei.

Die “NoRBF Crowd”, fährt er fort, “möchte offenbar an der Vorstellung festhalten, es gebe eine ehrliche Mehrheit, die keine Transaktionen ersetzt, wenn dies verlangt wird.” Die RBF-Crowd hingegen, könnte man ergänzen, geht von einer rationalen Mehrheit aus, die alles tut, was Profite bringt. Die Unterschiede zwischen diesen beiden Anschauungen sind gewaltig. Für die eine sind die Risiken durch “rationale, aber unehrliche Akteure” beherrschbar. Für die andere nicht.