Eine Zahlung zu versenden bedeutet noch nicht, dass sie bestätigt ist. Bis ein Miner sie in einen Block aufnimmt, können Nodes — Programme, die Bitcoin-Transaktionen prüfen und weiterleiten — sie in ihrem Mempool speichern, einer lokalen Liste wartender Transaktionen. Unter bestimmten Bedingungen dürfen sie durch RBF stattdessen eine neue Transaktion annehmen, die mindestens eines derselben UTXOs ausgibt, also einen noch nicht ausgegebenen Output. Die Ersatztransaktion braucht gültige Signaturen und muss an das Netzwerk übermittelt werden. Eine höhere Gebühr allein garantiert keine schnelle Bestätigung.
Anna hat 20.000 sat verschickt, doch die Zahlung wartet noch. Die Abkürzung sat steht für Satoshi, die kleinste Bitcoin-Einheit. Ihre Wallet bietet an, die Gebühr mit RBF zu erhöhen. Ein einfaches Beispiel: Die ursprüngliche Transaktion gibt 50.000 sat aus. Davon gehen 20.000 sat an den Empfänger, 200 sat sind Gebühr und 29.800 sat fließen als Wechselgeld an Anna zurück. Der Ersatz kann weiterhin 20.000 sat an den Empfänger zahlen, die Gebühr auf 2.000 sat erhöhen und 28.000 sat an Anna zurückgeben. Diese Zahlen erklären das Prinzip und sind keine Empfehlung für die derzeitige Gebühr. Vor dem Signieren prüft Anna die Adresse, den Empfängerbetrag und die neue Gesamtgebühr. Die Wallet muss die erforderlichen Inputs signieren können; eine Hardware-Wallet muss dafür womöglich erneut angeschlossen werden. Der Ersatz hat eine neue txid, seine Transaktionskennung. Der Empfänger braucht daher eventuell einen neuen Link zur Nachverfolgung. Die Gebührenerhöhung ist etwas anderes als eine unabhängige zweite Zahlung mit anderen UTXOs: Beide unabhängigen Zahlungen könnten bestätigt werden und du würdest doppelt bezahlen. [1] [2] [12]
Eine Wallet kann einen Eingang schon vor der ersten Bestätigung anzeigen. Das nennt man zero-conf: Die Zahlung wurde gesehen, steht aber noch nicht in einem Block. Eine andere Version kann zuerst bestätigt werden und der angezeigte Eingang verschwinden. Die Kennzeichnung ‘RBF deaktiviert’ beweist daher nicht, dass die Zahlung sicher ist. Wer gegen eine unbestätigte Zahlung Ware übergibt, übernimmt ein geschäftliches Risiko. Nach der Aufnahme in einen Block kann RBF die Transaktion nicht umschreiben. Eine mögliche Reorganisation der Kette ist ein anderes Risiko, weshalb man bei bedeutenderen Zahlungen mehrere Bestätigungen abwartet. [1]
RBF selbst verlangt nicht, den ursprünglichen Empfänger beizubehalten. Eine Ersatztransaktion kann die Gebühr erhöhen und dieselbe Person bezahlen oder die Mittel an eine andere Adresse schicken. Beide Varianten versuchen, dasselbe UTXO auszugeben. Technisch sind das konkurrierende Ausgaben, ein Double Spend; der Begriff allein sagt noch nicht, ob Betrug vorliegt. Ein Angreifer kann eine fremde Zahlung aber nicht einfach signieren: Auch der Ersatz muss die Ausgabebedingungen einschließlich der erforderlichen Signaturen erfüllen. Bietet eine Wallet ein ‘Stornieren’ durch eine Ersatztransaktion an dich selbst an, ist das ein Versuch, der ursprünglichen Transaktion zuvorzukommen, keine garantierte Rückbuchung. [1]
RBF ändert die wartende Transaktion selbst. Child Pays for Parent (CPFP) lässt die ursprüngliche Transaktion bestehen und erstellt eine neue, die einen ihrer Outputs ausgibt. Um die Gebühr der neuen Transaktion zu erhalten, muss ein Miner auch die ursprüngliche aufnehmen und kann die gemeinsame Gebührenrate betrachten. Die neue Transaktion heißt Kind, die ursprüngliche Elterntransaktion. Erstellen kann sie, wer den betreffenden Output ausgeben kann: etwa der Zahlungsempfänger oder der Absender mit seinem Wechselgeld. Wallet-Unterstützung, nötige Signaturen und Abhängigkeiten bestimmen die Möglichkeiten. CPFP ersetzt die ursprüngliche Zahlung nicht und garantiert ebenfalls keinen Bestätigungstermin. [2]
Der Mempool ist keine gemeinsame Warteschlange für ganz Bitcoin. Jeder Node führt eine eigene Liste und eigene Regeln für die Annahme und Weitergabe wartender Transaktionen. RBF gehört zu dieser lokalen Policy, nicht zum Konsens, der die Gültigkeit von Blöcken bestimmt. Ein Miner kann deshalb eine gültige konkurrierende Transaktion auswählen, die ein anderer Node zuvor nicht gespeichert hatte. Ein Full Node prüft anschließend den gesamten Block nach den Bitcoin-Regeln; seine frühere Mempool-Präferenz entscheidet nicht über das Ergebnis. Die Annahme eines Ersatzes durch einen Node verspricht keine Annahme überall. [1] [6]
Für Wallet-Nutzer sind zwei verschiedene Zahlen wichtig: die Gesamtkosten und die für die Transaktionsgröße angebotene Gebührenrate. Bei beispielhaften 200 vB entsprechen 200 sat einer Rate von 1 sat/vB; bei gleicher Größe sind 2.000 sat eine Rate von 10 sat/vB. Ein virtuelles Byte, vB, ist eine aus dem Transaktionsgewicht abgeleitete Größeneinheit. Beim Neuaufbau kann sich die Größe ändern; die Wallet muss dann auch die Rate neu berechnen. Die Gesamtgebühr ist ein Betrag in Satoshi, der Gebührensatz ein Betrag pro virtuellem Byte in sat/vB. Bei einer einzelnen Ersatztransaktion in Core 30 muss die Gebühr die Summe der Gebühren aller verdrängten Transaktionen sowie zusätzlich die anhand von incrementalrelayfee für die Größe des Ersatzes berechneten Kosten decken. Ihr Gebührensatz muss die Sätze der direkt konfliktierenden Transaktionen übersteigen. Weder ein höherer Gebührensatz allein noch das bloße Hinzufügen von Satoshi genügt. Core 30 verwendet standardmäßig incrementalrelayfee von 0,1 sat/vB, die Knoteneinstellung kann jedoch abweichen. [2] [9]
Von einer wartenden Zahlung kann bereits eine weitere abhängen: Jemand gibt einen Output der ersten, noch unbestätigten Transaktion aus. Solche Folgetransaktionen heißen Nachkommen. Fällt ihre Elterntransaktion weg, sind auch sie im Mempool nicht mehr verwendbar. Der Node muss daher die gesamte betroffene Gruppe berücksichtigen. Das Ersetzen einer Elterntransaktion kann auch Nachkommen aus dem Mempool verdrängen, die ihre Outputs ausgeben. Es geht daher nicht immer nur um den Vergleich zweier Transaktionen. Core 30 begrenzt bei einer einzelnen Ersatztransaktion die Summe der Nachkommenzahlen der direkt konfliktierenden Transaktionen einschließlich dieser Transaktionen selbst auf 100; gemeinsame Nachkommen können dabei mehrfach gezählt werden. Gebühren und Beziehungen innerhalb des Pakets können deshalb den Erfolg der Ersetzung beeinflussen. [2]
Ein Node muss auch verhindern, dass ihn jemand durch ständig neu zu berechnende Ersatztransaktionen überlastet. Das ist Schutz vor DoS, einem Angriff auf die Verfügbarkeit eines Dienstes. Ein UTXO ist ein noch nicht ausgegebener Output einer früheren Transaktion; ein Input der neuen verweist darauf. Die folgenden Regeln beschreiben ausdrücklich Bitcoin Core 30, kein unveränderliches Bitcoin-Gesetz. Die Richtlinie von Bitcoin Core 30 für eine einzelne Ersatztransaktion begrenzt auch neue unbestätigte Inputs und die Anzahl verdrängter Transaktionen. Der Ersatz muss die lokalen Regeln für akzeptierte Transaktionsformen (Standardness) sowie die Regeln für Weiterleitung und Gültigkeit erfüllen; es genügt nicht, dasselbe UTXO auszugeben. Die Grenzen schützen Rechenleistung, Speicher und Übertragungskapazität. Regeln für Paketersetzungen müssen gesondert nach der Knotenversion beurteilt werden. Core 31 änderte diese Policy mit Cluster Mempool: Zusammenhängende unbestätigte Transaktionen werden in Gruppen betrachtet. Eine Ersetzung muss das sogenannte Feerate-Diagramm verbessern, das kumulierte Gebühren dem schrittweise belegten Platz gegenüberstellt. Weitere Bedingungen gelten weiterhin, etwa eine ausreichende Gesamtgebühr und der zusätzliche Betrag für die Weiterleitung der Ersetzung. Übertrage die oben beschriebenen Grenzen von Core 30 deshalb nicht automatisch auf neuere Versionen, sondern prüfe die Regeln deines Knotens. [2] [13]
Warum zeigen manche Wallets noch einen RBF-Schalter? Nodes mit der ursprünglichen Opt-in-RBF-Richtlinie verlangten vorab ein Signal, das einen Ersatz erlaubte. Bitcoin Core 24 machte full-RBF ohne diese Bedingung konfigurierbar, Core 28 aktivierte es standardmäßig und Core 29 entfernte den Schalter mempoolfullrbf. Die folgenden BIP125-Details erklären die ursprüngliche Signalisierung, keine universelle Regel aller heutigen Nodes. BIP125 beschreibt ein explizites Opt-in-Signal, wenn mindestens ein Input einen nSequence-Wert unter 0xfffffffe hat, sowie die Vererbung des Signals von einem unbestätigten Vorfahren. Dies ist eine historische Richtlinie, keine Konsensbedingung. Full-RBF erlaubt die Prüfung eines Ersatzes auch ohne dieses Signal; sein Fehlen garantiert nicht, dass eine Zahlung unersetzbar ist. [1] [3] [4] [5] [6]
Dieser Abschnitt richtet sich an Betreiber eines eigenen Nodes. RPCs sind Befehle, mit denen Software abgefragt oder gesteuert wird. Für die Schaltfläche zum Erhöhen der Gebühr muss man sie nicht kennen. Die RPC getmempoolentry zeigt den Zustand einer Transaktion, sofern sie im Mempool dieses Nodes liegt. testmempoolaccept prüft eine einzelne signierte vorgeschlagene Ersatztransaktion gegen den aktuellen Mempool und die Regeln des eigenen Knotens, ohne sie zu senden. Das Ergebnis verspricht weder die Annahme durch andere Knoten noch die Aufnahme in einen geminten Block. Core 28 aktivierte full-RBF standardmäßig über mempoolfullrbf; Core 29 entfernte diese Option. Die RPC getmempoolinfo zeigt Gebührenparameter, aber das Feld fullrbf gilt in Core 30 als veraltet; prüfe stets Version und konkrete Konfiguration. [5] [6] [7] [8] [10] [11]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Transaction Fees, Mempool, CPFP (Child Pays for Parent), Double Spend, Bestätigung, Fee Rate. Auf diesen Eintrag verweisen außerdem Change Address, Bestätigung, Double Spend, Fee Rate.