38 / 7362X

Double Spend

Der Versuch, dieselben Mittel zweimal auszugeben

Bei einem Double Spend sollen dieselben Bitcoin-Mittel für widersprüchliche Zahlungen verwendet werden. In einer gültigen Historie kann nur eine davon bestehen. Gefährlich wird es, wenn jemand Ware für eine Zahlung übergibt, die sich am Ende nicht durchsetzt.

Ein Double Spend erzeugt keine neuen Bitcoins. Der Absender erstellt zwei Transaktionen, die jeweils auf mindestens einen identischen, zuvor empfangenen Betrag zugreifen. Beide können sich im Netzwerk verbreiten, aber nicht in derselben Historie gültig sein. Wer eine unbestätigte Zahlung, also zero-conf, annimmt, handelt möglicherweise, bevor feststeht, welche Variante sich durchsetzt.

Angenommen, Tom hat einen früher empfangenen Output über 100 000 sat, die kleinsten Bitcoin-Einheiten. Ein solcher noch nicht ausgegebener Output heißt UTXO. Er bereitet eine Zahlung von 99 000 sat an Alice vor; 1 000 sat bleiben als Gebühr. Er könnte aber auch eine andere Transaktion unterschreiben, die denselben UTXO verwendet und das Geld woandershin schickt. Beide greifen auf dieselben Mittel zu und widersprechen sich deshalb. Das ist nicht wie das Kopieren einer Datei: Ein Bitcoin-Knoten, also ein Rechner, der die Regeln prüft, lässt denselben Output in einer gültigen Kette nicht zweimal ausgeben. Der Betrug wäre erfolgreich, wenn Alice für die erste Zahlung Ware übergibt, sich in der akzeptierten Historie aber die zweite durchsetzt. Es sind keine neuen Münzen entstanden; Alice hat auf die unterlegene Variante vertraut. Technisch verweist jeder Input mit der Transaktionskennung txid und der Output-Nummer auf einen früheren Output. Dieses Paar heißt outpoint. [1] [3] [7]

Alice kann die eingehende Zahlung nach wenigen Sekunden sehen. Damit steht sie aber noch nicht in einem Block. Der Mempool ist der lokale Vorrat unbestätigter Transaktionen eines Knotens. Es gibt weder einen globalen Mempool noch eine für das ganze Netzwerk gemeinsame Empfangsreihenfolge. Ein anderer Knoten könnte zuerst die widersprüchliche Variante erhalten oder Alices Variante noch gar nicht gesehen haben. Eine First-seen-Regel bevorzugt beim Weiterleiten die zuerst empfangene Variante. Sie verspricht nicht, dass ein Miner diese in einen Block aufnimmt. Ein Wallet-Screenshot oder die txid allein belegt daher keine abgeschlossene Zahlung. Entscheidend ist der Zustand der konkreten Zahlung in einer zuverlässig geprüften Kette. [2] [5]

Vielleicht sendet Alice selbst eine ehrliche Zahlung, die schon lange wartet. Replace-by-Fee (RBF) erlaubt, eine unbestätigte Transaktion zu ersetzen, meist durch eine mit höherer Gebühr. Der Empfänger kann denselben Betrag bekommen, obwohl sich die txid ändert. Die Ersatztransaktion nutzt zumindest teilweise dieselben Mittel und widerspricht deshalb technisch der ursprünglichen, ohne dass jemand den Empfänger betrügen will. Entscheidend sind Inhalt und Umstände der neuen Zahlung, nicht das RBF-Etikett. Derselbe Mechanismus kann das Geld allerdings auch umleiten. Full-RBF ist seit Version 28 die Standardregel in Bitcoin Core: Die ursprüngliche Transaktion muss ihre Ersetzbarkeit nicht ankündigen. Die Ersatztransaktion muss weiterhin die Gebühren- und Missbrauchsschutzregeln des Knotens erfüllen. Auch ohne RBF-Signal ist eine unbestätigte Zahlung deshalb nicht unumkehrbar. [5] [6] [15]

Eine Zahlung erhält eine Bestätigung, wenn sie in einen gültigen, vom Knoten akzeptierten Block gelangt. Weitere Blöcke erschweren gewöhnlich den Austausch dieser Historie und senken damit das Betrugsrisiko. Eine sichere Anzahl für jede Situation gibt es jedoch nicht. Die Bezahlung für einen Kaffee zu verlieren ist etwas anderes als ein Auto zu übergeben oder eine große Börsenauszahlung freizugeben. Die oft genannten sechs Bestätigungen sind eine Konvention, keine Bitcoin-Regel. Empfänger sollten Betrag, Möglichkeiten zur Wiedergutmachung, ungewöhnliches Kettenverhalten und die Qualität ihrer Informationen berücksichtigen. Die Isolation eines Knotens durch einen Eclipse Attack kann dessen Netzwerksicht verfälschen. Warten ergänzt deshalb das Prüfen, statt es zu ersetzen. [2] [10]

