Bestätigung

Alice schickt einem Freund 20 000 sat, die kleinsten Bitcoin-Einheiten. Ihre Wallet zeigt Gesendet, und der Freund sieht den Zahlungseingang bereits, allerdings mit null Bestätigungen. Das widerspricht sich nicht: Die Zahlung wurde unter Knoten verbreitet, also Computern, die Bitcoin überprüfen, steht aber noch in keinem Block. Ein Mempool ist der lokale Vorrat unbestätigter Transaktionen eines Knotens, keine gemeinsame Warteschlange des gesamten Netzwerks. Sobald die Zahlung in einen akzeptierten Block gelangt, erhält sie die erste Bestätigung. Der nächste Block bringt die zweite, der folgende die dritte. Alice muss nichts erneut senden. Das Verbreiten einer Transaktion bestätigt sie nicht; auch ihre Kennung txid garantiert keine Bestätigung. Eine unbestätigte Transaktion kann ersetzt werden, etwa mit Replace-by-Fee (RBF) zum Erhöhen der Gebühr. Eine Zahlung ohne Bestätigung anzunehmen heißt zero-conf. Dabei trägt man das Risiko, dass stattdessen eine andere Ausgabe derselben Mittel bestätigt wird. [4] [8] [11]

Ein Miner wählt Transaktionen für einen neuen Block aus und sucht einen gültigen Proof of Work, das von den Bitcoin-Regeln verlangte Ergebnis aufwendiger Berechnungen. Andere vollständige Knoten prüfen anschließend den Block selbst: Stimmen Signaturen, Beträge und Ausgabebedingungen, und sind die Mittel noch nicht ausgegeben? Das ist weder eine Abstimmung der Miner noch der Genehmigungsstempel einer Firma. Ein Miner kann eine ungültige Zahlung nicht gültig machen, indem er sie in einen Block aufnimmt. Ein Knoten zählt sie nur in der von ihm akzeptierten Kette als bestätigt. Unter gültigen Zweigen wählt er den mit der größten angesammelten Arbeit, der chainwork. Jeder Block verweist auf seinen Vorgänger. Wer ältere Geschichte ändern will, muss deshalb auch deren Fortsetzung neu aufbauen. [2] [7]

Bitcoin strebt durchschnittlich zehn Minuten zwischen Blöcken an, keinen Fahrplan. Ein neuer Block kann nach Sekunden oder viel später kommen. Eine Stunde Warten bedeutet nicht automatisch sechs Bestätigungen. Ein höherer Gebührensatz kann die Chance verbessern, dass ein Miner Ihre Transaktion auswählt; Blöcke entstehen dadurch nicht schneller. Manche Wallets unterstützen RBF, den Ersatz einer unbestätigten Transaktion durch eine mit höherer Gebühr, oder CPFP (Child Pays for Parent): Eine abhängige Transaktion zahlt genug Gebühren, damit sich ihre gemeinsame Aufnahme mit der Vorgängertransaktion lohnt. Ob das möglich ist, hängt von Wallet und Transaktion ab. Eine niedrige Gebühr kann langes Warten oder die Entfernung aus dem Mempool eines Knotens bedeuten. Nehmen Sie die Schätzung der Wallet daher als Schätzung, nicht als zugesagten Termin. [3] [4]

Der Empfänger oder Dienst legt fest, ab wie vielen Bestätigungen er eine Zahlung akzeptiert. Bei einem kleinen Einkauf kann er ein anderes Risiko tragen als bei der unwiderruflichen Übergabe teurer Ware. Wartet eine Börse mehrere Bestätigungen ab, kann die Transaktion bereits in der Blockchain stehen, obwohl das Guthaben auf Ihrem Börsenkonto noch fehlt. Das ist nicht automatisch ein Zahlungsfehler. Prüfen Sie Betrag, Zieladresse und Status in Ihrer Wallet sowie die Gutschriftbedingungen des Dienstes. Auch die Informationsquelle zählt. Ein Angreifer kann einen Knoten isolieren und ihm eine eingeschränkte Netzwerksicht liefern; das heißt Eclipse Attack. Angemessenes Warten hängt daher von Wert, Korrekturmöglichkeiten, Vertrauen in die Gegenpartei und Art der Prüfung ab. Die Bestätigungszahl allein schützt nicht vor einem gestohlenen Schlüssel. [11] [13]

