Bitcoin Gebühr nachträglich erhöhen mit RBF und CPFP

Die Transaktion ist raus, der Mempool füllt sich, und die Bestätigung kommt nicht. Wer zu knapp kalkuliert hat oder wen ein plötzlicher Gebührenanstieg überholt hat, steht vor derselben Frage: Lässt sich die Bitcoin Gebühr nachträglich erhöhen? Ja, und zwar auf zwei sehr verschiedene Arten. RBF ersetzt die Transaktion durch eine teurere, CPFP hängt eine zweite Transaktion hinten dran, die für beide zahlt. Die Bitcoin sind in keinem Fall verloren — sie sind nur eine Weile nicht verfügbar.

An diesem Thema hat sich in den vergangenen zwei Jahren mehr geändert, als die meisten Anleitungen im Netz wiedergeben. Die Regel, dass eine Transaktion beim Senden ausdrücklich als ersetzbar markiert sein muss, gilt seit Bitcoin Core 28.0 nicht mehr. Und Core 31.0 hat im April 2026 an der Mechanik hinter CPFP geschraubt. Beides räumen wir hier mit ein.

Warum eine Transaktion überhaupt liegen bleibt

Miner suchen sich aus dem Mempool die Transaktionen mit der höchsten Gebühr je Byte heraus, nicht die mit der höchsten Gesamtgebühr. Massgeblich ist also der Satz in sat/vByte. Eine grosse Transaktion mit hoher Gesamtgebühr kann hinter einer kleinen mit niedriger Gesamtgebühr zurückstehen, wenn deren Satz besser ist. Wie sich Grösse und Satz berechnen, haben wir in Bitcoin Onchain Gebühren einfach berechnen ausführlich vorgerechnet; das wiederholen wir hier nicht.

Bleibt eine Transaktion unter dem Satz, den die Miner gerade bedienen, wartet sie. Und sie wartet nicht ewig: Bitcoin Core wirft unbestätigte Transaktionen nach einer eingestellten Frist wieder aus dem Mempool. Die Vorgabe steht im Quelltext bei DEFAULT_MEMPOOL_EXPIRY_HOURS{336}, also bei 336 Stunden oder rund zwei Wochen. Danach ist die Transaktion weg, als hätte es sie nie gegeben, und ihr könnt die Bitcoin normal wieder ausgeben. Die verbreitete Angabe von drei bis vier Wochen stimmt nicht.

Bitcoin Gebühr nachträglich erhöhen: RBF oder CPFP

Die beiden Verfahren lösen dasselbe Problem auf entgegengesetztem Weg, und die Wahl zwischen ihnen ist meistens keine Geschmacksfrage, sondern hängt davon ab, ob ihr Absender oder Empfänger seid.

Ein Punkt aus der Grafik verdient es, ausgesprochen zu werden, weil er in vielen Anleitungen untergeht: RBF ist der günstigere Weg. Bei der Ersetzung zahlt ihr am Ende nur die Gebühr der neuen Transaktion, die alte wird nie bestätigt und kostet deshalb auch nichts. Bei CPFP zahlt ihr beide Gebühren, und ihr belegt zusätzlich Platz in einem Block, den ihr sonst nicht gebraucht hättet. Wenn ihr die Wahl habt, nehmt RBF.

Damit ist auch eine falsche Vorstellung erledigt, die sich hartnäckig hält: Ihr bekommt die Gebühr der ersetzten Transaktion nicht „zurück". Es gibt nichts zurückzuerstatten, weil sie nie abgebucht wurde. Eine Bitcoin-Gebühr entsteht erst in dem Moment, in dem ein Miner die Transaktion in einen Block aufnimmt.

RBF: Was 2024 und 2025 gekippt ist

Replace by Fee heisst: Ihr gebt eine zweite Transaktion heraus, die dieselben Eingänge ausgibt wie die erste, aber eine höhere Gebühr trägt. Die Nodes werfen die alte aus dem Mempool und behalten die neue. Weil beide dieselben Eingänge verbrauchen, kann am Ende nur eine von beiden in einen Block. Doppelt ausgeben lässt sich damit also nichts.

