Eine unbestätigte Bitcoin-Transaktion wird nicht schneller, nur weil jemand eine zweite Zahlung sendet oder die Gebühr nach Gefühl erhöht. Zuerst muss klar sein, wer die betreffenden Inputs oder Outputs kontrolliert, welche Mempool-Policy die Nodes anwenden und welche Feerate Miner aktuell auswählen. Bitcoin RBF und CPFP sind die zwei üblichen Verfahren: Replace-by-Fee ersetzt die Transaktion, Child Pays for Parent ergänzt ein hoch bezahltes Child und macht damit das gesamte Paket attraktiv.
Diese Anleitung setzt voraus, dass die Transaktion gültig, noch unbestätigt und wegen einer zu niedrigen Gebühr verzögert ist. Prüfen Sie zuerst txid, absolute Fee, virtuelle Größe, Feerate, Inputs und Outputs im Wallet, auf dem eigenen Node oder über einen unabhängigen Explorer. Unser Leitfaden zu Bitcoin-Gebühren erklärt, warum sat/vB und belegter Blockspace zählen, nicht der überwiesene Bitcoin-Betrag.
Bitcoin RBF und CPFP: der entscheidende Unterschied
Bei RBF erstellt das Wallet eine neue Transaktion, die mindestens einen Input der ursprünglichen Transaktion erneut ausgibt und eine ausreichend höhere Gebühr zahlt. Beide Transaktionen stehen im Konflikt. Akzeptiert ein Node den Ersatz, entfernt er das Original aus seinem Mempool und verbreitet die neue Version. Sie erhält eine andere txid; Outputs und Wechselgeld können sich ändern. Die alte Transaktion wird nicht nachträglich bearbeitet.
CPFP lässt den Parent unverändert. Wer einen unbestätigten Output daraus kontrolliert, gibt ihn in einem neuen Child mit hoher Fee aus. Ein Miner kann das Child nur bestätigen, wenn er vorher den Parent in denselben Block aufnimmt. Deshalb kann er den gemeinsamen Ertrag bewerten. CPFP steht häufig dem Empfänger offen oder dem Absender, wenn dieser einen Change-Output des Parents kontrolliert.
| Frage | RBF | CPFP |
|---|---|---|
| Wer handelt? | Meist der Absender mit Kontrolle über die Inputs | Inhaber eines Parent-Outputs |
| Was ändert sich? | Original wird ersetzt; neue txid | Child kommt hinzu; Parent bleibt gleich |
| Gebührenprüfung | Replacement- und Relay-Regeln | Gemeinsame Paket-Feerate |
| Typischer Anlass | Wallet bietet „Fee erhöhen“ | Kein nutzbares RBF, aber ausgebbarer Output |
Opt-in RBF, Full RBF und das Feld nSequence
RBF ist eine Mempool- und Relay-Policy, keine Bitcoin-Konsensregel. Beim Opt-in RBF nach BIP125 signalisiert eine Transaktion ihre Ersetzbarkeit ausdrücklich, wenn mindestens ein Input einen nSequence-Wert unter 0xfffffffe besitzt. Ein Wert unter 0xffffffff ermöglicht außerdem die Wirkung von nLockTime; bestimmte Sequence-Werte können relative BIP68-Sperrzeiten codieren. Diese Zahlen sollten nicht ohne Kenntnis der Nebenwirkungen manuell verändert werden.
Opt-in bedeutet nicht, dass eine Transaktion ohne Signal gegen Double Spends geschützt wäre. Das Signal teilt Nodes mit entsprechender Policy lediglich vorab mit, dass sie einen regelkonformen Ersatz prüfen dürfen. Bei Full RBF kann ein Node auch eine nicht signalisierende unbestätigte Transaktion als ersetzbar behandeln. Unterstützung, Standardeinstellung und Relay-Details hängen von Software, Version und Konfiguration ab. Verschiedene Peers können deshalb unterschiedliche Mempools besitzen.
„RBF deaktiviert“ bedeutet nicht endgültig. Eine Zero-Conf-Zahlung bleibt unbestätigt; bei relevantem Risiko wartet der Empfänger auf Bestätigungen.
Welche Gebührenregeln ein Replacement erfüllen muss
Eine höhere Anzeige in sat/vB allein genügt nicht. Von BIP125 abgeleitete Policies enthalten Schutz gegen Spam und Denial-of-Service. Praktisch muss der Kandidat mit einer Transaktion im Mempool dieses Nodes kollidieren, mindestens die gesamten absoluten Fees aller dadurch entfernten Transaktionen zahlen und zusätzlich genügend Fee für das Relay seiner eigenen Bytes gemäß der incremental relay fee bereitstellen. Eine minimale Feerate-Erhöhung kann daher scheitern, wenn das Replacement größer ist oder Descendants entfernt.
Die klassischen Regeln beschränken außerdem neue unbestätigte Inputs, die das Original nicht ausgab, und begrenzen die Zahl der entfernten Transaktionen üblicherweise auf 100 einschließlich Descendants. Moderne Implementierungen können Varianten wie einen auf einen Konflikt begrenzten Ersatz und weitere Mempool-Policies anwenden. Das Thema Replace-by-Fee bei Bitcoin Optech dokumentiert diese Entwicklung. Die Annahme durch einen Explorer verpflichtet weder andere Nodes noch Miner.
Beispiel: Das Original zahlt 2.000 sat für 200 vB, also 10 sat/vB. Ein Ersatz mit 220 vB und 11 sat/vB zahlt 2.420 sat. Er kann dennoch abgelehnt werden, wenn der absolute Aufschlag die geltende incremental relay fee nicht deckt oder zum Konfliktset gebührenzahlende Descendants gehören. Ein geeignetes Wallet berechnet Zielgebühr und Replacement-Schwellen gemeinsam.
CPFP und die Feerate des Transaktionspakets
CPFP nutzt die Abhängigkeit zwischen Transaktionen. Das Child gibt einen unbestätigten Output des Parents aus; ein Miner muss daher beide in der richtigen Reihenfolge aufnehmen. Bei einem einfachen Paar lautet die wirtschaftliche Paket-Feerate (Parent-Fee + Child-Fee) / (Parent-vsize + Child-vsize). Sie ist nicht der arithmetische Mittelwert der beiden einzelnen Feerates.
Ein Parent mit 200 vB zahlt beispielsweise 1.000 sat, also 5 sat/vB. Das Ziel sind 30 sat/vB für das Paket, das Child wird 110 vB groß. Die gesamte Zielgebühr beträgt 30 × 310 = 9.300 sat. Da der Parent 1.000 sat beisteuert, muss das Child ungefähr 8.300 sat oder mehr als 75 sat/vB zahlen. Lediglich 30 sat/vB beim Child würden das Defizit des Parents nicht ausgleichen.
Hat der Parent weitere unbestätigte Ancestors, muss die Rechnung alle vom Miner benötigten Transaktionen umfassen. Das Child muss zudem die minimale Relay-Gebühr erreichen und die Kette in die Ancestor-/Descendant-Policy passen. Historisch verbreitete Bitcoin-Core-Standardwerte sind 25 Transaktionen und 101.000 virtuelle Bytes; Versionen und Konfigurationen können abweichen. Package Relay und Package Mining verbessern bestimmte Fälle, machen aber nicht jede Kette zulässig. Siehe CPFP bei Bitcoin Optech.
Kontrolle von Absender, Empfänger und Wechselgeld
Der Absender kann RBF nur einsetzen, wenn sein Wallet die ursprünglichen Inputs kontrolliert, die offene Transaktion erkennt und einen gültigen Ersatz erstellen kann. Bei einer Auszahlung von einer Custodial Exchange besitzt der Kunde diese Kontrolle nicht; nur die Börse kann ihre Transaktion ersetzen. Eine txid in ein Watch-only-Wallet zu importieren überträgt keine privaten Schlüssel.
Der Empfänger kann CPFP verwenden, wenn sein Wallet die Ausgabe des erhaltenen unbestätigten Outputs erlaubt. Manche Wallets blenden solche Coins aus, sperren sie oder bieten kein Coin Control. Der Absender kann stattdessen seinen Change ausgeben, sofern der Parent einen Change-Output erstellt hat, das Wallet ihn als eigenen erkennt und sein Wert Gebühr sowie einen wirtschaftlich sinnvollen, nicht staubkleinen Ziel-Output ermöglicht.
Damit werden zwei Sackgassen sichtbar. Der Empfänger kann die Zahlung eines anderen nicht per RBF ersetzen, nur weil er einen Output besitzt. Der Absender kann ohne Change kein CPFP durchführen, wenn ihm der Empfänger-Output nicht gehört. Die Erklärung der Bitcoin-UTXO zeigt den Unterschied zwischen Inputs, Ziel-Outputs und Wechselgeld.
Entscheidungstabelle: RBF, CPFP oder warten
| Situation | Erste Wahl | Begründung |
|---|---|---|
| Sie sind Absender, das Wallet kontrolliert die Inputs | RBF | Direkt und meist platzsparender |
| Sie sind Empfänger und können den Output ausgeben | CPFP | Keine Mitwirkung des Absenders nötig |
| Kein nutzbares RBF, aber eigener Change vorhanden | CPFP | Das Child hebt die Paket-Feerate |
| Fee nahe aktueller Schätzung, Zeit ist flexibel | Warten | Vermeidet Überzahlung und Komplexität |
| Custodial-Auszahlung ohne eigenen Output | Warten/Service kontaktieren | Die nötigen Schlüssel fehlen |
| Parent fehlt im Mempool des eigenen Nodes | Erst diagnostizieren | Rebroadcast oder andere Maßnahme kann nötig sein |
Sind beide Wege sauber verfügbar, ist RBF meistens günstiger, weil es eine Transaktion ersetzt, statt eine weitere hinzuzufügen. CPFP ist wertvoll, wenn nur der Empfänger einen geeigneten Output kontrolliert oder Replacement nicht möglich ist. Warten bleibt sinnvoll: Die Mempool-Nachfrage fällt regelmäßig, wobei eine Transaktion unter der minimalen Relay-Fee auch verschwinden statt weitergeleitet werden kann.
Praktisches Szenario mit konkreten Zahlen
Alice sendet 0,01 BTC an Bob. Die Transaktion ist 180 vB groß, zahlt 1.800 sat (10 sat/vB) und signalisiert Opt-in RBF. Danach steigt die Nachfrage; Miner wählen ungefähr 35 sat/vB. Alice benötigt eine schnelle Bestätigung. Ihr Wallet schlägt ein Replacement mit 185 vB und 40 sat/vB vor, insgesamt 7.400 sat. Vor der Signatur prüft sie Bobs Output, Betrag, Change und Fee. Der Ersatz nutzt einen kollidierenden Input und erhält eine neue txid.
Handelt Alice nicht, könnte Bob seinen Output mit einem 120-vB-Child ausgeben. Parent und Child belegen zusammen 300 vB. Für 40 sat/vB braucht das Paket 12.000 sat. Nach Abzug der 1.800 sat des Parents muss das Child ungefähr 10.200 sat zahlen. Bob benötigt dafür einen ausreichend großen Output und ein Wallet, das unbestätigte Coins ausgeben kann.
Die Rechnung ändert sich bei weiteren niedrig bezahlten Ancestors. Sie ändert sich auch, wenn Alice ihren Change bereits ausgegeben hat: Diese Descendants können durch RBF entfernt werden und die erforderliche Gebühr erhöhen. Beide Parteien sollten die Verbreitung über unabhängige Quellen prüfen. Eine Anzeige nur im Explorer des Wallet-Anbieters beweist keine breite Miner-Akzeptanz.
Sicherer Wallet-Ablauf ohne Doppelzahlung
- Bestätigen Sie, dass die Transaktion noch unbestätigt ist, und erfassen Sie die richtige txid. Eine bestätigte Transaktion lässt sich mit keiner Methode ändern.
- Prüfen Sie absolute Fee, vsize, Feerate, Inputs, Outputs sowie Ancestors und Descendants. Verwechseln Sie den Zahlbetrag nicht mit der Miner-Gebühr.
- Wählen Sie anhand mehrerer Schätzer oder des eigenen Nodes eine zur Dringlichkeit passende Ziel-Feerate. Ein Next-Block-Ziel ist bewusst teuer.
- Für RBF verwenden Sie die native Funktion zur Gebührenerhöhung oder einen unterstützten RPC wie Bitcoin Core bumpfee. Erstellen Sie keine unabhängige zweite Zahlung.
- Prüfen Sie auf dem Signiergerät Empfänger, Betrag, Change, absolute Fee und Feerate. Der Aufschlag wird häufig aus dem Change finanziert.
- Für CPFP wählen Sie den Parent-Output ausdrücklich per Coin Control. Berechnen Sie das komplette Paket und lassen Sie einen sinnvollen, nicht staubkleinen End-Output.
- Kontrollieren Sie nach dem Broadcast Replacement oder Parent-Child-Paar über unabhängige Quellen. Bewahren Sie beide txids auf.
Ein Hardware Wallet zeigt möglicherweise nur die neue Transaktion, nicht ihre Beziehung zur alten. Vergleichen Sie jeden Output, statt der Beschriftung „Fee bump“ zu vertrauen. Die Checkliste zum Krypto-Senden ergänzt die Prüfung von Adresse und Netzwerk.
Risiken und Grenzen hinter der Wallet-Oberfläche
Das erste Risiko ist wirtschaftlich: Eine aggressive Schätzung kann zu erheblicher Überzahlung führen. Das zweite ist operativ: Geänderte Outputs oder txids können Buchhaltung, Zahlungsanforderungen und Dienste stören, die nur die ursprüngliche Kennung beobachten. Zero-Conf-Erwartungen bleiben vorläufig, bis die verlangte Zahl von Bestätigungen erreicht ist.
Konkurrierende Replacements können sich in unterschiedlichen Teilen des Netzwerks verbreiten. Das Original kann trotzdem zuerst bestätigt werden, wenn ein Miner den Ersatz nie erhalten oder abgelehnt hat. CPFP kann scheitern, weil ein Miner das erwartete Paket nicht bewertet, ein Ancestor fehlt, Kettenlimits überschritten sind oder das Child selbst nicht relayed wird.
Bei Multi-Party-Protokollen können Pinning und Griefing Replacement teuer oder policywidrig machen. Neue Relay-Regeln verringern einzelne Angriffe, garantieren aber keinen Erfolg. Hohe Werte verdienen ein fortgeschrittenes Wallet und möglichst einen eigenen Node.
Häufige Fehler
- Die Zahlung erneut senden: Zwei unabhängige Transaktionen können beide bestätigt werden. Echtes RBF kollidiert bei den Inputs.
- Nur sat/vB des Child ansehen: CPFP hängt von der gemeinsamen Feerate aller nötigen Ancestors ab.
- Nicht-RBF für endgültig halten: Full RBF und andere Double-Spend-Wege existieren vor der Bestätigung.
- Nur minimal erhöhen: Absolute Fee, incremental relay fee, Konflikte und Evictions zählen gleichzeitig.
- Change unbemerkt ausgeben: Offene Descendants erschweren den Ersatz und können aus Mempools verschwinden.
- Einem Accelerator die Seed Phrase geben: Kein seriöser Relay- oder Mining-Dienst benötigt private Schlüssel.
- Rebroadcast mit Bumping verwechseln: Identische Bytes erneut zu senden ändert weder Fee noch wirtschaftliche Priorität.
Abschlusscheckliste und Fazit
- Ist die Transaktion zweifelsfrei unbestätigt?
- Kontrollieren Sie Inputs für RBF oder einen Output für CPFP?
- Signalisiert sie Opt-in RBF, und wurde Full-RBF-Policy berücksichtigt?
- Sind absolute Fee, vsize und Feerate berechnet?
- Enthält die CPFP-Rechnung alle nötigen Ancestors?
- Erfüllt das Replacement Gebührenschwellen und Mempool-Limits?
- Wurden Empfänger, Betrag, Change und neue txid geprüft?
- Rechtfertigt die Dringlichkeit den Preis oder ist Warten besser?
Bitcoin RBF und CPFP lösen dieselbe Verzögerung von zwei Seiten. RBF ist gewöhnlich das Werkzeug des Absenders und ersetzt die offene Transaktion. CPFP steht dem Inhaber eines ausgebbaren Outputs zur Verfügung und bezahlt das Paket. Die richtige Entscheidung folgt aus Schlüsselhoheit, UTXO-Struktur, Node-Policy und vollständiger Gebührenrechnung. Fehlt eine dieser Angaben, sind Diagnose und Geduld sicherer als eine blinde Signatur.