Der Wechsel eines Knotens auf einen anderen gültigen Kettenzweig heißt Reorganisation. Proof of Work belegt die Arbeit zur Erzeugung von Blöcken; die aufsummierte Arbeit eines Zweigs heißt chainwork. Nach einer Bestätigung kann eine widersprüchliche Transaktion die Zahlung nicht mehr einfach aus dem Mempool verdrängen. Ein alternativer gültiger Kettenzweig muss die ursprüngliche Zahlung auslassen, die zweite Ausgabe enthalten und mehr Arbeit, also chainwork, ansammeln als die aktive Kette des Empfängers. Eine Kettenreorganisation kann auch ohne Betrug entstehen, etwa bei fast gleichzeitig geminten Blöcken oder einem Software- beziehungsweise Netzwerkfehler. Ein Double Spend gegenüber dem Opfer ist erst dann erfolgreich, wenn der Angreifer durch den Sieg der widersprüchlichen Transaktion einen Wert erhält. Für die unterliegende Wallet-Transaktion kann Bitcoin Core im Feld confirmations eine negative Bestätigungszahl und im Feld walletconflicts die zugehörigen Konflikte anzeigen. [4] [7] [8]

Hashrate bezeichnet die Rechengeschwindigkeit beim Mining. Ein größerer Anteil hilft im Wettlauf um die Historie, setzt aber andere Regeln nicht außer Kraft. Ob ein heimlich geminter Zweig die ehrlich erzeugte Kette einholt, hängt unter anderem vom Anteil des Angreifers an der Rechenleistung des Netzwerks und von der Zahl der Bestätigungen ab. Der mögliche Gewinn beeinflusst vor allem, ob sich der Angriff lohnt. Bei einem Anteil unter 50 % ist die Erfolgschance nicht null; eine dauerhafte Mehrheit erhöht die Möglichkeit, den anderen Kettenzweig einzuholen, erheblich. Selbst eine Mehrheit erlaubt es Minern jedoch nicht, Signaturen zu fälschen, fremde UTXOs auszugeben, die Ausgaberegeln neuer Bitcoins zu verletzen oder vollständige Knoten zur Annahme eines ungültigen Blocks zu zwingen. Bei der Bewertung eines Angriffs sind Rechenleistung, Energie und entgangene Belohnungen aus ehrlichem Mining zu berücksichtigen. Auch verfügbares Kapital, das Risiko eines Fehlschlags und die Möglichkeit, entdeckt zu werden, spielen eine Rolle. Zum Ertrag können auch Gewinne aus Positionen an den Finanzmärkten gehören. Der Mietpreis von Mining-Geräten allein reicht daher für eine Schätzung nicht aus. [1] [10] [12]

Race meint hier einen Wettlauf beim Timing: Empfänger und Miner können zuerst unterschiedliche Transaktionen sehen. Bei einem Angriff vom Typ Race Attack sendet der Zahler eine Transaktion an den Händler und eine widersprechende Transaktion an Miner oder andere Knoten. Er will erreichen, dass der Händler die Ware unwiderruflich übergibt, bevor ein Block eine der Varianten auswählt. Das Ergebnis hängt von der Verbreitung der Transaktionen, der Netzwerksicht des Händlers, der Auswahl der Miner und dem Zeitpunkt der Übergabe ab. Mehr unabhängige Knoten, die das Netzwerk beobachten, verbessern die Erkennung von Konflikten, garantieren aber keine unumkehrbare Abwicklung. Die Namen race, Finney und Vector76 beschreiben Angriffsszenarien, keine Datenfelder einer Transaktion oder unterschiedliche Konsensregeln. [2] [11]

Finney Attack bezeichnet ein Szenario, bei dem der Angreifer auch über Mining-Kapazität verfügt. Das ist nicht die normale Gebührenerhöhung einer Wallet. Bei einem Finney Attack mint ein Angreifer mit eigener Mining-Möglichkeit zunächst im Verborgenen einen Block mit einer widersprüchlichen Transaktion, die den Wert an ihn zurückführt. Anschließend bezahlt er mit demselben UTXO einen Händler, der Zahlungen ohne Bestätigung annimmt, und veröffentlicht den verborgenen Block nach Erhalt der Ware. Der Plan gelingt nur, wenn der Block weiterhin verwendbar ist und das Netzwerk ihn annimmt, bevor ein ehrlicher konkurrierender Block die Vorbereitung zunichtemacht. Der Angreifer riskiert damit die Blockbelohnung und die Mining-Kosten. Auf die Aufnahme der Händlertransaktion in einen validierten Block zu warten, unterbricht diesen klassischen Ablauf, beseitigt aber nicht das Risiko einer späteren Kettenreorganisation. [1] [11]