Jahrelang galt dafür eine Bedingung, die den ganzen Mechanismus zur Glückssache machte: Die ursprüngliche Transaktion musste sich beim Senden als ersetzbar zu erkennen geben, über einen Wert im sequence-Feld unterhalb von 0xfffffffe. Wer das versäumt hatte, kam an RBF nicht heran.

Diese Bedingung ist gefallen. Bitcoin Core 28.0 hat am 02.10.2024 die Vorgabe für -mempoolfullrbf von 0 auf 1 gestellt. Ein halbes Jahr später, mit Core 29.0 vom 14.04.2025, ist der Schalter ganz verschwunden — die Release Notes schreiben dazu: „With widespread adoption of this policy, users no longer benefit from disabling it, so the option has been removed, making full replace-by-fee the standard behavior." In der Policy-Dokumentation stehen die früheren Regeln 1 und 2 folgerichtig als „(Removed)".

Für euch heisst das zweierlei. Als Absender könnt ihr praktisch jede unbestätigte Transaktion nachbessern, unabhängig davon, wie sie herausgegangen ist. Als Empfänger solltet ihr eine unbestätigte Zahlung grundsätzlich als noch nicht endgültig behandeln — auch eine, die formal nicht als ersetzbar markiert ist. Wer Waren gegen null Bestätigungen herausgibt, geht heute ein grösseres Risiko ein als 2023.

Die Regeln, die eine Ersetzung erfüllen muss

Übrig geblieben sind vier Bedingungen, und sie stehen so in der Policy-Dokumentation von Bitcoin Core:

1. Die Ersatztransaktion zahlt eine absolute Gebühr, die mindestens so hoch ist wie die Summe der Gebühren aller Transaktionen, die sie verdrängt.
2. Die zusätzliche Gebühr deckt darüber hinaus die eigene Bandbreite zum Incremental Relay Feerate der Node ab. Die Dokumentation rechnet es vor: für 500 vByte bei 0,1 sat/vByte sind das mindestens 50 Satoshi obendrauf.
3. Die verdrängten Transaktionen verteilen sich auf höchstens 100 Cluster.
4. Das Feerate-Diagramm des Mempools muss sich durch die Ersetzung strikt verbessern. Diese Regel kam mit dem Cluster-Mempool in Core 31.0 dazu und ersetzt die frühere reine Gebührenprüfung. Für gewöhnliche Zahlungen ist sie unauffällig: Laut Release Notes reicht es, dass die neue Transaktion eine höhere Gebühr und eine höhere Gebührenrate hat als die alte.

Drei Behauptungen, die ihr getrost vergessen könnt

Rund um RBF kursieren Regeln, die es nie gab. Weil sie in älteren Anleitungen stehen — auch in der ersten Fassung dieses Artikels —, hier die Richtigstellung.

• „Die Empfänger und Beträge müssen gleich bleiben." Falsch. Die Ausgänge dürfen frei geändert werden, auch die Empfängeradresse. Genau das ist der Grund, warum Wallets eine Funktion zum Stornieren einer unbestätigten Zahlung anbieten können: Sie ersetzen die Transaktion durch eine, die alles an euch selbst zurückschickt.
• „Ihr müsst die Gebühr verdreifachen, um sie zu verdoppeln." Falsch, und es vermengt absoluten Betrag und Rate. Es gilt Regel 1 plus Regel 2: mindestens die alte absolute Gebühr, plus ein kleiner Aufschlag für die Bandbreite.
• „Nicht alle Miner unterstützen RBF." Überholt. Ersetzungen werden von den Nodes im Netz weitergereicht; ein Miner sieht schlicht die teurere Variante und nimmt sie, weil sie mehr einbringt. Seit dem Wegfall des Schalters in Core 29.0 gibt es dazu auch keine sinnvolle Gegenkonfiguration mehr.

CPFP: Anhängen statt ersetzen

Child Pays for Parent braucht keine Erlaubnis vom Absender, denn es rührt die festhängende Transaktion gar nicht an. Ihr gebt stattdessen einen ihrer Ausgänge weiter aus — an euch selbst genügt — und stattet diese neue Transaktion mit einer hohen Gebühr aus. Weil das Kind nur bestätigt werden kann, wenn die Eltern mit im Block sind, bewerten Miner beide zusammen als Paket.