Stellen Sie sich die Zahlung als Eintrag vor, über dem weitere Seiten der Historie hinzukommen. Eine alte Seite zu ändern reicht nicht: Ein Angreifer müsste eine konkurrierende gültige Fortsetzung mit genügend angesammelter Arbeit erzeugen. Unter üblichen Annahmen wird das mit weiteren Bestätigungen schwieriger. Das Ergebnis hängt aber auch von der Rechenleistung des Angreifers und dem Netzwerkzustand ab. Die oft genannten sechs Bestätigungen sind eine historische Orientierung, keine Konsensregel oder magische Grenze völliger Sicherheit. Eine einzige feste Wahrscheinlichkeit für eine Änderung der bisherigen Blockchain-Historie lässt sich nicht seriös auf alle Situationen übertragen. Mehr Bestätigungen korrigieren auch keine falsche Adresse oder eine Zahlung an einen Betrüger. [1] [13]

Ein kurzer Kettenzweig kann auch ohne Angriff entstehen, wenn zwei Miner fast gleichzeitig einen Block finden. Wechselt ein Knoten auf einen anderen siegreichen Zweig, spricht man von einer Reorganisation. Ein Transaktionsausgang erfasst einen Betrag und seine Ausgabebedingungen; ein Eingang einer späteren Transaktion verweist darauf und gibt ihn aus. Ein noch nicht ausgegebener Ausgang heißt UTXO. Erreicht ein konkurrierender gültiger Kettenzweig mehr angesammelte Arbeit, also chainwork, trennt der Knoten die letzten Blöcke seiner bisherigen Kette ab und hängt den siegreichen Zweig an. Eine Transaktion aus einem abgetrennten Block kann in den Mempool zurückkehren, sofern sie weiterhin gültig ist, oder auf einer anderen Höhe bestätigt werden. Sie kann auch in Konflikt geraten, wenn der neue Zweig denselben Ausgang ausgibt, auf den ihr Eingang verweist. Ein negativer Wert in confirmations ist in Bitcoin Core die Art, wie die Wallet die Tiefe eines Konflikts ausdrückt. Er bedeutet keine negative Blockzahl in den Konsensregeln. [5] [7]

Die Blockhöhe ist die Position in der Folge, gezählt vom Anfangsblock mit der Nummer null. Liegt der Block der Transaktion auf Höhe h und der letzte Block der aktiven Kette des Knotens auf Höhe H, beträgt die Bestätigungszahl H − h + 1. Der Block mit der Transaktion zählt somit als erster. Das Ergebnis hängt vom besten geprüften Block dieses Knotens ab und kann daher beim Eintreffen neuer Blöcke zwischen Knoten kurzzeitig abweichen. Es ist kein Bestandteil der Transaktion, wächst nicht allein durch Zeitablauf und lässt sich nicht zuverlässig aus einem Zeitstempel ermitteln. Bitcoin Core liefert Angaben wie blockhash, blockheight und confirmations entsprechend dem Zustand, den die jeweilige Wallet oder UTXO-Sicht kennt. [3] [5] [6]

