History, Speed Up & Cancel (RBF)

Was dieses Werkzeug macht

History ist das gemeinsame lokale Protokoll jeder Transaktion, die über die Tools gesendet wurde (txid, verwendetes Tool, Gebühr, Status). Während eine Transaktion noch im mempool aussteht, stehen zwei RBF (BIP-125) Aktionen zur Verfügung: Speed Up erstellt dieselbe Transaktion mit einer höheren Gebühr neu, indem der Change-Output gekürzt wird, und Cancel ersetzt sie durch eine minimale 1-in / 1-out Transaktion, die die Gelder an Ihre Zahlungsadresse zurücksendet, sodass der ursprüngliche Empfänger nichts erhält.

Zwei RBF-Aktionen auf einen Blick

Beide Aktionen sind Gebührenersetzungen (Replace-by-Fee) und nur möglich, solange die ursprüngliche Tx unbestätigt ist. Weiterleitung und Mining einer Ersetzung hängen von der Richtlinie jedes Knotens und Miners ab (BIP-125-Signalisierung oder Full-RBF, wo aktiviert): Die Annahme ist nie universell oder garantiert. Sie unterscheiden sich in Absicht und Auswirkung auf den Empfänger:

• Beschleunigen — behält dieselben Empfängerausgänge; die höhere Gebühr wird durch Verkleinern des Wechselgeld-Ausgangs finanziert oder, falls das nicht reicht, durch Hinzufügen geprüft sauberer Payment-UTXOs als zusätzliche Eingänge. Der Empfänger wird weiterhin bezahlt, nur schneller.
• Abbrechen — ersetzt die ausstehende Transaktion durch eine 1-in / 1-out Transaktion, die Gelder an Ihre Zahlungsadresse zurücksendet. Der Empfänger erhält nichts. Verwenden Sie dies, wenn Sie eine Überweisung abbrechen möchten (falsche Adresse, falscher Betrag, Meinung geändert), bevor sie bestätigt wird.

Der Rest dieser Seite ist in zwei Teile unterteilt: Teil 1 dokumentiert „Beschleunigen“; Teil 2 dokumentiert „Abbrechen“ (einschließlich, wie zusätzliche Zahlungs-UTXOs hinzugezogen werden, wenn der wiederverwendete Input allein die neue Gebühr nicht deckt).

Teil 1 — Beschleunigen (Gebühr erhöhen, Transaktion beibehalten)

Beschleunigen sendet dieselbe Transaktion mit höherer Gebührenrate erneut. Die Empfängerausgänge bleiben identisch. Die höhere Gebühr wird zuerst durch Verkleinern des CHANGE-Ausgangs der Payment-Wallet finanziert; reicht das nicht, können geprüft saubere Payment-UTXOs als Eingänge ergänzt werden (dabei kann ein neuer CHANGE-Ausgang entstehen).

Wann zu verwenden

• Transaktion steckt seit mehreren Stunden wegen unzureichender Gebühr fest.
• Bestätigungsdringlichkeit (Verkauf, Frist).
• Nachträgliche Prüfung eines vergangenen Vorgangs.

Voraussetzungen

• Xverse Wallet verbunden (nur für Beschleunigung).
• Transaktion in tx_history verfolgt (jede über Bitcoin Tools gesendete Transaktion wird automatisch verfolgt).
• Genug Wert zur Finanzierung der Gebührenerhöhung: entweder lässt sich der Wechselgeld-Ausgang verkleinern, oder es stehen geprüft saubere Payment-UTXOs als zusätzliche Eingänge bereit.

Schritt-für-Schritt-Beschleunigung

1. Öffnen Sie History oder das Wallet Dashboard (Pending Tab).
2. Klicken Sie auf eine ausstehende Transaktion → Speed Up.
3. Das Tool lädt Eingaben von mempool.space.
4. Wähle die neue Gebührenrate. Der Dialog zeigt zwei getrennte Werte: die gültige Mindestersetzung — der Planer nimmt die strengere der beiden Anforderungen, Bitcoin Cores Standard-Incremental-Relay und eine Gebühr strikt über der ursprünglichen Gebührenrate, berechnet auf der tatsächlichen Größe der Ersetzung und den gewählten Ein-/Ausgängen — und die Mempool-Empfehlung für eine wahrscheinliche Bestätigung im nächsten Block. Keine von beiden garantiert Weiterleitung, Mining oder eine Bestätigung im nächsten Block.
5. Der Zahlungsausgang für das Wechselgeld wird automatisch reduziert.
6. Signieren über Xverse; die neue Transaktion ersetzt die ursprüngliche.

Grenzfälle

• Inputs außerhalb des Wallets: abgelehnt (unmöglich, die Transaktion eines anderen per RBF zu ersetzen).
• Change unterhalb des 546-Sat-Schwellenwerts nach Reduzierung: blockiert.
• Transaktion in der Zwischenzeit bereits bestätigt: Speed Up deaktiviert.

