Die Demokratisierung des Double Spends? Das kontroverse Update “Opt in RBF” wird Teil von Core 0.12

Ein Update mit dem obskuren Titel “Opt in RBF” sorgt derzeit für Streit. Ab Core 0.12 soll es möglich sein, eine Transaktion durch eine Gebühr rückgängig zu machen, sofern sie noch nicht bestätigt wurde. Ein Bruch mit den Grundwerten des Bitcoins – oder eine sinnvolle Erweiterung der Bitcoin-Software?

Mit ein Grund, weshalb “Opt in RBF” für so viel Wirbel sorgt, sollte der Unmut mit der “Governance” des Bitcoin-Protokolls sein. Während sich die Kernentwickler weigern, die von der Community seit langem geforderte Erhöhung der Blockgröße ins Protokoll zu bringen, haben sie ohne jede öffentliche Diskussion “Opt in RBF” integriert – obwohl dieses Feature von der Community heftig abgelehnt worden war, als Peter Todd zum ersten Mal versucht hatte, es durchzusetzen.

Allerdings sollte die Diskussion des einen Updates – der Blocksize – nichts mit der Diskussion des anderen Updates – Opt in RBF – zu tun haben. Auch die “Kommunikation” hat nichts in der Diskussion eines Updates verloren und sollte nicht, wie es so oft in der Politik geschieht, als Blendgranate dienen, die eine sachliche Diskussion unter einem “Wir müssen an unserer Kommunikation arbeiten” verschleiert. Es kommt weder auf die Regierungsform noch auf die Kommunikation noch auf die handelnden Akteure an, sondern einzig auf die Argumente und Meinungen zur Sache. Alles andere führt nur zu Streit, Vereinfachung, Populismus, Trotz und Fanatismus.

Dass “Replace by Fee” Emotionen schürt, ist jedoch kein Wunder. Schließlich geht es um eine der heiligen Kühe des Bitcoins: den Double Spend. RBF bedeutet, dass nicht mehr wie bisher die Transaktion, die zuerst gesehen wurde, in die Blockchain eingeht, sondern die Transaktion mit der höheren Gebühr. Bisher läuft es so ab, dass die Miner die Transaktion, die zuerst bei ihnen ankommt, in einen Block stecken. Ein double spend, der danach bei den Minern ankommt, wird ignoriert. Mit RBF soll dagegen nicht die zuerst gesehene Transaktion in den Block eingehen, sondern die mit der höchsten Gebühr. Dies macht es möglich, eine unbestätigte Transaktion durch eine Transaktion mit höheren Gebühren zu ersetzen.

Die Änderung wurde von Peter Todd entworfen und hat es nun, nach einigen Monaten der Analyse, in den Code des nächsten Core-Updates v.0.12 geschafft. Laut dem ursprünglichen Proposal wird RBF im April 2016 aktiviert werden.

Ist RBF nun ein Bruch mit den Kerneigenschaften des Bitcoins – oder eine sinnvolle Erweiterung des Protokolls? Die Meinungen dazu sind gespalten.

Contra RBF

Wie stets tummeln sich die Lager der Kritiker von allem, was die Kernentwickler machen, auf r/btc. Sie sind heftig empört darüber, dass Opt-in RBF es so still und leise ins Protokoll geschafft hat, während das wichtigere Update – die Erhöhung der Blocksize – auch nach monatelanger öffentlicher Diskussion kaum einen Schritt weiter gekommen ist. Aber auch inhaltlich gibt es schwere Kritik an Replace-by-Fee.

RBF bedeutet, dass man eine entsprechend gekennzeichnete Transaktion widerrufen kann, indem man eine zweite Transaktion mit (höheren) Gebühren absendet – sofern die erste Transaktion noch nicht bestätigt wurde. Die Kritiker sagen nun, RBF zerstöre die Möglichkeit, Transaktionen ohne Bestätigung zu empfangen (wie es etwa BitPay macht) und greife die Grundfesten des Bitcoin-Protokolls an: es zerstört zwei Basiseigenschaften von Transaktionen – ihre Irreversibilität und Resistenz gegen Double-Spends. Mit RBF werde der Double-Spend – also das doppelte Ausgeben eines Bitcoins – zum Basis-Bestandteil von Bitcoin Core.

