Einen besseren und ausführlicheren Beitrag zu RBF und CPFP findet ihr mittlerweile auf der Webseite:
Moin zusammen!
Heute soll es mal um das Thema unbestätigte Transaktionen gehen. Oft melden sich besorgte Nutzer hier im Forum an und fragen sich was mit ihrer Transaktion passiert, wenn diese nicht bestätigt wird. Darum soll es im ersten Abschnitt gehen - zukünftige Fragen die in diese Richtung gehen kann man dann mit diesem Beitrag schnell beantworten.
Im zweiten Abschnitt geht es ins Detail zu RBF und CPFP. Ich kann mir vorstellen dass dies für manche etwas schwieriger zu verstehen ist, aber ich gebe mein bestes es anschaulich zu erklären.
Los geht’s!
Meine Transaktion wird nicht bestätigt! Muss ich jetzt nervös werden?
Nein. Wenn du die die Transaktion über einen beliebigen Block-Explorer findest (oft findest du dafür in deiner Wallet Software einen Link), musst du dir keine Sorgen machen.
Auch wenn dir deine Wallet den versendeten Betrag nicht mehr als Guthaben anzeigt sind deine Bitcoin bis zum Zeitpunkt der ersten Bestätigung (wenn die Transaktion in einen Block geschrieben wird) noch vollständig in deinem Besitz. Solange die neue Transaktion nicht in der Blockchain steht hat sie auch nicht statt gefunden. Der Betrag wird dir nur zur Übersichtlichkeit ausgeblendet um Verwirrung zu vermeiden.
Hier und auch generell kann es hilfreich sein das Konzept von UTXO zu verstehen, da ich in diesem Beitrag öfters von UTXO spreche und voraussetze dass klar ist, was ich damit meine.
Der Grund warum die Transaktion so lange auf sich warten lässt ist die von dir eingestellte Netzwerkgebühr. Ist diese zu niedrig eingestellt wirst du von anderen Netzwerk-Teilnehmern sozusagen „überboten“ und deine Transaktion muss sich hinten anstellen. Hier wären wir auch schon beim Thema Mining, über das du dich in diesem Blocktrainer Wissen Artikel und auch hier im Forum weiter informieren kannst.
Standardmäßig (von Konfiguration der Node abhängig) werden unbestätigte Transaktionen nachdem sie zwei Wochen im Mempool gewartet haben automatisch aus diesem entfernt. Wichtig: Es gibt nicht „den zentralen“ Mempool, sondern jede Node hat jeweils eine eigene Kopie des aktuellen Mempools - ähnlich wie mit der Blockchain auch.
Um das nochmal ganz deutlich zu machen: Es gibt keinen „Limbo“! Eine unbestätigte Transaktion „schwebt“ nicht im „nirgendwo“ umher und eure Bitcoin laufen nicht Gefahr irgendwo vergessen zu werden. Bitcoin ist Atomic, also entweder findet die Transaktion statt, Bitcoin weg, oder sie findet nicht statt, Bitcoin noch da.
Also: Spätestens nach zwei Wochen - sollte eure Transaktion bis dahin nicht doch noch bestätigt werden - könnt ihr sie wie gewohnt neu erstellen, diesmal mit einer effizienteren Gebühr.
Hierzu empfielt es sich immer vor dem Erstellen einer Transaktion mit Explorern wie mempool.space zu überprüfen wie die Situation im Mempool aktuell aussieht - also einen Blick auf den Wetterbericht werfen!
In diesem Moment sieht dieser zum Beispiel so aus:
Auch die anderen Statistiken sind sehr interessant und hilfreich bei der Gebühren-Wahl, aber gerade für Anfänger reicht diese grobe Empfehlung vollkommen. Mit den hier angegeben 7 sat/vB würde man ohne Probleme in den nächsten Block kommen. Mit 2 sat/vB wüde man ohne Probleme innerhalb der nächsten Stunden in einen Block kommen - vorraussichtlich!
Doch manchmal hat man einfach keine Zeit oder Lust zu warten und möchte die feststeckende Transaktion so schnell wie möglich in einen Block bekommen:
Replace-By-Fee (RBF)
Kommen wir zur ersten Möglichkeit die Netzwerkgebühr einer Transaktion nachträglich zu erhöhen, die vom Sender der Transaktion ausgeführt wird.
Erstmal eine trockene Definition: RBF ist zunächst mal eine Node-Konfiguration die es erlaubt unbestätigte Transaktionen im Mempool nachträglich mit einer neuen Transaktion zu ersetzen, die mindestens einen gleichen Input hat und eine höhere Netzwerkgebühr zahlt.
Es gibt mehrere Implementationen und Regeln für RBF - ich spreche hier jetzt aber vom gängigsten opt-in RBF aus BIP125, das von den meisten modernen Wallets unterstützt wird. Hierbei muss sowohl die Feerate (sat/vB) als auch die totale Fee (in BTC) größer als in der ursprünglichen Transaktion sein. Dann werden die Miner diese neue Transaktion - anstatt der alten - in einen Block schreiben, da sie mit dieser mehr Bitcoin verdienen. Wird die neue RBF Transaktion dann bestätigt ist die alte, die bis zu diesem Zeitpunkt noch im Mempool gewartet hat, ungültig, da die Inputs dieser Transaktion nicht mehr unspent sind (UTXO - STXO). Um die alte Transaktion müssen wir uns also keine Sorgen mehr machen.
Um RBF zu nutzen muss der Ersteller der Transaktion, wie der Name „Opt-in“ schon verrät, in der Transaktion signalisieren dass er die Funktion (gegebenenfalls) nutzen möchte. Ihr müsst euch also bereits im Vorhinein auf die Funktion vorbereiten, sonst könnt ihr sie nicht nutzen. Es ist daher empfehlenswert in jeder Transaktion RBF zu signalisieren - was eure Wallet wahrscheinlich sowieso schon die ganze Zeit für euch gemacht hat.
Auf mempool.space kann man eine solche Transaktion ganz einfach am grünen RBF Icon erkennen. Probiert es mit euren alten Transaktionen einfach mal aus:
Hier ein kleiner Überblick welche der gängigen Software BIP125 RBF unterstützt (jeweils verlinkt):
Auch wenn ihr mit der BitBox App oder Ledger Live RBF nicht interaktiv, also in der App, verwenden könnt, haben eure Transaktionen den benötigten RBF Flag trotzdem. Ihr könnt also eure Hardware Wallet einfach mit z.B. Sparrow oder Electrum verwenden und die Transaktion beschleunigen.
Zur Debatte und Hintergrund von „Full RBF“ siehe diesen Beitrag auf der Webseite:
Child pays for parent (CPFP)
Mit dieser Methode kann der Empfänger einer Transaktion die Netzwerkgebühr nachträglich erhöhen. Es handelt es sich hier im Gegensatz zu RBF nicht um eine Funktion die Teil des Protokolls ist sondern nur um reine Strategie-Entscheidungen der Miner.
Der Empfänger der Transaktion erstellt eine neue Transaktion in der er einen Output der alten Transaktion ausgibt. Diese Transaktion kann also nur bestätigt werden, wenn die alte Transaktion zunächst auch bestätigt wird, da schließlich UTXO aus dieser alten Transaktion benötigt werden.
Die deutlich höhere Gebühr in der neuen Child-Transaktion gibt den Minern einen Anreiz beide Transaktionen in einen Block zu schreiben, da sie nur so an die hohe Gebühr in der Child-Transaktion ran kommen.
Das kann nur funktionieren, wenn die Parent-Transaktion im entsprechenden Block „früher“, also vor der Child-Transaktion steht. Hierfür haben die meisten Miner ancestor feerate mining in der Auswahl ihrer Transaktionen implementiert, das genau darauf achtet. Die Miner halten also aktiv nach CPFP Transaktionen Ausschau.
Beispiel:
Parent Transaktion - wird nicht bestätigt:
| Input | → | Output | Fee |
|---|---|---|---|
0.01 |
0.0099 |
0.0001 |
|
| Jemand schickt uns 0.01 BTC | Neuer UTXO den wir kontrollieren | Gebühr zu niedrig |
Child Transaktion - wird zusammen mit Parent Transaktion sofort bestätigt:
| Input | → | Output | Fee |
|---|---|---|---|
0.0099 |
0.0089 |
0.001 |
|
| UTXO aus der Parent Transaktion | Neuer UTXO an eigene Adresse | Gebühr deutlich höher |
Auch hier helfen die Block Explorer bei der Veranschaulichung. Diese Transaktion hat durch CFPF z.B. eine effektive Feerate die etwas höher ist als die ursprüngliche:
Auf den ersten Blick kann man CPFP also nur als Empfänger einer Transaktion nutzen. Aber: Hat eure Transaktion Change, also Bitcoin die an eine Wechseladresse zurück an euch gehen, dann könnt ihr diesen UTXO nutzen und damit auch CPFP, da ihr indirekt auch „Empfänger“ der Transaktion seid. Verbraucht ihr einen UTXO vollständig, also ohne Change, könnt ihr CPFP entsprechend nicht nutzen.
Ganz allgemein ist es wichtig bei der Wahl der Child-Feerate darauf zu achten dass die totale Fee (in BTC) hoch genug ist, um sowohl die Child Transaktion als auch die Parent-Transaktion zu „bezahlen“ (= Anreiz hoch genug für die Miner). Das letzte was man will sind schließlich zwei unbestätigte Transaktionen - eure Wallet Software hilft euch aber hierbei.
Transaktionsabbruch
Wir können RBF auch dazu nutzen eine unbestätigte Transaktion vollständig abzubrechen. Wer aufgepasst hat weiss dass die Transaktion zwar mindestens einen gleichen Input haben muss, die Outputs aber nicht zwingend die selben sein müssen. Also senden wir einfach an eine eigene Adresse mit erhöhter Fee und die Coins landen wieder bei uns. Eine Transaktion findet natürlich trotzdem statt, aber eben nicht die ursprünglich geplante.
Ich habe auch einen Thread aus 2014 gefunden mit einem, aus heutiger Sicht, lustigen Kommentar:
even if transaction is included in block, it can be canceled - all you need to do is to mine two consecutive blocks without this tx. Therefore, the first block will be orphaned, and all the transaction it has will be unvalidated. This is the very reason we should wait for 6 confirmations.
– Maciej Mączko Apr 24 '14 at 19:33
Man soll sich einfach schnell zwei Blöcke minen und die alte Transaktion verwaisen lassen! 
Aus heutiger Sicht ist eine bestätigte Transaktion natürlich irreversibel und kann nicht neu erstellt werden, da der durchschnittliche Nutzer nicht in der Lage ist auf die schnelle ein höheres Proof of Work zu erzeugen.
Erweitern der Transaktion
Bleibt eine Transaktion hängen können wir mit RBF die Fee erhöhen aber auch gleichzeit die Transaktion zusätzlich erweitern. Wenn man also ohnehin eine neue Transaktion machen muss kann man also zwei Fliegen mit einer Klappe schlagen und die alte Transaktion einfach erweitern (Natürlich nur wenn das mit der Privatsphäre der Transaktion vereinbar ist).
Somit spart man nicht nur Zeit sondern irgendwie auch Gebühren, da man nur für eine Transaktion zahlen muss.
UTXO Konsolidieren
Ich habe es zwar im UTXO-Beitrag bereits erwähnt, aber es kann sinnvoll sein eine Konsolidierung, die zeitlich nicht dringend ist, absichtlich mit einer niedrigen Feerate (z.B. 1 sat/vB) zu erstellen um darauf zu hoffen dass sie irgendwann bestätigt wird. Mit RBF oder CPFP könnt ihr eine solche Transaktion ohne Probleme im Zweifel bestätigen wenn es euch zu lange dauert.
Quellen:
Sehr zu empfehlen:
- Replace-by-fee (RBF) | Bitcoin Optech
- Child pays for parent (CPFP) | Bitcoin Optech
- Replace by fee - Bitcoin Wiki
- Transaction replacement - Bitcoin Wiki
- Miner fees - Bitcoin Wiki
- Frequently Asked Questions – Bitcoin Electrum
- How to do a manual Child Pays For Parent transaction – Bitcoin Electrum
- Bitcoin Core :: Opt-in RBF FAQ
- https://youtu.be/t3c0E4fkSNs
Danke fürs Lesen - Ich hoffe es war hilfreich! 
Bei Fragen oder Kritik gerne hier im Thread oder per DM melden.