Deshalb funktioniert CPFP auch dann, wenn euch jemand anderes eine zu billige Zahlung geschickt hat. Ihr müsst nur über einen Ausgang verfügen können. Umgekehrt ist CPFP auch der Ausweg für Absender ohne Wechselgeld: Wer den gesamten Betrag verschickt hat, hat keinen eigenen Ausgang, an dem sich für eine Ersetzung drehen liesse.

Die Paketgebühr rechnen

Der Fehler, den hier fast alle machen: Sie setzen für das Kind den Zielsatz ein. Das reicht nicht. Der Zielsatz muss für das Paket herauskommen, und die zu billigen Eltern ziehen den Schnitt nach unten. Die Rechnung geht so:

Zielgebuehr Paket = (Groesse Eltern + Groesse Kind) * Zielsatz
Gebuehr Kind      = Zielgebuehr Paket - bereits gezahlte Gebuehr Eltern
Satz Kind         = Gebuehr Kind / Groesse Kind

Beispiel aus der Grafik:
  Eltern  140 vB, 6 sat/vB   ->   840 sat bereits gezahlt
  Kind    110 vB
  Ziel    25 sat/vB

  (140 + 110) * 25 = 6250 sat fuer das Paket
  6250 - 840       = 5410 sat muss das Kind tragen
  5410 / 110       = 49,2 sat/vB  ->  aufgerundet 50 sat/vB

Merkt euch die Faustregel dahinter: Je kleiner das Kind im Verhältnis zu den Eltern, desto brutaler muss sein Satz ausfallen. Ein 110-vByte-Kind, das 140 vByte Eltern mitschleppt, braucht den doppelten Zielsatz. Wallets mit CPFP-Funktion rechnen das selbst; wer von Hand baut, sollte grosszügig aufrunden.

Was Core 31.0 an CPFP geändert hat

Für gewöhnliche Zahlungen ändert sich nichts. Wer eine Lightning-Node betreibt, sollte den Punkt trotzdem kennen. Es gab in Bitcoin Core eine Sonderregel namens CPFP Carve-out, die einer einzelnen Transaktion erlaubte, die Paketgrenzen leicht zu überschreiten, sofern sie nur einen unbestätigten Vorgänger hatte. Sie war für Verträge zwischen zwei Parteien gedacht — also genau für Lightning-Kanäle — damit beide Seiten eine Gebühr nachschieben können, ohne dass eine die andere blockiert.

Diese Sonderregel ist mit Core 31.0 entfallen. Die Release Notes halten fest, dass Anwendungsfälle mit ähnlichem Bedarf „employ TRUC transactions and sibling eviction instead going forward". TRUC steht für Topologically Restricted Until Confirmation und ist in BIP 431 beschrieben, der weiterhin den Status Draft trägt. Praktisch betrifft das die Lightning-Implementierung, nicht euch als Nutzer — aber es ist ein guter Grund, die Node-Software aktuell zu halten, statt sie drei Versionen zurückhängen zu lassen.

Welche Wallet kann was

Die Verfahren nützen euch nur, wenn eure Wallet sie anbietet. Von Hand eine Ersatztransaktion zu bauen ist möglich, aber nichts, was wir jemandem empfehlen, der nicht ohnehin weiss, wie es geht. Die folgende Übersicht stützt sich auf die Dokumentation der Projekte selbst, Stand 23.08.2026.

Wallet	RBF-Bump	CPFP	Anmerkung
Electrum	ja	ja	Rechtsklick im Verlauf, „Increase Fee" oder „Child pays for parent". Zusätzlich „Cancel (double-spend)".
Sparrow	ja	ja	Rechtsklick, „Increase Fee". CPFP über das Weiterausgeben des Ausgangs.
BlueWallet	ja	ja	Mobil. Die Projektseite nennt „Speed up, Cancel or Batch transactions. With RBF and CPFP".
Bitcoin Core	ja	von Hand	RPC bumpfee. Für CPFP baut ihr die Kind-Transaktion selbst.
BitBoxApp	nein	nein	Sendet aber alles ersetzbar. Für den Bump die BitBox02 an Sparrow hängen.
LND / Ride the Lightning	ja	ja	BumpFee wählt selbst, was passt.