SPV bezeichnet eine vereinfachte Zahlungsprüfung, RPC eine Programmierschnittstelle für Knotenabfragen. Der Unterschied der Prüfmethoden zählt auch dann, wenn zwei Anwendungen dieselbe Zahl anzeigen. Ein vollständiger Knoten prüft die Kette und antwortet anhand des aktuellen Endes seiner eigenen geprüften Kette. Ein SPV-Client prüft Proof of Work in den Blockheadern und einen Merkle-Nachweis über die Aufnahme der Transaktion, überprüft jedoch selbst nicht alle Konsensregeln. Ein Merkle-Nachweis belegt mit einer kurzen Folge kryptografischer Fingerabdrücke, dass eine Transaktion im Block enthalten ist, ohne alle Transaktionen des Blocks herunterzuladen. Ein Dienst, der Mittel für Nutzer verwahrt, wendet zusätzlich eigene Regeln für die Gutschrift von Zahlungen und das Risikomanagement an. Selbst ein RPC-Ergebnis eines vollständigen Knotens erfasst einen Zustand zu einem bestimmten Zeitpunkt, den eine Reorganisation verändern kann. Neben der Bestätigungszahl kommt es deshalb darauf an, wem der Nutzer bei der Beobachtung der Kette, der Prüfung und der Verwahrung seiner Mittel vertraut. [1] [2] [8]

Eine Coinbase Transaction ist die besondere erste Transaktion eines Blocks, die den Miner belohnt; mit der Börse Coinbase hat sie nichts zu tun. Eine Zeitsperre begrenzt, wann Mittel ausgegeben werden dürfen. BIP bezeichnet einen technischen Vorschlag oder Standard. Die Bestätigung setzt auch bestimmte Fristen des Protokolls in Gang. Für den Ausgang einer Coinbase-Transaktion gilt COINBASE_MATURITY = 100: Er darf frühestens in einem Block ausgegeben werden, dessen Höhe um 100 über der Höhe des Blocks mit dieser Coinbase-Transaktion liegt. Das ist eine vorgeschriebene Wartefrist vor dem Ausgeben einer Blockbelohnung und keine Entscheidung des Empfängers einer gewöhnlichen Zahlung. Relative Zeitsperren nach BIP68 leiten sich von der Bestätigung des auszugebenden Ausgangs ab und bewerten sein Alter anhand von Block- oder Zeitregeln. Ein Skript ist ein kurzes Programm, das die Bedingungen für die Ausgabe eines Ausgangs festlegt. Der Befehl CHECKSEQUENCEVERIFY (CSV) aus BIP112 ermöglicht es, diese relative Bedingung im Skript durchzusetzen. Eine Transaktion, die einen unbestätigten Ausgang ausgibt, bleibt von der Transaktion abhängig, die ihn erzeugt hat. Damit die nachfolgende Transaktion bestätigt werden kann, müssen ihre Vorgänger im selben oder in einem früheren Block enthalten sein. [9] [10]

Lightning Network ermöglicht Zahlungen über Kanäle, deren Finanzierung durch Bitcoin-Transaktionen erfolgt. BOLT bezeichnet seine technischen Spezifikationen. Hier geht es um das Öffnen eines Kanals, nicht um das Warten auf einen Block bei jeder Zahlung darin. BOLT 2 erlaubt der Partei, die einen Lightning-Kanal annimmt, im Feld minimum_depth die erforderliche Bestätigungszahl der Finanzierungstransaktion vor dem Senden von channel_ready festzulegen. Damit berücksichtigt sie das Double-Spend-Risiko der Finanzierung. Ein ohne Bestätigung geöffneter Kanal, ein zero-conf channel, setzt minimum_depth auf null und verlässt sich bewusst auf Vertrauen in den Finanzierer sowie auf Einschränkungen des Protokolls. Er erhält dadurch keine sofortige unumkehrbare Abwicklung. Ist die Finanzierungstransaktion selbst eine Coinbase-Transaktion, verlangt BOLT 2 von der Partei, die den Kanal nicht eröffnet, mindestens 100 Blöcke zu warten. Der Betreiber sollte den konkreten Finanzierungsausgang, den funding outpoint, seine Tiefe in der aktiven Kette und Reorganisationen verfolgen. Eine verbreitete txid allein bedeutet noch keinen geöffneten Kanal. [12] [14]