Vor zwei Tagen wurde eine neue Version der am weitesten verbreiteten Bitcoin-Implementation, Bitcoin Core veröffentlicht. Version 24.0 enthält die Konfiguration mempoolfullrbf, die bereits seit einigen Wochen innerhalb der Bitcoin-Community rege diskutiert wurde. Es gab und gibt einige Argumente für und einige Argumente gegen die Einführung von "Full RBF", wie die Option umgangssprachlich abgekürzt wird. Wir möchten die Debatte in diesem Beitrag kurz zusammenfassen und direkt zu Beginn klarstellen, dass diese noch deutlich nuancierter ist, als man es in einem solchen Artikel darstellen könnte. Im Grunde gibt es dabei nämlich kein schwarz oder weiß und es gibt zahlreiche Facetten, die in die Diskussion einspielen.
Was ist (Full) RBF?
Replace-By-Fee (RBF) ist eine im BIP125 geregelte Richtlinie für Fullnodes, die es ihnen erlaubt, eine unbestätigte Transaktion in ihrem Mempool durch eine andere Transaktion zu ersetzen, die mindestens einen der gleichen Inputs ausgibt und eine höhere Transaktionsgebühr zahlt. Auf diese Weise kann beispielsweise der Ersteller einer Transaktion die Aufnahme dieser in einen Block durch eine nachträgliche Erhöhung der Gebühr beschleunigen. Alternativ kann er diese in gewisser Weise aber auch abbrechen, indem er die Inputs mit höherer Gebühr an sich selbst überweist, anstelle des ursprünglichen Empfängers. Nodes, die BIP 125 folgen, akzeptieren die neue Transaktion und entfernen die ältere Version aus ihrem Mempool.
Die RBF-Regeln können von verschiedenen Nodes unterschiedlich angewendet werden und es gibt mehrere Varianten. Die heute am weitesten verbreitete Form von RBF ist "opt-in RBF". Diese wurde bereits im Jahr 2015 in Bitcoin Core 0.12.0 und nachfolgenden Versionen implementiert und erlaubt es dem Ersteller einer Transaktion, zu signalisieren, dass er bereit ist, sie durch eine höher bezahlte Version ersetzen zu lassen. Eine alternative Form von RBF ist das derzeit diskutierte und nun in Bitcoin Core 24.0 eingefügte "Full RBF", welches es erlaubt, dass jede Transaktion ersetzt werden kann, egal ob sie nach BIP125 Ersetzbarkeit signalisiert oder nicht. Auf andere Varianten, wie etwa "First-seen-safe RBF" oder "Delayed RBF" werden wir nicht näher eingehen, da diese für die Debatte nicht wirklich wichtig sind.
Worin besteht die Kontroverse?
Die Kontroverse besteht im Wesentlichen darin, dass es im Bitcoin-Bereich Unternehmen gibt, die sich darauf verlassen, dass die überwiegende Mehrheit der Fullnodes sich weigert, Transaktionen, die sich nicht aktiv für die RBF-Option entschieden haben, abzulehnen. Auf diese Weise können die Businesses Transaktionen, die zwar bereits in das Netzwerk gesandt, aber noch nicht offiziell in einen Block aufgenommen wurden, als "inoffiziell bestätigt" betrachten und einen Handel abschließen. Mit "Full RBF" wird diese Option gewissermaßen zunichtegemacht.
Ein gutes Beispiel hierfür sind unter anderem die Bitcoin-Automaten von Chivo in El Salvador. Aktuell ist es so, dass einem Kunden, der am ATM BTC gegen US-Dollar eintauschen möchte, das Geld sofort ausgezahlt wird, sofern die entsprechende Einzahlungs-Transaktion RBF nicht aktiviert und ausreichend Transaktionsgebühren bezahlt hat, um mit hoher Wahrscheinlichkeit innerhalb der nächsten Blöcke in die Blockchain aufgenommen zu werden. Der Betreiber sieht die Wahrscheinlichkeit, dass bei der jeweiligen Transaktion doch noch etwas schiefgehen könnte, als relativ gering an und wertet die positive Nutzererfahrung durch die sofortige Auszahlung höher als das eigene Risiko, das Geld doch nicht zu erhalten. Alternativ müsste der Kunde vor dem Automaten warten, bis die Einzahlungs-Transaktion bestätigt wurde, was (wie wir wissen) je nach Transaktionsgebühr und Auslastung des Netzwerks auch mal mehrere Stunden dauern kann. Unternehmen wie Chivo sind sich des Risikos durch sogenannte "Zero-Conf Transaktionen" (noch nicht bestätigte Transaktionen) durchaus bewusst.
Gleichwohl entscheiden sie sich trotzdem aktiv dafür, um den Kunden möglichst hohen Komfort zu bieten. Diese Möglichkeit wird Chivo und anderen Händlern nun jedoch durch mempoolfullrbf mehr oder minder genommen. Dies war und ist im Grund der größte Kritikpunkt seitens der "Full RBF"-Gegner. Der bekannteste unter ihnen ist vermutlich der Entwickler John Carvalho, der sich immer wieder darauf beruft, dass Zero-Conf Transaktionen ein guter Weg für Händler sind, um Kundenbedürfnissen nachzukommen und dass Full RBF die Mempools weniger vertrauenswürdig mache, was letzlich dazu führe, dass es sowohl für Kunden als auch Businesses gefährlicher wäre, Bitcoin als Zahlungsmittel zu verwenden.
Aber warum wurde "Full RBF" dann trotzdem implementiert?
Gründe für "Full RBF"
Für die Einführung von Full RBF als Standardeinstellung bei Bitcoin Nodes sprechen mehrere Gründe. Zum einen ist es so, dass die Befürworter von Full RBF der Meinung sind, dass eine Bitcoin-Transkation erst dann auch wirklich eine solche ist, wenn sie in einen gültigen Block aufgenommen wurde. Die Verwendung von Zero-Conf Transaktionen führt Bitcoins Proof-of-Work-Mechanismus ad absurdum und geht mit entsprechenden Sicherheitseinbußen einher. Es werde ein falsches Gefühl der Sicherheit vermittelt, so einige Befürworter.
Die Bitcoin-Entwicklerin Gloria Zhao fasste zusammen:
"Full RBF ist der natürliche Zustand des Netzwerks. Der Sinn von Bitcoin-Blöcken, PoW, etc. ist es, Doppelausgaben zu verhindern; es gab nie eine Garantie für die Endgültigkeit unbestätigter Transaktionen. Wenn ein Miner zwei sich widersprechende Transaktionen erhält, ist die anreizkompatible Politik, diejenige zu nehmen, die ihm höhere Gebühren einbringt. Die Verwendung einer RBF-Richtlinie hilft den Nodes, ein genaueres Bild davon zu bekommen, welche Transaktion wahrscheinlich bestätigt wird. Die Sicherheitsannahme "Miner werden nett sein", wenn eine nicht-signalisierende Transaktion einen Konflikt mit höherer Feerate hat, ist deutlich schwächer als "Miner werden das Rationale tun".
Außerdem würden Händler durch "Full RBF" incentiviert mehr auf Lightning-Zahlungen anstelle von Zero-Conf Transaktionen zu setzen, erklären Teile der Pro-Fraktion. Auf diese Weise würde somit auch das Lightning-Netzwerk gestärkt, was ebenfalls als positiver Aspekt in die Debatte mit eingebracht wird. Es gibt Parteien, die grundsätzlich für "Full RBF" sind, aber die Meinung vertreten, dass man mit der Umsetzung noch warten hätte sollen. Das Lightning Netzwerk ist im Hinblick auf die User-Experience noch immer im Aufbau und es muss dem Großteil der Nutzer noch besser zugänglich gemacht werden. Die Akzeptanz von Zero-Conf Transaktionen ist im aktuellen Netzwerk-Zustand in der Praxis durchaus sicher genug. Man könne "Full RBF" auch erst später einführen, wenn die Netzwerkauslastung höher wird und das Lightning-Netzwerk einfacher nutzbar ist.
Standardmäßig ausgeschaltet
Ein wichtiger und erwähnenswerter Punkt in der Debatte ist der, dass mit Bitcoin Core 24.0 die Option mempoolfullrbf zwar eingeführt wurde, diese jedoch standardmäßig ausgeschaltet sei. Dennoch signalisiert das Entwicklerteam in gewisser Weise damit, dass es gut sei diese Option zu benutzen. Da Miner durch das Aktivieren der "Full RBF"-Option mehr Geld verdienen können und man davon ausgeht, dass diese rational handeln, ist davon auszugehen, dass dies von diesen auch so umgesetzt wird. Da die Mempools der Mining-Nodes auch diejenigen sind, auf die es in letzter Instanz ankommt, ist das Argument "die Option ist doch standardmäßig ausgeschaltet" für viele "Full RBF"-Gegner auch nur ein Scheinargument.
Fazit
Wie bereits eingangs erwähnt, hat die Debatte um die Einführung von mempoolfullrbf viele Facetten und noch deutlich mehr als in diesem Beitrag darstellbar. Im Wesentlichen gibt es drei Interessengruppen. Diejenigen, die "Full RBF" sofort umgesetzt haben möchten, diejenigen, die es grundsätzlich für eine gute Idee halten, aber derzeit noch keinen Grund sehen und diejenigen, die es für kompletten Unsinn halten. Jede der Diskussionsparteien, hat im Grunde mehr oder minder gute Argumente, um sich für die eigene und gegen die anderen Positionen auszusprechen. Nachdem die Option "Full RBF" jetzt in der neuesten Bitcoin Core Version jedoch implementiert ist, wird es vermutlich auch umgesetzt und die Unternehmen, die bisher auf Zero-Conf Transaktionen gesetzt haben, werden besser früher als später lernen müssen, damit umzugehen und das eigene Business-Modell anzupassen.