Sparrow, auch mit einer BitBox02

Die Sparrow-Dokumentation nennt beide Wege. Für RBF muss die Transaktion unbestätigt sein und ausschliesslich eigene Eingänge verwenden; ersetzbar sendet Sparrow ohnehin von Haus aus. Unbestätigte Transaktionen bekommen im Reiter Transactions ein Symbol, und über den Rechtsklick führt Increase Fee zurück in den Sende-Dialog mit angepasster Gebühr. CPFP beschreibt die FAQ als das Ausgeben der Ausgänge zu einem höheren Satz.

Interessant ist das für alle mit einer BitBox02, denn die BitBoxApp selbst hat dafür keine Oberfläche. Der Hersteller sagt das offen und beschreibt in einer eigenen Anleitung den Umweg: „it doesn't have an RBF interface, it enables RBF for all transactions by default, giving you the option to use it with advanced software like Sparrow Wallet." Ihr verbindet die BitBox02 also mit Sparrow, wählt dort Increase Fee (RBF), schiebt den Regler hoch, bestätigt auf dem Gerät und sendet. Wie die Verbindung zu einer eigenen Node aussieht, steht in Sparrow Wallet mit Umbrel Bitcoin Fullnode verbinden und in Bitbox02 mit Raspiblitz Bitcoin Fullnode verbinden.

Bitcoin Core auf der Kommandozeile

Wer eine eigene Full Node betreibt, hat den direktesten Weg. Der RPC bumpfee nimmt die Transaktions-ID und baut die Ersetzung selbst:

# Gebuehr automatisch neu schaetzen lassen
bitcoin-cli bumpfee <txid>

# Oder den Satz selbst vorgeben, hier 25 sat/vByte
bitcoin-cli -named bumpfee txid=<txid> options='{"fee_rate": 25}'

Die Dokumentation beschreibt, wie Core die Mehrgebühr aufbringt: „The command will pay the additional fee by reducing change outputs or adding inputs when necessary. It may add a new change output if one does not already exist." Alle Eingänge der alten Transaktion wandern in die neue. Zwei Grenzen solltet ihr kennen: Der Befehl scheitert, wenn Wallet oder Mempool bereits eine Transaktion enthalten, die einen Ausgang der alten ausgibt — dann habt ihr faktisch schon ein CPFP gebaut. Und der angegebene Satz muss mindestens 1 sat/vByte über dem alten liegen.

Lightning-Node über Ride the Lightning

Hängt eine Kanaleröffnung fest, wird es unangenehm, weil der Kanal bis zur Bestätigung nicht nutzbar ist. RTL reicht dafür den BumpFee-Aufruf von LND durch, und der entscheidet selbst, welches Verfahren passt. Die LND-Dokumentation formuliert es so: „Depending on whether the outpoint has been registered in the sweeper (an existing input, e.g., an anchor output) or not (a new input, e.g., an unconfirmed wallet utxo), this will either be an RBF or CPFP attempt." Ihr müsst euch also nicht entscheiden, sondern nur einen Zielsatz angeben.

Der dritte Weg: Beschleuniger

Bleibt der Fall, in dem weder RBF noch CPFP geht: Ihr seid nicht der Absender und habt auch keinen Ausgang, über den ihr verfügen könnt. Dann bleibt ein Mining-Pool, der die Transaktion aus Kulanz in seinen nächsten Block nimmt. ViaBTC betreibt so einen Dienst weiterhin und nennt in seinem Hilfeartikel die Bedingungen: „ViaBTC supports 20 FREE acceleration chances per hour", dazu höchstens 0,5 KB Transaktionsgrösse und ein Mindestsatz. Wie das abläuft, steht in Bitcoin Transaktionen mit ViaBTC gratis beschleunigen.

Seid euch dabei über die Grenzen im Klaren. Ein Beschleuniger ändert nichts an der Transaktion und nichts an ihrer Gebühr — er bittet einen einzelnen Pool um Vorzugsbehandlung. Findet dieser Pool in absehbarer Zeit keinen Block, passiert nichts. Es ist die schwächste der drei Optionen und die einzige, bei der ihr auf das Wohlwollen eines Dritten angewiesen seid.