Sicherheitsvorkehrungen

• Eigentumsvalidierung bei jeder Eingabe.
• Anti-Dust auf dem reduzierten Wechselgeld.
• Der Planer ist die einzige Instanz, die die Gebühr validiert: Raten unterhalb der berechneten Mindestersetzung werden abgelehnt, und jeder als Eingang ergänzte Payment-UTXO muss geprüft sauber sein (Fail-closed: unbekannte oder unvollständig geprüfte UTXOs werden nie ergänzt).

Quellen & Server

mempool.space (Transaktion abrufen, senden). Aktualisiert tx_history mit der neuen txid.

Müssen Sie die Übertragung abbrechen, anstatt sie zu beschleunigen? Springen Sie zu Teil 2 — Abbrechen (RBF) unten.

Teil 2 — Abbrechen (RBF) — eine ausstehende Transaktion abbrechen

Abbrechen ersetzt eine ausstehende Transaktion durch eine minimale 1-in / 1-out RBF-Transaktion, die die Gelder an Ihre eigene Zahlungsadresse zurücksendet. Der ursprüngliche Empfänger erhält nichts. Es funktioniert, solange die ursprüngliche Transaktion noch nicht gemined wurde.

Möchten Sie die Transaktion nur beschleunigen, ohne ihre Outputs zu ändern? Siehe Teil 1 — Beschleunigen oben.

Warum dies für Ihre Assets sicher ist

BIP-125 erfordert nur mindestens einen gemeinsamen Input zwischen der ursprünglichen und ihrer Ersetzung – nicht alle. Cancel behält einen einzelnen payment Input bei und lässt alle Ordinals-Inputs weg, die die ursprüngliche Transaktion ausgegeben hat.

Da Ordinals-Inputs niemals von der Abbruch-Transaktion referenziert werden, werden sie niemals signiert und niemals On-Chain ausgegeben. Sobald das Original aus dem Mempool entfernt wurde, bleiben diese UTXOs genau wie zuvor im Wallet – dieselbe Regel gilt für Inscriptions, Runes, BRC-20, seltene Sats und Alkane.

Gebührenregeln (BIP-125, kumulativ)

Damit Nodes den Ersatz weiterleiten und Miner ihn bevorzugen, müssen beide Regeln gelten:

1. newFeeRate > oldFeeRate — die neue Transaktion muss die ursprüngliche in sat/vB übertreffen.
2. newFee > oldFee und newFee − oldFee ≥ minRelay × newVsize (~110 Sats Minimum für eine Cancel-Transaktion) — deckt die Relay-Bandbreite der zusätzlichen Transaktion ab.

Die Abbruch-Transaktion ist kleiner als das Original (~110 vB für 1-in / 1-out P2WPKH), sodass bei gleicher Gebührenrate ihre absolute Gebühr niedriger wäre und Regel #2 fehlschlagen würde. Der Dialog füllt daher die minimal mögliche Gebührenrate vor; Sie können sie nur erhöhen, niemals unter diesen Mindestwert senken.

Finanzierung der Stornierung – zusätzliche Zahlungseingaben

Eine 1-in / 1-out Cancel-Transaktion ist nur gültig, wenn der wiederverwendete Zahlungs-Input newFee + 546 Sats (der P2WPKH Dust-Schwellenwert auf dem wiederhergestellten Output) abdeckt. Wenn dies nicht der Fall ist, zieht der Dialog automatisch zusätzliche P2WPKH UTXOs aus Ihrem Zahlungs-Wallet als zusätzliche Funding-Inputs.

• Zuerst bestätigt, größte zuerst: Bestätigte Zahlungs-UTXOs werden in absteigender Wertreihenfolge ausgewählt, bis der erforderliche Gesamtbetrag erreicht ist.
• Vsize und Gebühr werden bei jedem Schritt neu berechnet: Jeder zusätzliche P2WPKH-Input fügt ~68 vB hinzu, daher wird die Ziel-Fee-Rate auf die neue vsize angewendet.
• Strikte Ausschlüsse: niemals der bereits wiederverwendete Outpoint, niemals ein Outpoint, der bereits von einer anderen ausstehenden Transaktion ausgegeben wurde, niemals ein UTXO von der Ordinals-Adresse, niemals ein UTXO, das eine Inscription, Rune, BRC-20 oder seltene Sats enthält.
• Zusammenfassungszeilen im Dialog: Erforderlicher Input-Gesamtbetrag (Cancel-Gebühr + 546 Dust), Verfügbarer Input-Gesamtbetrag und Fehlende X Sats, wenn die Mittel unzureichend sind.

Letzter Ausweg – Verwendung unbestätigter Zahlungs-UTXOs

Wenn bestätigte UTXOs allein den erforderlichen Gesamtbetrag nicht decken, erscheint eine optionale Schaltfläche: „Unbestätigte Zahlungs-UTXOs verwenden“. Sie ermöglicht es der Stornierung, UTXOs aus Ihrer Zahlungs-Wallet zu verbrauchen, die sich noch im mempool befinden.

