RBF kommt in die Wallets

Das umstrittene Feature Replace-by-Fee (RBF) ist bereits seit einigen Monaten in Core. Nun beginnen die Wallets, RBF zu implementieren.

Replace-by-Fee ist eines der kontroversesten Features der neueren Bitcoin-Entwicklung. Denn RBF erlaubt es, eine Transaktion zu verändern, solange sie abgesendet, aber noch nicht bestätigt ist. Für die einen ist dies Vandalismus, da es Transaktionen ohne Bestätigung noch unsicherer macht; für die anderen bestätigt es nur die längst überfällige Tatsache, dass man niemals unbestätigte Transaktionen empfangen soll und fügt dem die Möglichkeit hinzu, die Gebühr für diese zu erhöhen, um die Bestätigung zu beschleunigen.

Für GreenAddress “gibt es keine Nachteile, sondern nur Vorteile, und daher unterstützen wir RBF natürlich.” Die Wallet-Entwickler aus Malta gehören zu den ersten, die RBF implementiert haben. Das Feature ist bereits live, läuft aber weitgehend unter der Haube: es ist standardmäßig an und kann in den Optionen ausgeschaltet werden.

Mit "bumb fees" kann man die Gebühren einer unbestätigten Transaktion nachträglich erhöhen.

Mit “bumb fees” kann man die Gebühren einer unbestätigten Transaktion nachträglich erhöhen.

Anders als von vielen befürchtet, kann man Transaktionen mit RBF nach dem Absenden keinen neuen Empfänger zuweisen, sondern lediglich die Gebühren ändern. Sprich: Man hat eine Transaktion abgesendet, die Gebühren reichen nicht aus – weil man zu geizig war oder in einen Stau geraten ist – und so kann man rückwirkend die Gebühren erhöhen.

Noch auf dem Weg, RBF zu integrieren, ist Electrum. Die Entwickler der beliebten Wallet für den Desktop haben den Code bereits gemerged, so dass RBF wohl ab der nächsten Version enthalten sein wird. Da das Feature “fee bump” genannt wird, ist zu erwarten, dass man wie bei GreenAddress nachträglich nicht die Empfänger, sondern lediglich die Gebühren verändern kann. Eine kontroverse Diskussion im GitHub-Kanal entstand darüber, ob Electrum explizit anzeigen soll, ob eine Transaktion RBF aktiviert hat, um dem User zu signalisieren, dass ein Double Spend jederzeit möglich ist. Die Electrum-Entwickler haben sich dagegen entschieden, da dies fälschlicherweise so zu verstehen sein könnte, dass Nicht-RBF-Transaktionen sicher seien.

Die Android-Wallet Mycelium hingegen handhabt RBF genau andersherum: Sie zeigt es an, wenn eine Transaktion als RBF gesendet wurde, erlaubt aber gegenwärtig noch nicht, die Gebühren durch RBF zu erhöhen. Allerdings ist dies wohl für die kommenden Monate erlaubt.

Auch die Online-Wallet coinb.in hat bereits RBF implementiert. Allerdings nicht, wenn man die Wallet benutzt, sondern nur, wenn man eine Rohtransaktion bildet. Wie es genau möglich sein soll, von dort ausgehend die Transaktion nachträglich zu verändern, erschließt sich mir jedoch nicht genau.

Ob man das Feature mag oder nicht – RBF wird Teil der Wallets werden. Die rückwirkende Erhöhung der Gebühren wird helfen, einen Gebührenmarkt aufzurichten, in dem Transaktionen angesichts voller Blöcke mit sich ständig erhöhenden Gebühren um die knappen Bestätigungen konkurrieren können. Darüber hinaus erlaubt RBF es auch, die Empfänger einer unbestätigten Transaktion rückwirkend zu ändern. Dies kann genutzt werden, um Double Spends zu machen, aber dies kann auch helfen, unbestätigte Transaktionen besser zu organisieren und damit Platz auf der Blockchain und Gebühren zu sparen. Ob RBF wie befürchtet unbestätigte Transaktionen kaputtmacht oder den Wallets hilft, flexibler die richtigen Gebühren zu finden, wird sich in den kommenden Monate zeigen.

About Christoph Bergmann (986 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 RBF kommt in die Wallets

  1. RBF bietet Sicherheit, dass eine Transaktion nicht unnötig lange in der Schwebe hängen muss, weil sie mit einer unzureichenden Fee gesendet wurde. RBF ist optional und man kann lediglich die Gebühr erhöhen.

    Ich verstehe nicht, wie das die Gefahr von Double Spendings erhöht.

    • Im Prinzip kann man mit RBF nicht nur die Gebühren erhöhen, sondern auch den Empfänger einer Transaktion. Dies ist noch nicht Teil von Wallets, aber wenn dies in die GUI eingeht, kann man mit RBF z. B. eine Transaktion mit niedrigen Gebühren absenden und noch eine halbe Stunde später zu sich selbst umbiegen. Ohne RBF ist dies deutlich schwieriger zu machen.

      • Jens K. // 23. May 2016 at 18:36 //

        Ok, danke für die Antwort. Dann kann man mit dieser neuen Art von Transaktion wohl nicht nur die Gebühr erhöhen, sondern auch den Empfänger ändern. Ein Wallet sollte ggf. alle unbestätigten Transaktionen deutlich als unsicher markieren.

  2. Im Text steht unter anderem das hier :”Anders als von vielen befürchtet, kann man Transaktionen mit RBF nach dem Absenden keinen neuen Empfänger zuweisen, sondern lediglich die Gebühren ändern. Sprich: Man hat eine Transaktion abgesendet, die Gebühren reichen nicht aus – weil man zu geizig war oder in einen Stau geraten ist – und so kann man rückwirkend die Gebühren erhöhen.”

    • eParanoid // 24. May 2016 at 22:22 // Reply

      Wenn ich es richtig verstanden habe, bezieht sich diese Aussage nur auf die Implementierung in der Wallet GreenAddress und nicht auf die grundsätzlichen Möglichkeiten von RBF.

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