Was ihr tun könnt

• Erst nachsehen, dann handeln. Sucht die Transaktions-ID in einem Mempool-Explorer und vergleicht euren Satz mit dem, was gerade in die Blöcke geht. Liegt ihr knapp darunter, lohnt oft schon das Abwarten der nächsten ruhigen Stunde.
• Seid ihr der Absender, nehmt RBF. Es ist günstiger als CPFP und braucht seit Core 28.0 keine Vorbereitung mehr an der ursprünglichen Transaktion.
• Seid ihr der Empfänger, nehmt CPFP — und rechnet den Satz für das Paket, nicht für das Kind allein. Sonst zahlt ihr mehr und hängt trotzdem fest.
• Setzt einmalig den richtigen Satz, statt zweimal zu bieten. Jede Nachbesserung kostet erneut die volle Gebühr. Ein zu vorsichtiger Bump, der wieder nicht reicht, ist der teuerste Fehler in diesem Vorgang.
• Behandelt eingehende Zahlungen mit null Bestätigungen als offen. Seit Full-RBF Standard ist, lässt sich jede unbestätigte Transaktion ersetzen, auch eine ohne Markierung.
• Beugt vor mit UTXO-Management. Wer wenige, saubere UTXO hält, baut kleinere Transaktionen — und kleinere Transaktionen sind bei gleichem Satz schlicht billiger, auch beim Nachbessern.
• Prüft vor dem Wallet-Wechsel, ob sie es kann. Die Tabelle oben ist ein Anfang; Welche Bitcoin Wallets gibt es ordnet die Kandidaten breiter ein.

Fazit: Eine festhängende Transaktion ist ein Ärgernis, kein Verlust

Der schlimmste Fall ist, dass ihr zwei Wochen wartet und die Bitcoin danach wieder in eurer Wallet liegen. Alles darunter lässt sich mit einem der beiden Verfahren beheben, und in den meisten Wallets sind es zwei Klicks.

Bemerkenswert ist, wie deutlich sich die Lage seit 2023 gebessert hat. Damals war RBF eine Funktion, an die ihr im Nachhinein nur herankamt, wenn ihr vorher daran gedacht hattet — und dieses Vorher-Daran-Denken übernahmen längst nicht alle Wallets. Heute ist die Ersetzbarkeit der Normalzustand des Netzes, und die Frage lautet nur noch, ob eure Wallet eine Schaltfläche dafür hat. Dass Bitcoin Core dafür eine jahrelang umstrittene Option kommentarlos gestrichen hat, statt sie zur Wahl zu stellen, war die richtige Entscheidung: Eine Regel, die sich mit ein paar Zeilen Konfiguration umgehen liess, hat nie Sicherheit gestiftet, sondern nur den Anschein davon.

Wer daraus etwas mitnehmen will, dann dies: Verlasst euch nicht auf null Bestätigungen, weder als Empfänger noch beim Kaffeeholen mit dem Handy. Und wenn ihr sendet, schaut einmal kurz auf den Mempool, bevor ihr auf Senden drückt. Das erspart euch diesen ganzen Artikel.

Quellen und weiterführende Links

• Bitcoin Core: doc/policy/mempool-replacements.md — die geltenden Ersetzungsregeln
• Bitcoin Core 28.0 Release Notes — Vorgabe für -mempoolfullrbf von 0 auf 1
• Bitcoin Core 29.0 Release Notes — Option entfernt, Full-RBF ist Standard
• Bitcoin Core 31.0 Release Notes — Feerate-Diagramm und Wegfall des CPFP Carve-out
• Bitcoin Core: mempool_options.h — DEFAULT_MEMPOOL_EXPIRY_HOURS{336}
• Bitcoin Core RPC-Referenz: bumpfee
• BIP 431: Topology Restrictions for Pinning — TRUC-Transaktionen
• Bitcoin Optech: CPFP carve out
• Sparrow Wallet FAQ — Increase Fee und CPFP
• Electrum FAQ — Increase Fee, Child pays for parent, Cancel
• BitBox Support: RBF mit Sparrow und BitBox02
• LND API: BumpFee
• ViaBTC: BTC Transaction Accelerator