Finality bezeichnet die Endgültigkeit der Abwicklung: Wie verlässlich bleibt eine abgeschlossene Übertragung bestehen? Bitcoin bietet eine mit weiterer gültiger Arbeit zunehmende, probabilistische Sicherheit. Keine allgemeingültige Bestätigungszahl schließt allein einen Wechsel des Kettenzweigs aus oder entscheidet, ob ein Vertrag rechtlich vollständig erfüllt wurde.
Zunächst weiß Paul nur, dass seine Wallet von der Transaktion erfahren hat. Das ist noch keine Aufnahme in einen Block. Sobald dieser Block existiert und weitere darauf aufbauen, müsste immer mehr Arbeit übertroffen werden, um diese Historie zu ersetzen. So nimmt die praktische Finality zu. Allerdings spielen auch die Mittel eines möglichen Angreifers und der Zustand des Netzwerks eine Rolle. Das Protokoll stellt kein mathematisches Zertifikat der Unumkehrbarkeit aus. Der Empfänger beurteilt, wie belastbar die Grundlage für die Annahme seiner Zahlung ist. [1] [2]
Ein Full Node prüft die Bitcoin-Regeln selbstständig. Er akzeptiert eine Historie nicht einfach deshalb, weil sie lang ist. Zunächst prüft er ihre Gültigkeit; unter gültigen Zweigen wählt er den mit der größten kumulierten Arbeit. Gemeint ist die durch Blöcke nachgewiesene Arbeit, keine Abstimmung nach Personen oder Münzbesitz. Mehr Arbeit macht eine ungültige Transaktion nicht gültig. Paul muss deshalb beides wissen: Entspricht die Zahlung den Regeln, und wie tief liegt sie in der aktuell verwendeten gültigen Historie? [1]
In unserem Beispiel liegt Pauls Transaktion im Block auf Höhe 800000. Die aktuelle Spitze desselben Zweigs hat die Höhe 800005. Die Höhe bezeichnet die Position eines Blocks, keinen Zeitpunkt. Die Rechnung lautet 800005 − 800000 + 1 = 6 Bestätigungen: Der Block mit der Transaktion selbst zählt mit. Es werden also nicht nur die später angehängten Blöcke gezählt. Liegt die Zahlung lediglich im mempool, der Sammlung unbestätigter Transaktionen dieses Knotens, hat sie 0 Bestätigungen. Bloßes Warten erhöht den Zähler nicht. [2] [3]
Zeitweise können im Netzwerk konkurrierende Blöcke bekannt sein. Später setzt es die Historie auf einem anderen gültigen Zweig mit mehr Arbeit fort. Ein solcher Wechsel heißt Reorganisation. Laut Dokumentation von Bitcoin Core 28.0 liefert die Blockheader-Abfrage getblockheader den Wert confirmations = -1, wenn der Block nicht zur aktiven Kette gehört. Das beschreibt den Block, nicht den automatischen Verlust aller darin enthaltenen Zahlungen. Pauls Transaktion kann auch im neuen Zweig liegen, unbestätigt warten oder mit einer anderen Transaktion konkurrieren. Ihr konkreter Zustand muss erneut geprüft werden. [1] [3]
Der Entwicklerleitfaden nennt 6 Bestätigungen als verbreitete Schwelle für Zahlungen mit hohem Wert und erläutert zugleich die nötige Risikobeurteilung. Das ist eine Annahmeregel des Empfängers, kein Umschaltpunkt im Bitcoin-Konsens. Paul sollte den Wert des Fahrrads, einen möglichen Verlust und die Zuverlässigkeit seiner Prüfung berücksichtigen. Die Zahl entscheidet nicht für ihn. Auch ein Durchschnitt von ungefähr einer Stunde bedeutet nicht, dass sechs Blöcke immer innerhalb einer Stunde eintreffen. Mining folgt keinem festen Fahrplan; eine ältere allgemeine Empfehlung ist keine Garantie für jeden Einzelfall. [2]
Paul kann bestätigte BTC erhalten haben und trotzdem über Zustand oder Übergabe des Fahrrads streiten. Die PFMI, internationale Prinzipien für Finanzmarktinfrastrukturen, verlangen einen klar bestimmten Zeitpunkt endgültiger Abwicklung und eine Grenze, nach der Teilnehmer einen Auftrag nicht mehr widerrufen können. Das ist ein anderer Rahmen als das Zählen von Bitcoin-Blöcken. Bestätigungen allein bestimmen weder die rechtliche Wirkung eines Vertrags noch die Endgültigkeit einer Bankzahlung oder den Eigentumsübergang am Kaufgegenstand. Die Zahlungsprüfung ist wichtig, ersetzt aber nicht die übrigen Vertragsbedingungen. [4]
Vereinbaren Paul und der Käufer eine Rückerstattung, erfolgt sie normalerweise als neue Transaktion durch den Empfänger der ursprünglichen Zahlung. Die ursprüngliche Übertragung bleibt in der Historie erhalten. Bitcoin hat keine zentrale Servicestelle, die bestätigte Zahlungen auf Wunsch per Knopfdruck storniert. Eine Reorganisation ändert die aktive Netzwerkhistorie; sie ist kein Kundendienst zur Korrektur von Versehen. Deshalb sollten Empfänger und Betrag vor dem Senden geprüft werden. Zusätzliche Bestätigungen reparieren keine falsch eingegebene Zahlung. [5]
Für den Betreiber einer Zahlungsanwendung endet die Arbeit nicht mit der Annahme. Er sollte Transaktion, Block und Prüfquelle erfassen und erkennen, ob sein Knoten hinter dem Netzwerk zurückgeblieben ist. confirmations ist ein Zustand zum Abfragezeitpunkt, kein dauerhaftes Zertifikat. Sinkt die Zahl oder entsteht ein Konflikt, braucht die Anwendung vorab festgelegte Abläufe und eine erneute Prüfung des aktiven Zweigs. Ein alter Screenshot ist kein neuer Nachweis. Paul sollte nach dem aktuellen Zustand seiner Zahlung entscheiden, nicht allein danach, was seine Wallet früher angezeigt hat. [2] [3]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Bestätigung, Proof of Work, Settlement risk, Delivery versus payment. Auf diesen Eintrag verweisen außerdem Byzantine Generals Problem, Delivery versus payment.