• Sichtbarkeit umschalten: wird nur angezeigt, wenn bestätigte Mittel unzureichend sind UND mindestens ein geeignetes unbestätigtes UTXO existiert. Standardmäßig ist es ausgeschaltet.
• Auswahlreihenfolge: Bestätigte UTXOs werden immer zuerst verbraucht (größte zuerst), unbestätigte werden nur hinzugefügt, wenn noch ein Mangel besteht – ebenfalls größte zuerst.
• Gleiche Filter: nur UTXOs, deren scriptpubkey_address === paymentAddress geeignet sind. Ordinals-Adress-UTXOs und Asset-tragende Outpoints bleiben ausgeschlossen.
• Gelbes Warnbanner: wird nur angezeigt, wenn die endgültige Auswahl tatsächlich ≥1 unbestätigten Input verbraucht – der Cancel wird erst bestätigt, nachdem seine übergeordneten Transaktionen bestätigt wurden.

Wann stornieren?

• Sie stellen fest, dass die Zieladresse oder der Betrag falsch ist, bevor die Transaktion gemined wird.
• Sie haben Ihre Meinung über die Überweisung geändert, während sie noch ausstehend ist.
• Eine ausstehende Transaktion würde ein Ordinal / Rune UTXO ausgeben, das Sie nicht mehr verschieben möchten.

Voraussetzungen für die Stornierung

• Wallet verbunden und die ursprüngliche Transaktion noch im mempool ausstehend.
• Die ursprüngliche Transaktion muss mindestens einen Input enthalten, der Ihrer Zahlungsadresse gehört.
• Der wiederverwendete Zahlungseingang muss groß genug sein, damit der wiederhergestellte Betrag über dem Dust-Schwellenwert von 546 sat liegt.
• Genügend Zahlungs-sats verfügbar – bestätigt, oder bestätigt + unbestätigt als letzter Ausweg – um newFee + 546 sats zu decken.

Stornierung Schritt für Schritt

1. Öffnen Sie das Wallet Dashboard → Registerkarte „Pending TXs“ (oder die Verlaufsseite).
2. Klicken Sie auf eine ausstehende Transaktion → Abbrechen (neben Beschleunigen).
3. Lesen Sie das rote Warnbanner und bestätigen Sie, dass Sie die Überweisung abbrechen möchten.
4. Der Regler ist mit der minimal gültigen Ersetzungsrate für die Abbruch-Transaktion vorbelegt: der Planer nimmt die strengere der beiden Anforderungen, Incremental-Relay und eine Gebühr strikt über der ursprünglichen Gebührenrate, bezogen auf die tatsächliche Größe der Ersetzung. Erhöhe sie für mehr Priorität — dieses Minimum garantiert weder Weiterleitung noch Mining.
5. Überprüfen Sie die Zusammenfassung: ursprüngliche Gebühr, neue Gebühr, zusätzliche Kosten, in Ihre Wallet wiederhergestellter Betrag.
6. Signieren; die Stornierungs-Transaktion wird gesendet und die ursprüngliche wird entfernt, sobald die Relays konvergieren.

Grenzfälle bei der Stornierung

• Kein Zahlungs-Input im Original (Gebühr vollständig aus einem Ordinals-Input bezahlt): Abbrechen ist mit einer klaren Meldung blockiert – es gibt keinen gebührenzahlenden Input zur Wiederverwendung.
• Wiederhergestellter Betrag unter 546 sats: als Dust blockiert.
• Fee-rate unter den berechneten Mindestwert gesenkt: abgelehnt mit Anzeige des BIP-125-Minimums.
• Abbruch verworfen, Original gemined: Der Verlauf zeigt replaced-original-confirmed – die Übertragung wurde trotz des Versuchs durchgeführt.
• Nicht genügend Guthaben: Selbst wenn unbestätigtes Opt-in aktiviert ist, bleibt die Schaltfläche deaktiviert und der Dialog zeigt Fehlende X sats an, wenn der verfügbare Gesamtbetrag unter dem erforderlichen Gesamtbetrag liegt.
• Eltern-Transaktion verworfen: Ein Abbruch, der einen unbestätigten Input ausgibt, wird ungültig, wenn seine Eltern-Transaktion aus dem mempool entfernt wird – ein erneuter Broadcast ist erforderlich.

Sicherheitsvorkehrungen bei der Stornierung

• Keine Referenz auf Ordinals-Inputs – sie werden niemals von der Stornierungs-Transaktion signiert.
• Beide BIP-125-Gebührenregeln werden zur Erstellungszeit erzwungen (Rate + absolut).
• Eigentumsprüfung des wiederverwendeten Inputs; Dust-Prüfung des wiederhergestellten Outputs.
• Wenn mehrere Zahlungseingänge vorhanden sind, wird der größte ausgewählt, um den wiederhergestellten Betrag zu maximieren.