Fee-Engineering: RBF und CPFP im Mempool-Stau | BitAtlas Technical
⚙️ Technical Layer 📅 ⏱️ 14 Min.

Fee-Engineering 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.

George V. - BitAtlas Lead Architect
George V. Lead Architect, BitAtlas
🔗
Die Brücke zur Kontrolle

Hardware, die RBF korrekt verarbeitet

Präzises Fee-Engineering erfordert Signer, die RBF-Signale korrekt verarbeiten und dich nicht im Mempool-Stau im Stich lassen. Im Select Archiv prüfen wir die Hardware.

§ 01

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.

Sender-Werkzeug 🔄

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.

Wann: Du kontrollierst die Inputs.
Empfänger-Werkzeug 👶

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.

Wann: Du bist der Empfänger.
💡 Der Marktplatz-Gedanke

Der Mempool ist kein Wartezimmer – er ist eine Auktion. Jeder Block hat begrenzten Platz (~4 MB Weight), und Miner verkaufen diesen Platz an den Höchstbietenden. Deine Transaktion konkurriert mit tausenden anderen. Wer zahlt, gewinnt.

§ 02

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.

RBF Replacement Rules

Regel 1: Die Ersatz-TX muss mindestens einen Input der Original-TX verwenden.

Regel 2: Die absolute Gebühr muss höher sein (mehr Satoshis total).

Regel 3: Die Fee-Rate (sat/vB) muss höher sein.

Regel 4: Die Ersatz-TX muss alle Outputs der Original-TX abdecken oder höher priorisieren.

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.

1

Steckengebliebene TX identifizieren

Sparrow öffnen → Transactions-Tab → Unbestätigte TX finden (gelbes Icon).

2

RBF-Option auswählen

Rechtsklick auf die TX → Increase Fee (RBF). Sparrow lädt die TX in den Send-Screen.

3

Neue Fee-Rate setzen

Fee-Slider anpassen (z.B. von 20 auf 80 sat/vB). Sparrow zeigt die neue geschätzte Bestätigungszeit.

4

Mit Hardware-Wallet signieren

BitBox02/Trezor verbinden → TX auf dem Device verifizieren → Signieren → Broadcast.

💰 Ökonomische Effizienz

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 dein First-Line-Tool.

§ 03

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.

CPFP Package Fee Rate

Miner berechnen die effektive Fee-Rate des Parent+Child-Pakets:

$$\text{feerate}_{\text{eff}} = \frac{\text{fee}_{P} + \text{fee}_{C}}{\text{size}_{P} + \text{size}_{C}}$$

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:

Child-Fee Kalkulation

Um eine Ziel-Fee-Rate zu erreichen:

$$\text{fee}_{C} \geq \text{feerate}_{\text{target}} \cdot (\text{size}_{P} + \text{size}_{C}) – \text{fee}_{P}$$

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

Quelle: Bitcoin Optech Fee Bumping Guide | Sparrow Wallet Documentation

CPFP-Workflow als Empfänger

1

Unbestätigten Eingang identifizieren

Sparrow → Transactions → Die unbestätigte Eingangstransaktion auswählen.

2

UTXO zum Ausgeben auswählen

Rechtsklick → Spend selected UTXO oder CPFP (je nach Sparrow-Version).

3

Zieladresse und hohe Fee setzen

Sende an eine eigene Adresse (Consolidation). Setze eine deutlich höhere Fee-Rate als aktuell nötig.

4

Signieren und Broadcasten

Hardware-Wallet verbinden → Signieren → Broadcast. Miner sehen das Paket und priorisieren es.

⚠️ CPFP ist teurer

CPFP ist dein Last Resort. 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.

§ 04

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

Relevanz für Lightning-Nutzer

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 der Standard-Stack gegen diese Attacken.

§ 05

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

Du bist Sender
✓ Optimal
Möglich, aber teurer
RBF
Du bist Empfänger
✗ Nicht möglich
✓ Einzige Option
CPFP
Kosten-Effizienz
Hoch (nur Delta)
Mittel (+1 TX)
RBF
UTXO-Hygiene
Sauber (keine neuen)
Erzeugt neuen UTXO
RBF
Komplexität
Niedrig
Mittel
RBF
Zuverlässigkeit 2026
Full-RBF Standard
Package Relay aktiv
Beide robust

Quelle: Bitcoin Optech Fee Bumping Guide | Stacker News CPFP Analysis

§ 06

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

Die mathematische Grundlage: Sei $Q(\lambda)$ die Menge an vBytes im Mempool mit Fee-Rate ≥ $\lambda$. Ein Block fasst ca. 1,0-1,5 Mio vB. 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.

Fee-Projektion über eigene Node

Bitcoin Core CLI:

bitcoin-cli estimatesmartfee 2 → Empfohlene sat/vB für Bestätigung in ~2 Blöcken

bitcoin-cli estimatesmartfee 6 → Für ~6 Blöcke (Low Priority)

bitcoin-cli getmempoolinfo → Aktuelle Mempool-Größe und Min-Fee

Quelle: Bitcoin Core RPC Documentation | Bitcoin Wiki Fee Estimation

🖥️ Eigene Node für präzise Schätzungen

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.

§ 07

Die „Mempool War“ Checkliste

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. Für maximale Präzision verbinde Sparrow mit deiner eigenen Node – kein Raten, nur Daten.

BitAtlas Select Archiv →

Technischer Hinweis: Dieses Dokument beschreibt den Stand von RBF, CPFP und Package Relay zum Januar 2026. Die Mempool-Policy kann je nach Node-Implementierung variieren. Prüfe die aktuellen Release Notes von Bitcoin Core und Sparrow.

BitAtlas ist unabhängig, gibt aber kuratierte Empfehlungen für Tools und Hardware, die den höchsten Sicherheitsstandards entsprechen. Souveränität durch Wissen.

Nach oben scrollen