Der Konflikt kann bereits vor der Einigung beobachtet werden, aber ein erfolgreicher Double-Spend liegt nur dann vor, wenn das Opfer Wert für eine Transaktion ausgibt und die andere in der Empfangskette gewinnt. Daher sind eine ersetzte Wallet-Zahlung, eine unbeabsichtigte Gebührenerhöhung oder ein erfolgloser Konflikt nicht automatisch Betrug. Zero-Conf-Race und das Überschreiben festgeschriebener Blöcke haben grundsätzlich unterschiedliche Kosten und Risiken.
Jede Eingabe verweist mithilfe einer txid und eines Index auf die vorherige Ausgabe. Zwei Transaktionen stehen in Konflikt, wenn sich mindestens eine Eingabe auf denselben nicht ausgegebenen Outpoint bezieht, sie aber nicht gleichzeitig bezahlen können. Bei der Validierung eines Blocks prüft der Knoten, ob die Eingabe vorhanden ist und nicht früher im angegebenen Verlauf oder an anderer Stelle im selben Block ausgegeben wurde. In einem gültigen UTXO-Set bleibt nur ein Zweig bestehen; Der Angriff erzeugt keine Kopie des Satoshi, sondern versucht, den Empfänger dazu zu bringen, auf den Zweig zu reagieren, der verliert. [Bitcoin-Whitepaper – Transaktionen, Zeitstempelserver und Berechnungen] [Bitcoin-Entwicklerhandbuch – Transaktionen] [Bitcoin Core – validation.cpp]
Es gibt keinen globalen Mempool oder eine Konsensreihenfolge für nicht festgeschriebene Transaktionen vor dem Mining. Peers können zunächst verschiedene Konflikte aufgrund von Promotion, Topologie, Gebührenpolitik, Paketstatus oder Eclipse-Isolation erkennen. First Seen ist eine Relay-Richtlinie und keine Verpflichtung der Bergleute, die erste Option zu bestätigen. Eine txid im Backend des Händlers beweist nur, dass ein unterschriebener Kandidat angekommen ist, nicht, dass das gesamte Netzwerk ihn gesehen oder einen Block gewonnen hat. [Bitcoin-Entwicklerhandbuch – Zahlungsabwicklung] [Bitcoin Core – Mempool-Ersatz]
Durch Ersetzen durch Gebühr kann ein Knoten Mempool-Konflikte ersetzen, die den Gebühren- und Anti-DoS-Regeln entsprechen. full-RBF ist seit Version 28 die Standardrichtlinie in Bitcoin Core. Der Absender kann berechtigterweise die Gebühr für feststeckende Zahlungen erhöhen und die Ausgabe des Empfängers beibehalten oder den Wert umleiten. In beiden Fällen sieht der Konsens gemeinsame Kandidaten und akzeptiert die Variante in der gültigen Mining-Historie. Ein RBF-Signal, ein Austausch oder eine Störung allein beweist keinen Betrug; Eine Transaktion ohne Signal ist wiederum nicht sicher für Zero-Conf. [Bitcoin Core – Mempool-Ersatz] [BIP 125 – Opt-in-Vollaustausch durch Gebühr]
Bei einem Race-Angriff sendet der Zahler eine Transaktion an den Händler und den Konflikt an Miner oder andere Peers, sodass der Händler nicht rückzahlbare Waren ausgibt, bevor der Block eine Option auswählt. Das Ergebnis hängt von der Aktion, der Netzwerkansicht des Händlers, der Wahl der Miner und der Transferzeit ab. Unabhängigere Zuhörer verbessern die Erkennung, schaffen jedoch keine deterministische Endgültigkeit. Die Namen „race“, „Finney“ und „Vector76“ sind Szenariomodelle, keine Transaktionsarrays oder verschiedene Konsensregeln. [Bitcoin-Entwicklerhandbuch – Zahlungsabwicklung] [Karam et al. — Fehlverhalten bei Bitcoin]
Ein Angreifer im Finney-Stil mit der Fähigkeit zum Mining findet zunächst privat den Block, der den Konflikt enthält, gibt ihm den Wert zurück, bezahlt dann den Zero-Conf-Händler mit demselben UTXO und veröffentlicht den versteckten Block nach Erhalt der Ware. Der Plan gelingt nur, wenn der Block nutzbar bleibt und vom Netzwerk akzeptiert wird, bevor ein ehrlicher Konkurrenzblock die Vorbereitung vereitelt; Der Angreifer riskiert sowohl die Blockbelohnung als auch die Mining-Kosten. Das Warten darauf, dass die Transaktion des Händlers in den verifizierten Block aufgenommen wird, beendet die klassische Sequenz, beseitigt jedoch nicht das Risiko einer späteren Neuorganisation. [Bitcoin-Whitepaper – Transaktionen, Zeitstempelserver und Berechnungen] [Karame et al. — Fehlverhalten bei Bitcoin]
Nach der Bestätigung kann der Konflikt die Zahlung nicht mehr einfach aus dem Mempool verschieben: Die alternative gültige Filiale muss die Zahlung überspringen, die zweite Ausgabe einbeziehen und mehr Kettenarbeit als die aktive Kette des Empfängers erzielen. Eine Reorganisation kann auch ohne Betrug in nahezu gleichzeitigen Blöcken oder einem Software- oder Netzwerkvorfall erfolgen; Eine erfolgreiche Doppelausgabe gegen das Opfer besteht nur darin, durch den Sieg im Konflikt an Wert zu gewinnen. Bitcoin Core kann negative Bestätigungen und Wallet-Konflikte für eine verlorene Wallet-Transaktion anzeigen. [Bitcoin Core – Validierung] [Bitcoin Core – validation.cpp] [Bitcoin Core RPC – gettransaction]
Der Hash-Rate-Anteil, die Bestätigungstiefe und der erreichbare Wert des Angreifers bestimmen das zufällige Rennen zwischen privater und ehrlicher Arbeit. Unter 50 % bedeutet nicht, dass die Chance gleich null ist; Die dauerhafte Mehrheit erhöht die Möglichkeit, aufzuholen, erheblich, erlaubt es Minern jedoch nicht, Signaturen zu fälschen, ausländisches UTXO auszugeben, die Ausgabe zu überschreiten oder vollständige Knoten zu zwingen, einen ungültigen Block zu akzeptieren. Zu den Kosten gehören Hashpower, Energie, verlorene ehrliche Belohnungen, Verlustrisiko, Liquidität und Gefährdung; Einnahmen können auch Marktpositionen umfassen, daher reicht der bloße Preis für die Anmietung von Maschinen nicht aus. [Bitcoin-Whitepaper – Transaktionen, Zeitstempelserver und Berechnungen] [Rosenfeld – Analyse von Hashrate-basierten Doppelausgaben] [Garay, Kiayias und Leonardos – Das Bitcoin-Backbone-Protokoll]
Jeder zusätzliche Commit zwingt den alternativen Zweig dazu, einen größeren Teil des Rückstands zu wiederholen, und verringert unter Berücksichtigung der Annahmen die Erfolgswahrscheinlichkeit. Eine universelle Tresornummer gibt es nicht: Kaffee, Auto, Börsenpfand und nicht rückzahlbare Auszahlung weisen unterschiedliche Werte, Motivationen und Korrekturmöglichkeiten auf. Die oft zitierten sechs Aussagen sind eine Konvention, kein Konsens. Die Richtlinie sollte auch die Hash-Ratenverteilung, ungewöhnliche Neuorganisationen, das Vertrauen in das Backend, das Eclipse-Risiko und die Reversibilität von Übergaben überwachen. [Bitcoin-Entwicklerhandbuch – Zahlungsabwicklung] [Rosenfeld – Analyse von Hashrate-basierten Doppelausgaben]
Das Backend kann widersprüchliche Mempool-Ausgaben auf seinem eigenen vollständigen Knoten überwachen, gettxspendingprevout aufrufen, Walletkonflikte lesen, aktive Tipps vergleichen und vor dem Verlust der Bestätigung warnen. Mehr Peers oder unabhängige Knoten reduzieren blinde Flecken, aber das Fehlen eines erkannten Konflikts ist ein schwacher Beweis: Ein Angreifer kann ihn abfangen oder an eine andere Stelle senden. Der Explorer zeigt eine benutzerdefinierte Knotenansicht an und kann verzögert sein. Durch die Erkennung kann die Abgabe gestoppt werden; Es kann Minern nicht sagen, dass sie gewinnen sollen, oder Zero-Conf in eine Bestätigung umwandeln. [Bitcoin Core RPC – gettransaction] [Bitcoin Core RPC – gettxspendingprevout] [Karame et al. — Fehlverhalten bei Bitcoin]
Validieren Sie für die On-Chain-Abwicklung mit Ihrem eigenen vollständigen Knoten, verknüpfen Sie die Bestellung mit der genauen TxID, den Ausgaben und dem Betrag, legen Sie die Tiefe entsprechend dem möglichen Verlust fest, stoppen Sie im Falle einer Neuorganisation oder eines Konflikts die Ausführung und trennen Sie den gutgeschriebenen Saldo vom auszahlbaren Betrag. Behandeln Sie einen unbestätigten Änderungsnachkommen nicht als unabhängig vom übergeordneten Element. Lightning handhabt schnell wiederkehrende Zahlungen anders: Ein bestätigter Finanzierungsausgangspunkt verankert den Kanal und Verpflichtungs-/Widerrufsregeln steuern den Off-Chain-Status; Der Zero-Conf-Kanal vertraut bewusst dem Geldgeber und schließt das Risiko einer doppelten Finanzierung nicht aus. [BOLT 2 – Peer-Protokoll] [Bitcoin Optech – Zero-Conf-Kanäle]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Transaktion, Bestätigung, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. Auf diesen Eintrag verweisen außerdem Bestätigung, Replace-by-Fee (RBF), Problem der byzantinischen Generäle, Eclipse-Angriff.