RBF schade, so die Kritiker, allen, die Bitcoins ohne Bestätigung akzeptieren. Beispielsweise Webseiten, auf denen man etwas gegen Bitcoins herunterladen kann, Zahlungsdienstleistern, die Händlern sofort eine Freigabe schicken, den Betreibern von Bitcoin ATMs – die sofort Bargeld gegen Bitcoins wechseln – sowie allen, die Bitcoins “Face-to-Face” kaufen. Man kann im Café nicht einfach eine Stunde warten, bis ein Bitcoin bestätigt wurde.

Die Idee hinter RBF finden die Kritiker fundamentalistisch: Weil unbestätigte Transaktionen generell nicht sicher sind, aber dennoch akzeptiert werden, müsse man sie noch unsicherer machen, damit Händler mit der schlechten Angewohnheit brechen, sie dennoch zu akzeptieren. Die bisher funktionierenden Maßnahmen gegen Double-Spends werden durch RBF zunichte gemacht. So ähnlich, als würde man jemandem, der schlecht sieht, die Augen ausreissen, damit er nicht auf die Idee kommt, ohne Brille Autofahren zu können.

Alles in allem, so die Kritiker von RBF, sei dieses Update nicht nur unnötig und unerwünscht, da es keinen Nutzen bringe, sondern schädlich für zahlreiche Akteure im Bitcoin-Ökosystem. Dass die Kernentwickler ein Update, das unnötig mit den wichtigsten Elementen des Bitcoins bricht, ohne jede Diskussion ins Protokoll bringen, während sie bei den wirklich wichtigen Dingen – der Blocksize – zögern und zaudern und verhindern, disqualifiziere die Kernentwickler endgültig. Das einzig Gute an RBF sei, so die Kritiker, dass es alternativen Clienten wie BitcoinXT oder BitcoinUnlimited Auftrieb geben wird.

Pro RBF

Die meisten Argumente der Kritiker können von Verteidigern von RBF wie Gregory Maxwell und Peter Todd jedoch entschärft werden. Denn anders als von den Kritikern behauptet, hat RBF durchaus seinen Nutzen. Nicht nur, weil es praktisch ist, einer Transaktion, so sie denn im Nirwana der unbestätigten Transaktionen hängengeblieben ist, eine zweite Chance zu geben. Sondern auch und vor allem für das Scalability-Thema.

Peter Todd schrieb in seinem BIP für RBF:

Full-RBF hat signifikante Vorteile für die Effizienz gegenüber Alternativen wie FSS-RBF oder Child-Pays-For-Parent. Diese betreffen eine weite Bandbreite üblicher Transaktionsmuster wie “fee-bumping” oder mehrere sequenzielle Zahlungen, wie auch Smart Contracts Protokolle wie für Payment-Channels und Auktionen. Mit Unterstützung der Miner würde die weitere Bitcoin-Community die Blockchain effizienter nutzen und mehr Transaktionen je Sekunde in weniger Blockchain-Raum bringen.

Eine effizientere Nutzung der Blockchain sollte die Basis für jede weitere Skalierbarkeit sein. So, wie die Reduzierung des Stromverbrauchs die Basis für die Energiewende ist und wie die Reduktion von Abfall die Basis für einen umweltschonenden Konsum ist. Leider geht sehr viel von der  Arbeit an den Details, die Bitcoin effizienter machen, in den Rufen nach einer Erhöhung der Blockgröße unter.

Auch diejenigen, die sagen, RBF zerstöre grundlegende Kerneigenschaften des Bitcoins, sind auf dem Holzweg. Denn es war niemals eine Eigenschaft des Bitcoins, dass unbestätigte Transaktionen irreversibel und sicher sind. Wer dies meint, verkennt den ganzen Sinn der Miner und der Blockchain. Die Kerneigenschaft des Bitcoins ist es eben, dass Transaktionen NACH einer (oder nach mehreren) Bestätigung(en) sicher und irreversibel sind. Dies wird durch RBF nicht geändert. Tatsächlich gibt es auch schon vor RBF double spends von unbestätigten Transaktionen. Nur große Zahlungsdienstleister wie BitPay können diese halbwegs vernünftig erkennen, indem sie das Netzwerk durch mehrere Nodes permanent analysieren. Die Anbieter mancher Glücksspiele hingegen nehmen die Double Spends als Geschäftsrisiko in Kauf.