RPC ist die Programmierschnittstelle des Knotens. Die folgenden Namen sind Befehle und Datenfelder für Entwickler von Zahlungssystemen, keine weitere Bestätigungsart. Das System des Händlers kann auf einem eigenen vollständigen Knoten widersprüchliche Ausgaben im Mempool verfolgen, gettxspendingprevout aufrufen, das Feld walletconflicts lesen, den letzten Block der aktiven Kette vergleichen und vor dem Verlust von Bestätigungen warnen. Mehr verbundene oder unabhängige Knoten verringern blinde Flecken. Ein nicht erkannter Konflikt ist jedoch nur ein schwacher Sicherheitsbeleg: Ein Angreifer kann die widersprüchliche Transaktion zurückhalten oder auf einem anderen Weg versenden. Ein Blockexplorer zeigt die Sicht seines eigenen Knotens und kann hinterherhinken. Ein erkannter Konflikt ermöglicht es, die Warenübergabe anzuhalten. Er kann Minern aber weder die Auswahl einer bestimmten Transaktion vorschreiben noch eine unbestätigte Zahlung einer bestätigten gleichstellen. [8] [9] [11]

Prüfen Sie die tatsächlich eingehende Zahlung, ihr Ziel, den Betrag und ihre Bestätigungen. Ein Beleg des Absenders ersetzt das nicht. Ein eigener vollständiger Knoten erlaubt die direkte Prüfung der Regeln. Bei einem fremden Dienst sollten Sie verstehen, wessen Informationen und gegebenenfalls Verwahrung Sie nutzen. Ein Händlersystem sollte Bestellungen bestimmten Outputs zuordnen und Ersatztransaktionen verfolgen. Bei Konflikten oder verlorenen Bestätigungen muss es eine unumkehrbare Übergabe anhalten. Eine spätere Zahlung, die unbestätigtes Wechselgeld ausgibt, hängt von der ersten Transaktion ab und ist kein unabhängiger Sicherheitsnachweis. Lightning Network ermöglicht schnelle Zahlungen in Kanälen, die durch eine Bitcoin-Transaktion finanziert werden. Die Kanalteilnehmer tauschen signierte commitment-Transaktionen aus, die die Verteilung der Mittel festhalten. Bei einer Aktualisierung geben sie der Gegenpartei geheime Daten, mit denen diese eine spätere Veröffentlichung eines überholten Zustands bestrafen kann; diese Entwertung des alten Zustands heißt revocation. Der Schutz setzt voraus, dass ein solcher Versuch rechtzeitig erkannt und beantwortet wird. Das ist ein anderer Mechanismus als die Warenübergabe gegen eine unbestätigte Blockchain-Zahlung. Ein ohne Bestätigung geöffneter zero-conf channel vertraut bewusst seiner finanzierenden Partei; das Risiko eines Double Spend dieser Finanzierung bleibt bestehen. [13] [14]

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, Reorg, Stale Block, Replace-by-Fee (RBF).

DOC · 001Bitcoin whitepaper — Transactions, Timestamp Server and CalculationsDokumentation DOC · 002Bitcoin Developer Guide — Payment ProcessingDokumentation DOC · 003Bitcoin Developer Guide — TransactionsDokumentation DOC · 004Bitcoin Core — ValidationDokumentation DOC · 005Bitcoin Core — Mempool ReplacementsDokumentation DOC · 006BIP 125 — Opt-in Full Replace-by-FeeSpezifikation DOC · 007Bitcoin Core — validation.cppDokumentation DOC · 008Bitcoin Core RPC — gettransactionDokumentation DOC · 009Bitcoin Core RPC — gettxspendingprevoutDokumentation DOC · 010Rosenfeld — Analysis of Hashrate-Based Double SpendingDokumentation DOC · 011Karame et al. — Misbehavior in BitcoinDokumentation DOC · 012Garay, Kiayias and Leonardos — The Bitcoin Backbone ProtocolDokumentation DOC · 013BOLT 2 — Peer ProtocolSpezifikation DOC · 014Bitcoin Optech — Zero-conf channelsDokumentation DOC · 015Bitcoin Core 28.0 — Release NotesDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung