Newsticker

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

Der Mond steigt prächtig in die Höhe. Bild von Don Owens via flickr.com. Lizenz: Creative Commons

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.

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

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

  1. Eigentlich bin ich selbst Verfechter von 0-conf Transaktionen und war gegen RBF, allerdings muss man anerkennen, dass Full-RBF eine logische Folgerung einer Blockchain ist, die von rationalen Akteuren fortgeschrieben wird. Ob nun der offizielle Client diese Möglichkeit mitbringt oder nicht, ist ziemlich egal, denn sobald Gebühren tatsächlich einen Großteil der Einnahmen ausmachen sollten (was heutzutage nicht der Fall ist), werden Miner bzw. Pools ihre eigene Software nutzen, um den größtmöglichen Profit zu erwirtschaften.

    Bei Bitcoin kommt erschwerend hinzu, dass die Block Time bei 10 Minuten liegt und eine Transaktion selbst mit ausreichenden Gebühren im Schnitt über 5 Minuten braucht, bis sie bestätigt wird und eben die beschränkte Blockgröße, die nicht unbedingt alle Transaktionen, die darauf warten, bestätigen kann. RBF und CPFP verstärken diesen Effekt, aber im Prinzip ist er bei jeder Blockchain reproduzierbar, solange eine Transaktion nicht final bestätigt ist, denn erst dann greifen die Protokollmechanismen.

    Man kann sich streiten, ob die 10 Minuten Block Time bei Bitcoin heute noch angemessen sind, für Echtzeitzahlungen müsste diese aber unter 10 Sekunden liegen und ich halte das abseits der technischen Fragen für politisch nicht durchsetzbar nach den wahnwitzigen Blocksize Kriegen der letzten Jahre. Insbesondere einige im Artikel erwähnten Entwickler wie z.B. Luke DashJr sind da in meinen Augen eher Extremisten.

  2. >Was bedeutet ‚ehrlich‘?

    Da gibt es keine Verwirrung. Satoshi hat im Whitepaper klipp und klar definiert was ein ehrlicher Knoten(=Miner) zu tun hat, Kapitel 5

    – Er sendet TX an anderen Knoten weiter
    – Er packt Transaktionen in einen Block
    – Er sendet den Block nach erfolgreicher POW an alle anderen Nodes
    – Er akzeptiert nur Blöcke mit validen Transaktionen / keine double spends.

    Daraus kann man unehrliche Nodes gut ableiten:
    Alle Miner, die z.B.
    – akzeptierte Transaktionen zurückhalten
    – auf Dauer leere Blöcke schürfen
    – ihre Blöcke zurück halten in der Hoffnung unbemerkt eine längere Kette zu schaffen
    – gültige Blöcke ablehnen oder double spends akzeptieren

    • Lieber Hannes

      – Er sendet TX an anderen Knoten weiter

      Dafür gibt es im Protokoll schlichtweg keinen Anreiz, es ist Goodwill der Nodes oder man kümmert sich als User (und Händler!) selbst darum, dass die Transaktion so weit wie möglich verbreitet und wahrscheinlich zeitnah in einen Block aufgenommen wird.

      – akzeptierte Transaktionen zurückhalten

      Von wem akzeptierte Transaktionen? Am Ende zählen nur Transaktionen, die es in einen Block geschafft haben und dafür gibt es einen Anreiz in Form von Gebühren. Der Mechanismus ist das, was Bitcoin überhaupt ermöglicht hat. Ob er ausgewogen ist, steht auf einem anderen Blatt, aber Bitcoiner reden nicht gern darüber, ob sich ein signifikanter Gebührenmarkt entwickeln kann, der die Coinbase Rewards langfristig ersetzen kann, ich bin da persönlich sehr skeptisch und würde wollen, dass man offen darüber redet und Lösungsmöglichkeiten auslotet. Aber nach den Blocksize Kriegen bin ich ausgestiegen, da gefühlt eine handvoll Leute bestimmt, wohin sich Bitcoin entwickelt und die lautesten Claqueure wiederholen gefühlt ihre Meinung.

      – auf Dauer leere Blöcke schürfen

      Ein rational agierender Miner wird auch heute nur Transaktionen in seinen Block packen, die ihm statistisch mehr Profit bringen als der Nachteil der Propagation im Netzwerk ist und ein anderer Miner seinen konkurrierenden Block womöglich schneller propagieren kann, auf dem dann andere Miner aufbauen. „Uncle Blocks“ wie bei Ethereum gibt es nicht bei Bitcoin, eine Transaktion, die im unter-Promille Bereich des Coinbase Rewards bepreist ist, dürfte statistisch einfach nicht lohnend sein und einige Miner sehen sogar die gesamten Gebühren eines Blocks von derzeit meist unter 2%, oft sogar unter 1% als nicht lohnend an, um ihren Block voll zu machen.

      – ihre Blöcke zurück halten in der Hoffnung unbemerkt eine längere Kette zu schaffen

      Die Blockchain mit ihrem geleisteten Proof of Work hat eben ein System geschaffen, welches kein Vertrauen erfordert. Wer soll darüber wachen, wer das System „falsch“ nutzt? Die längste Kette ist gültig.

      – gültige Blöcke ablehnen oder double spends akzeptieren

      Da sehe ich keine Gefahr, denn jede Node prüft jeden Block auf ungültige Transaktionen, ein Miner kann keinen korrumpierten Block unterjubeln, auf dem ein anderer Miner aufbauen würde, denn sein Client wird ihn schlichtweg nicht akzeptieren.

Kommentar verfassen

%d Bloggern gefällt das: