Bestätigung

Das Senden ist keine Bestätigung. Jeder Knoten wendet die Richtlinien für die Zulassung zu seinem Mempool unabhängig an, und verschiedene Knoten können aufgrund von Zeit, Gebühren, Konflikten, Paketbeschränkungen oder Einstellungen einen anderen Satz sehen. RBF kann eine unbestätigte Transaktion ersetzen und die vom Händler gesehene Zahlung kann verschwinden, ohne in den Block zu gelangen. Zero-Conf tauscht also Geschwindigkeit gegen das Risiko von Doppelausgaben und einer unvollständigen Netzwerkansicht; Weder die txid- noch die Explorer-Seite sind Abrechnungen. [Bitcoin-Entwicklerhandbuch – Transaktionen] [Bitcoin Core – JSON-RPC-Konsistenz] [BIP 125 – Opt-in-Voll-Replace-by-Fee]

Ein Miner kann eine Transaktion in einen Kandidatenblock auswählen, die erste Bestätigung erfolgt jedoch nur, wenn der Validierungsknoten den Block akzeptiert und der Block in seiner aktiven Kette mit dem größten Kettenwerk liegt. Der vollständige Knoten überprüft den Arbeitsnachweis, die Skripte, die Existenz und Nichtausgabe von Eingaben, Beträge und andere Konsensregeln. Ein Miner kann eine ungültige Ausgabe nicht einfach durch eine Auflistung einlösen. Der Merkle-Root übergibt die Transaktion an den Block und ein Verweis auf den vorherigen Block fügt sie in den Proof of Work-Verlauf ein. [Bitcoin Core – Validierung] [Bitcoin Core – validation.cpp]

Wenn sich der Transaktionsblock auf der Höhe h befindet und die aktuelle Spitze des Knotens H ist, beträgt die Zählung H − h + 1: Der Block selbst wird zuerst gezählt. Der Wert wird anhand des am besten verifizierten Blocks dieses Knotens generiert, sodass die Spitze zwischen den Knoten leicht variieren kann. Es wird nicht in eine Transaktion geschrieben, wächst nicht mit der Zeit und kann nicht zuverlässig anhand eines Zeitstempels bestimmt werden. Bitcoin Core gibt Blockhash, Blockhöhe und Bestätigungen als Status der Wallet oder UTXO-Ansicht zurück. [Bitcoin-Entwicklerhandbuch – Blockchain] [Bitcoin Core RPC – gettransaction] [Bitcoin Core RPC – getbestblockhash]

Wenn ein konkurrierender gültiger Zweig mehr Kettenarbeit erhält, löst der Knoten die Blöcke der alten Spitze und fügt den siegreichen Zweig hinzu. Eine Transaktion aus einem abgetrennten Block kann in den Mempool zurückkehren, wenn sie gültig bleibt, auf einer anderen Höhe festgeschrieben wird oder in einen Konflikt gerät, weil ein neuer Zweig dieselbe Eingabe ausgegeben hat. Negative Bestätigungen in Bitcoin Core sind eine Wallet-Konvention für die Konflikttiefe, keine negativen Blöcke im Konsens. [Bitcoin Core RPC – gettransaction] [Bitcoin Core – validation.cpp]

Zusätzliche Bestätigungen stellen einen Arbeitsnachweis für eine Transaktion dar, was sie in der Regel teurer macht und es unwahrscheinlich macht, dass der Verlauf neu geschrieben wird. Sie schaffen keine deterministische Endgültigkeit. Sowohl die Aufholberechnung des Whitepapers als auch spätere Modelle hängen vom Hashrate-Anteil des Angreifers, dem Verhalten des ehrlichen Netzwerks und den Beobachtungen des Empfängers ab. „Sechs Bestätigungen“ sind ein historisches Mittel, keine Konsenskonstante oder eine universelle sichere Grenze; Eine tiefgreifende Neuordnung ist grundsätzlich weiterhin möglich. [Bitcoin-Whitepaper – Proof-of-Work und Berechnungen] [Rosenfeld – Analyse von Hashrate-basierten Doppelausgaben]

Die Zählung wird vom Empfänger, der Börse oder dem Downstream-Protokoll benötigt, nicht von der Transaktion selbst. Kaffee, Einwegausgabe teurer Waren, Börseneinzahlung und Kanaleröffnung weisen unterschiedliche Verlust- und Wartequoten auf. Die Richtlinie sollte den Wert, die Reversibilität der Leistung, die Motivation und die Hashrate des Angreifers, Konflikte oder RBF, Verwahrung und Backend, Eclipse-Risiko und einen ungewöhnlichen Zustand der Kette berücksichtigen. Durch die Bestätigung wird das Risiko eines Überschreibens der Kette verringert. wird einen gestohlenen Schlüssel, eine falsche Adresse oder einen Betrug mit der Gegenpartei nicht beheben. [BIP 125 – Opt-in Full-Replace-by-Fee] [Rosenfeld – Analyse Hashrate-basierter Doppelausgaben]

Bitcoin strebt einen durchschnittlichen Abstand von etwa zehn Minuten zwischen den Blöcken an, aber das Eintreffen von Proof-of-Work erfolgt zufällig: Der nächste Block kann in Sekunden oder Stunden eintreffen. Eine höhere Gebühr kann die Reihenfolge der Miner-Auswahl und die RBF- oder CPFP-Paketökonomie verbessern, aber keine Gebühr kauft eine feste Zeit und beschleunigt nicht die Erstellung von Blöcken. Eine günstige Transaktion kann viele Blöcke warten oder aus dem Mempool entfernt werden; Eine Schätzung ist eine Wahrscheinlichkeit, keine Frist. [Bitcoin-Entwicklerhandbuch – Blockchain] [Bitcoin-Entwicklerhandbuch – Transaktionen]

Der vollständige Knoten validiert die Zeichenfolge und antwortet entsprechend seinem eigenen aktiven Tipp. Der SPV-Client prüft den Arbeitsnachweis in Headern und die Einbeziehung von Merkle-Beweisen, führt jedoch nicht alle Konsensregeln selbst aus. Der Depotdienst fügt außerdem seine eigene Kredit- und Risikorichtlinie hinzu. Sogar das RPC-Ergebnis eines vollständigen Knotens ist eine Momentaufnahme, die durch Reorg geändert werden kann. Die Frage ist also nicht nur „wie viele Bestätigungen“, sondern auch, wessen Kettenansicht, Validierung und Verwahrung der Benutzer vertraut. [Bitcoin-Whitepaper – Proof-of-Work und Berechnungen] [Bitcoin Core – Validierung] [Bitcoin Core – JSON-RPC-Konsistenz]

Auch andere Kurse beginnen mit der Konfirmation. Die Ausgabe von Coinbase unterliegt COINBASE_MATURITY = 100 und kann erst nach 100 neuen Blöcken ausgegeben werden; Dies ist eine andere Regel als die reguläre Zahlungsrichtlinie. Relative BIP68-Zeitsperren, die durch das BIP112-Skript CHECKSEQUENCEVERIFY (CSV) erzwungen werden, messen das Alter ab dem Ausgabe-Commit-Block. Ein unbestätigter Elternteil sorgt dafür, dass die Nachkommen abhängig bleiben; Damit ein untergeordnetes Element bestätigt wird, müssen sich seine Vorfahren im selben oder einem älteren Block befinden. [Bitcoin Core – consens.h] [BIP 112 – CHECKSEQUENCEVERIFY]

BOLT 2 ermöglicht es einem Lightning-Kanalempfänger, Finanzierungstransaktionen mit minimaler Tiefe auszuwählen, bevor Channel_ready ist. Die Zahlenwerte „Double-Spending-Risikofinanzierung“. Ein Zero-Conf-Kanal setzt die minimale Tiefe auf Null und verlässt sich bewusst auf Fondsvertrauen und Protokollbeschränkungen statt auf sofortige Endgültigkeit. Die Finanzierung durch Coinbase steht noch aus. Der Betreiber sollte den Finanzierungsausgangspunkt, die Tiefe in der aktiven Kette und die Neuorganisationen überwachen und die gesendete TXID nicht als offenen Kanal betrachten. [BOLT 2 – Peer-Protokoll] [Bitcoin Optech – Zero-Conf-Kanäle]