RBF ist, wenn überhaupt, eine Demokratisierung des Double Spends unbestätigter Transaktionen: während der double spend vorher nur Leuten möglich war, die genügend technische Expertise haben, um Transaktionen entsprechend zu streuen, wird er nun zum Basiselement der Clients. Darüber hinaus wurde nicht, wie von Peter Todd ursprünglich gewünscht, “Full RBF” integriert, sondern “Opt In RBF”. Dieser kleine, aber wichtige Unterschied bedeutet, dass Transaktionen, die mit RBF gesendet werden, gekennzeichnet werden. Wallets können mit sehr geringem Aufwand erkennen, ob eine Transaktion RBF ist oder nicht. RBF-Double-Spends können somit leicht verhindert werden, indem man für entsprechende Anwendungen keine RBF-Transaktionen akzeptiert. BlockCypher, ein Dienstleister, der hilft, unbestätigte Transaktionen zu erkennen, hat seine Software bereits am Wochenende aktualisiert. RBF wird also NICHT zu einer Flut akzeptierter Double Spends führen.

Fazit

Natürlich ist das Thema komplizierter, als hier dargestellt. Die Möglichkeit, per RBF double spends auszuführen, ist zwar längst nicht so gefährlich, wie die Kritiker meinen, aber sie stiftet doch Verwirrung und stellt beispielsweise für unerfahrene Face-to-Face Trader – insbesondere Leute, die über diesen Weg an ihre ersten Bitcoins kommen – ein nicht geringes Risiko dar.

Weiter ist (von meiner Seite) nicht genau zu sagen, inwieweit RBF tatsächlich das Netzwerk effizienter macht. Zahlreiche Fragen sind bisher offen. Etwa die Folgen für die Miner. Werden diese beispielsweise Transaktionen, die als RBF gekennzeichnet sind, grundsätzlich nicht akzeptieren, weil sie hoffen, dass diese durch Transaktionen mit höheren Gebühren ersetzt werden? Wird RBF einen “fee-market” – von den einen erwünscht, von den anderen abgelehnt – etablieren, der die Gebühren, um eine Transaktion in die Blockchain zu bringen, womöglich deutlich nach oben schraubt? Und: was passiert, wenn RBF einmal zum Standard wird, wenn also alle Transaktionen durch Gebühren ersetzt werden können – wird dann das Empfangen unbestätigter Transaktionen tatsächlich unmöglich? Zuletzt: rechtfertigt es das Resultat wirklich, die Komplexität von Wallets und des Netzwerkes zu erhöhen, indem man nun zwei Gattungen von Transaktionen einführt?

All das sind offene Fragen, die vermutlich erst beantwortet werden, wenn RBF wirklich im Einsatz ist. So wenig es für die Kernentwickler spricht, dass sie diese einschneidende und verwirrende Änderung ohne öffentliche Diskussion ins Protokoll einfügen, so wenig gereicht es deren Kritikern zum Ruhm, dass sie eine verkürzte Perspektive auf RBF zum Anlass nehmen, um gegen die Kernentwickler zu stänkern. Denn RBF ist zwar tatsächlich ein Update, da es vieles verändert, aber der Teufel steckt nicht im Großen und Ganzen, sondern, wie allgemein bekannt ist, im Detail.

About Christoph Bergmann (1086 Articles)
Das Bitcoinblog wird von bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder. Wenn Ihnen das Blog gefällt, freuen wir uns über Spenden an 1BvayiASVCmGmg4WUJmyRHoNevWWo5snqC. Jeder Satoshi wird dazu verwendet, um das Blog besser zu machen. Weitere Infos, wie Sie uns unterstützen können, finden Sie HIER. Gastbeiträge sind ebenfalls willkommen. Meinen öffentlichen PGP-Schlüssel sowie den Bitmessage-Schlüssel finden Sie HIER

