Gebühren steuern RBF und CPFP im Mempool-Stau
Der Mempool ist ein Marktplatz. Wer zuerst im Block landen will, muss das beste Angebot machen. Dieses Dossier gibt dir die chirurgischen Instrumente zur Transaktionsbeschleunigung: Replace-By-Fee für die Ersetzung, Child-Pays-For-Parent für die Rettung. Keine Panik-Buttons, sondern präzise Exekution.
Die Anatomie der Beschleunigung
Deine Transaktion hängt im Mempool. Die Gebühr war zu niedrig, der Markt hat sich bewegt, und jetzt wartest du. Stunden. Vielleicht Tage. Das ist kein Systemfehler – es ist das Design eines freien Marktes. Miner sind rationale Akteure: Sie priorisieren Transaktionen, die ihnen die höchste Rendite pro Blockgewicht bieten.
2026 hast du zwei Werkzeuge, um diese Situation zu lösen: RBF (Replace-By-Fee) und CPFP (Child-Pays-For-Parent). Beide sind Standardwerkzeuge, keine Hacks. Aber sie haben fundamental unterschiedliche Anwendungsfälle, und die Wahl des falschen Werkzeugs kostet dich Geld.
RBF (Replace-By-Fee)
Ersetze deine eigene, unbestätigte Transaktion durch eine neue Version mit höherer Gebühr. Die alte TX wird verworfen, die neue priorisiert.
CPFP (Child-Pays-For-Parent)
Erstelle eine Kind-Transaktion, die einen Output der steckengebliebenen Parent-TX ausgibt – mit so hoher Gebühr, dass das Paket attraktiv wird.
Der Mempool ist kein Wartezimmer – er ist eine Auktion. Jeder Block hat begrenzten Platz — 4 Millionen Gewichtseinheiten, das sind 1 Million virtuelle Bytes —, und Miner verkaufen diesen Platz an den Höchstbietenden. Deine Transaktion konkurriert mit tausenden anderen. Wer zahlt, gewinnt.
RBF – Die chirurgische Ersetzung
BIP-125 definiert das Protokoll: Eine unbestätigte Transaktion kann durch eine neue ersetzt werden, wenn mindestens einer der gleichen Inputs verwendet wird, die absolute Gebühr höher ist, und die Gebührenrate (sat/vB) steigt. Die ursprüngliche TX signalisiert RBF typischerweise durch ein nSequence-Flag.
Full-RBF: Der 2026er Standard
„Full-RBF“ geht einen Schritt weiter: Nodes erlauben die Ersetzung jeder unbestätigten Transaktion, unabhängig davon, ob sie BIP-125 signalisiert. 2026 haben die meisten Nodes und Miner Full-RBF aktiviert. Das bedeutet: Du kannst praktisch jede deiner unbestätigten Transaktionen bumpen – vorausgesetzt, du kontrollierst die Inputs.
Die Ersatz-TX gibt mindestens einen Input der Original-TX aus. Dann gelten fünf Bedingungen:
Regel 1: Die Original-TX signalisiert Ersetzbarkeit – ausdrücklich oder geerbt.
Regel 2: Die Ersatz-TX darf einen unbestätigten Input nur verwenden, wenn er schon in einer der Original-TX steckte.
Regel 3: Die absolute Gebühr ist mindestens so hoch wie die Summe der ersetzten TX.
Regel 4: Die Ersatz-TX bezahlt zusätzlich ihre eigene Bandbreite zum Mindest-Relay-Satz der Node.
Regel 5: Ersetzte TX und ihre verdrängten Nachfahren zusammen höchstens 100.
Die fünf Regeln stehen wörtlich im Abschnitt Implementation Details von BIP-125, am 17.09.2026 im Volltext gelesen. Die Signalisierungsregel, die Regel zu unbestätigten Inputs und die 100er-Grenze fehlten. Quelle: BIP-125 Specification | Bitcoin Optech RBF Topic
RBF-Bump in Sparrow Wallet
Sparrow macht den Prozess trivial. Du brauchst keinen manuellen PSBT-Builder – die Software erkennt RBF-fähige Transaktionen automatisch und bietet dir die Ersetzungsoption an.
Steckengebliebene TX identifizieren
Sparrow öffnen → Transactions-Tab → Unbestätigte TX finden (gelbes Icon).
RBF-Option auswählen
Rechtsklick auf die TX → Increase Fee (RBF). Sparrow lädt die TX in den Send-Screen.
Neue Fee-Rate setzen
Fee-Slider anpassen (z.B. von 20 auf 80 sat/vB). Sparrow zeigt die neue geschätzte Bestätigungszeit.
Mit Hardware-Wallet signieren
BitBox02/Trezor verbinden → TX auf dem Device verifizieren → Signieren → Broadcast.
RBF ist fast immer günstiger als CPFP. Du zahlst nur die Differenz zwischen alter und neuer Gebühr – kein zusätzlicher TX-Body, keine extra vBytes. Bei CPFP bezahlst du einen kompletten zweiten Transaktionskörper. RBF ist der erste Griff.
CPFP – Die Rettung des Empfängers
Du bist der Empfänger. Jemand hat dir Bitcoin gesendet, aber mit einer lächerlich niedrigen Gebühr. Du siehst den unbestätigten Eingang in deiner Wallet, kannst aber die Inputs nicht kontrollieren – sie gehören dem Sender. RBF ist keine Option. Hier kommt CPFP ins Spiel.
Die Ancestor Fee Rate Logik
Miner betrachten beim Mempool-Scoring die effektive Fee-Rate eines Pakets. Wenn eine Child-TX nur zusammen mit ihrer Parent-TX gemined werden kann (weil sie einen noch unbestätigten Output der Parent ausgibt), berechnen Miner die kombinierte Fee-Rate beider Transaktionen.
Miner berechnen die effektive Fee-Rate des Parent+Child-Pakets:
feeP = Gebühr der Parent-TX (die steckengebliebene)
feeC = Gebühr der Child-TX (deine Rettungs-TX)
size = Größe in vBytes
Quelle: Bitcoin Wiki Transaction Replacement | Bitcoin Optech CPFP Topic
Für ein Ziel von z.B. 50 sat/vB, wenn die Parent-TX 200 vB groß ist und nur 5 sat/vB zahlt, musst du die Differenz ausgleichen. Die Formel zur Berechnung deiner Child-Fee:
Um eine Ziel-Fee-Rate zu erreichen:
Beispiel: Parent = 200 vB @ 5 sat/vB (1.000 sat). Child = 150 vB. Ziel = 50 sat/vB.
feeC ≥ 50 × (200 + 150) − 1.000 = 50 × 350 − 1.000 = 17.500 − 1.000 = 16.500 sat
Die Formel ist unsere Umstellung der Paket-Gebührenrate (feeP + feeC) / (sizeP + sizeC) nach feeC; Optech beschreibt diese Ahnen-Gebührenrate im Topic CPFP in Worten, das Bitcoin Wiki im Abschnitt zu abhängigen Transaktionen. Das Beispiel ist nachgerechnet: 50 × 350 − 1.000 = 16.500 sat. Quelle: Bitcoin Optech – Topic Child pays for parent (CPFP) | Bitcoin Wiki – Miner fees | Sparrow Wallet — FAQ: CPFP durch Ausgeben der Outputs mit höherer Gebührenrate
CPFP-Workflow als Empfänger
Unbestätigten Eingang identifizieren
Sparrow → Transactions → Die unbestätigte Eingangstransaktion auswählen.
UTXO zum Ausgeben auswählen
Rechtsklick → Spend selected UTXO oder CPFP (je nach Sparrow-Version).
Zieladresse und hohe Fee setzen
Sende an eine eigene Adresse (Consolidation). Setze eine deutlich höhere Fee-Rate als aktuell nötig.
Signieren und Broadcasten
Hardware-Wallet verbinden → Signieren → Broadcast. Miner sehen das Paket und priorisieren es.
CPFP ist der letzte Ausweg. Du bezahlst einen kompletten zweiten TX-Body (Input, Output, Signaturen). Das sind typisch 100-200 zusätzliche vBytes. Nutze CPFP nur, wenn RBF keine Option ist – also wenn du der Empfänger bist und keinen Zugriff auf die Sender-Inputs hast.
Paket-Relay und V3 Transaktionen
2026 ist Package Relay in Bitcoin Core etabliert. Nodes können Pakete aus Parent+Child-Transaktionen an Peers weiterleiten, anstatt nur einzelne TXs. Das macht CPFP verlässlicher: Du kannst dich darauf verlassen, dass Miner das komplette Paket sehen.
V3 Transactions (TRUC / BIP-431)
Version-3-Transaction-Relay führt neue Policy-Regeln speziell für V3-TXs ein. Der Hauptzweck: Verhinderung von Pinning-Attacken. Bei einem Pinning-Angriff erstellt ein Angreifer eine Low-Fee-Child-TX, die deine Fähigkeit blockiert, die Parent-TX effektiv zu bumpen.
Package Relay
1p1c (One-Parent-One-Child) Pakete werden nativ relayed.
Anti-Pinning
V3/TRUC verhindert, dass bösartige Children die Fee-Rate drücken.
Lightning-Ready
Commitment- und Anchor-TXs nutzen V3 für sichere Channel-Closings.
Quelle: Bitcoin Optech V3 Transaction Relay | Delving Bitcoin TRUC Discussion
Wenn du Lightning-Channels betreibst, ist V3/TRUC kritisch. Bei einem Force-Close muss deine Commitment-TX durch einen überlasteten Mempool. Ohne Anti-Pinning könnte ein bösartiger Channel-Partner deinen Close blockieren. Die Kombination aus Full-RBF, Package Relay und V3 ist das, was heute gegen diesen Angriff steht.
Entscheidungsmatrix: RBF vs. CPFP
Die Wahl des richtigen Werkzeugs hängt von einer einzigen Frage ab: Kontrollierst du die Inputs der steckengebliebenen Transaktion? Wenn ja: RBF. Wenn nein: CPFP.
RBF
CPFP
Empfehlung
Mempool-Forensik in Sparrow
Bevor du bumpst, musst du wissen, wie viel du bumpen sollst. Überbezahlung ist Verschwendung, Unterbezahlung ist wirkungslos. Die Lösung: Mempool-Forensik. Analysiere die aktuelle vByte-Tiefe und projiziere deine Ziel-Fee.
mempool.space Integration
mempool.space ist der de-facto Standard für Mempool-Visualisierung. Die Seite zeigt Fee-Buckets (z.B. 1-5, 5-10, 10-20 sat/vB), die vByte-Tiefe pro Klasse und geschätzte Blöcke bis zur Inklusion. Sparrow kann sich direkt mit mempool.space verbinden oder mit deiner eigenen Node synchronisieren.
Next Block
High Priority. Höchste Fee-Rate nötig.
~3 Blöcke
Medium Priority. Balance aus Kosten und Geschwindigkeit.
~6+ Blöcke
Low Priority. Für nicht-zeitkritische TXs.
Eco
Wochenende/Nacht. Warte auf niedrige Gebühren.
Quelle: mempool.space Fee Estimation | Bitcoin Core estimatesmartfee
Die Fee-Projektion
Vereinfacht dargestellt, in unserer eigenen Formulierung: Sei $Q(\lambda)$ die Menge an vBytes im Mempool mit Fee-Rate ≥ $\lambda$. Ein Block faßt genau 1 Million vB; als Datei auf der Platte sind das je nach Anteil an SegWit-Daten rund 1,2 bis 2 MB. Du suchst die Fee-Rate $\lambda$, bei der $Q(\lambda)$ ≤ $n \times V_{\text{block}}$ für deine gewünschte Blockanzahl $n$.
Praktisch: mempool.space liefert dir diese Werte direkt. „High Priority (next block): x sat/vB“, „Medium (3 Blöcke): y sat/vB“. Nutze diese als Ziel-Fee-Rate für deinen Bump.
Bitcoin Core CLI:
bitcoin-cli estimatesmartfee 2 → geschätzte Gebührenrate in BTC/kB für Bestätigung in ~2 Blöcken; mal 100.000 ergibt sat/vB
bitcoin-cli estimatesmartfee 6 → dieselbe Schätzung für ~6 Blöcke (Low Priority)
bitcoin-cli getmempoolinfo → Aktuelle Mempool-Größe und Min-Fee
Die Bedingung Q(λ) ≤ n × Vblock ist unsere vereinfachte Darstellung; das Bitcoin Wiki beschreibt in Worten, dass Miner Transaktionen nach Gebührenrate auswählen, die Grenze von 1 Million vB je Block folgt aus BIP-141 (4 Millionen Gewichtseinheiten). Laut RPC-Dokumentation gibt estimatesmartfee die Rate in BTC/kB aus und schätzt sie aus der Bestätigungshistorie der Node, nicht aus der Tiefe des Mempools. Quelle: Bitcoin Core RPC Docs | Bitcoin Wiki – Miner fees
mempool.space ist bequem, aber du verlässt dich auf deren Node. Für maximale Präzision und Privacy verbinde Sparrow mit deiner eigenen Full Node. Dann siehst du exakt denselben Mempool-State, den auch die Miner sehen – ohne Latenz oder Filterung.
Für maximale Präzision bei der Fee-Schätzung brauchst du Zugriff auf deinen eigenen Mempool. Unser Eigene Node Guide zeigt den vollständigen Pfad zur souveränen Node-Infrastruktur.
Checkliste für den überlaufenden Mempool
Hochlast-Phasen (500+ sat/vB) erfordern Disziplin. Panik-Bumps verbrennen Sats. Diese Checkliste ist dein Protokoll für Zeiten, in denen der Mempool explodiert – sei es durch Ordinals-Hypes, ETF-News oder Halving-FOMO.
Mempool War Protocol
Für Phasen mit 500+ sat/vB
Nicht-kritische TXs pausieren
Nur sicherheitskritische Transaktionen senden: LN-Force-Closings, echte Notfälle. Alles andere kann warten.
Batching maximieren
Mehrere Zahlungen in eine TX packen. Eine TX mit 5 Outputs ist effizienter als 5 einzelne Transaktionen.
RBF konservativ nutzen
Lieber einmal ausreichend hoch bumpen als 5 kleine Bumps. Jeder Bump kostet die Differenz zur vorherigen Fee.
CPFP nur für Notfälle
CPFP nur für wirklich blockierte, fremd-initiierte Eingänge. Die Zusatzkosten eines zweiten TX-Bodys lohnen sich selten.
Feerate-Glättung planen
Große Bewegungen (Consolidation, Channel-Openings) in Zeiten niedriger Gebühren verschieben: Nachts, Wochenenden, zwischen Hype-Zyklen.
Lightning und Layer 2 nutzen
Für alltägliche Zahlungen: Lightning, Sidechains, vBTC-Layer. On-Chain auf Settlement-Events beschränken.
Zeitkontrolle: Wiederhergestellt.
Fee-Engineering ist die Kunst, den Mempool-Marktplatz zu navigieren, ohne zu überbezahlen. Verbinde Sparrow mit deiner eigenen Node, dann prüfst du selbst – kein Raten, nur Daten.
Alle Testberichte →