5 Comments on Die Demokratisierung des Double Spends? Das kontroverse Update “Opt in RBF” wird Teil von Core 0.12

  1. Christoph Staudinger // 30. November 2015 at 16:06 // Reply

    Danke für den guten Artikel! Habe ich (wie schon öfters) noch nicht gewusst und war ausgewogen und informativ.

    Nur im 4ten Absatz habe ich etwas zu bemängeln:
    “dass nicht mehr wie bisher die Transaktion, die zuerst gesehen wurde, in die Blockchain eingeht, sondern die Transaktion mit der höheren Gebühr” ist glaube ich nicht ganz richtig.
    Soweit ich das verstanden habe, darf jeder Miner, der gerade einen Block gefunden hat, selber entscheiden, welche Transaktionen er in den Block einbaut. Es gab auch schon Miner, die einfach keine Transaktionen in ihre Blöcke gerechnet haben, um schneller mit der Erstellung fertig zu sein (oder weil vielleicht ihre Software fehlerhaft war)

    Zum Thema Kernentwickler:
    Vielleicht ist es wirklich schlecht, dass sie alle von einer Firma bezahlt werden, die ein eigenes Produkt pushen will. Weil auch diese Änderung dürfte positiv für Sidechains sein. (stimmt doch, oder?)

    Eventuell sollte die Comunity anfangen, die Entwickler selber zu bezahlen…
    Und mehrere, gleichberechtigte Clients wären natürlich auch zu begrüßen!

    • Klar dürfen die Miner das auch künftig selbst entscheiden. Sie können auch eine Ersatz-Transaktion ablehnen.

      Aber derzeit ist es eben so, dass eine Transaktion, wenn sie einmal einen Miner erreicht, DIE Transaktion ist. Mit RBF kann diese Transaktion, solange sie nicht bestätigt ist, durch eine zweite Transaktion mit höheren Gebühren ersetzt werden.

      Zumindest habe ich es soweit verstanden.

      Mit den Kernentwicklern stimme ich Ihnen zu. Ich teile zwar keine Blockstream-Verschwörungstheorien, aber prinzipiell ist es nie gut, wenn eine Firma maßgebliche Protagonisten der Client-Entwicklung verbindet. Je mehr Vielfalt, desto besser. Es gibt alternative Clienten zu Core, wie bitcoind, bitcoinunlimited, bitcoinxt. Schwierig ist derzeit eben, dass die meisten der alternativen Clienten drohen, eine Hard Fork auszulösen.

      Aber langfristig sollte sich Bitcoin am besten so ähnlich wie Linux entwickeln.

  2. Guter Artikel! Ich habe von dem Thema schon gehört, aber ein Detail verstehe ich noch nicht ganz:

    Wie können durch diese Änderung Transaktionen rückgängig gemacht werden? Wenn man dieselbe Transaktion noch einmal schickt, mit höheren Gebühren, wird zwar die erste Transaktion damit ersetzt, aber die Ziel-Adresse und der Betrag müssen doch unverändert bleiben? Sonst würde doch eine zweite valide Transaktion erstellt werden, und nichts wird ersetzt?

    Habe ich da etwas falsch verstanden?

  3. Durch RBF wir die Nutzung von Bitcoin so verkompliziert, daß einige Menschen abgeschreckt werden, Bitcoin überhaupt zu nutzen. Wie kann so etwas ohne einen demokratischen Prozeß eingeführt werden? Zeit das Core-Team abzulösen.

    Wenn ich Dinge mit Bitcoins kaufe wird mir die Leistung oft schon gutgeschrieben, z.B. Aufstockung meines Guthabens für einen VoIP Account, bevor die erste Bestätigung eintrifft. Das scheint bald vorbei sein.

    Was kann man tun um RBF rückgängig zu machen? Nicht auf Core 0.12 umsteigen?

1 Trackback / Pingback

  1. “Ich habe in 20 Jahren Open Source nicht erlebt, dass sich die Entwicklung so weit von den Wünschen der User abkoppelt.” | BitcoinBlog.de – das Blog für Bitcoin und andere virtuelle Währungen

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s