Finality は決済を最終とみなせる時点を表す。Bitcoin の技術的最終性は確率的であり、深い有効履歴ほど置換が難しいが、普遍的な確認数だけで再編成の不可能性や契約の法的履行は保証できない。
取引の上に加わるブロックは履歴を置き換えるための作業を増やす。安全性は攻撃者の資源やネットワーク状態にも依存する。Finality は固定時点ではなく、プロトコルが数学的な不可逆証明書を発行するわけではない。 [Bitcoin Developer Guide — Block Chain][Bitcoin Developer Guide — Payment Processing]
ノードは最初に規則を検証し、累積作業が最大の有効チェーンを選ぶ。単なるブロック数、接続ノード数、保有者投票はこの選択に代わらない。作業が多くても無効取引が有効にはならない。 [Bitcoin Developer Guide — Block Chain]
独自例：取引ブロックの高さが 800000、同じアクティブチェーンの先端が 800005。確認数は 800005 − 800000 + 1 = 6 で、取引ブロック自体も含む。mempool にあるだけなら 0 確認であり、最初の確認ではない。 [Bitcoin Developer Guide — Payment Processing][Bitcoin Core 28.0 — getblockheader]
再編成で従来ブロックがアクティブな枝から外れる場合がある。Bitcoin Core 28.0 の getblockheader はそのブロックに confirmations = -1 を返す。すべての支払い喪失を意味せず、新しい枝に取引が含まれる、未確認になる、競合する場合があるため状態を再確認する。 [Bitcoin Developer Guide — Block Chain][Bitcoin Core 28.0 — getblockheader]
開発者ガイドは高額支払いの一般的基準に 6 確認を挙げ、リスク分析も考慮する。これは受取人の判断で、コンセンサス規則の変更ではない。平均約一時間でも六ブロックが必ず一時間以内に生まれるわけではない。 [Bitcoin Developer Guide — Payment Processing]
PFMI は最終決済時点と指示の取消可能期限を明確にするよう求める。確認数だけでは契約、銀行支払い、所有権移転の法的効果を決められない。BTC の技術的受入れは取引の全義務履行に代わらない。 [BIS — PFMI principle 8]
Bitcoin には通常の事業者ボタンによる確認済み支払いの取消しはない。任意の返金は受取人による新しい取引で、元の転送を履歴から消さない。受取人と金額は確認基準の到達後だけでなく送信前に確認する。 [Bitcoin.org — Some things you need to know]
取引、ブロック、検証元を記録し、ノードの同期状態とアクティブな枝の変化を監視する。confirmations は照会時点の状態で、永久証明書ではない。確認数の減少や競合への対応も定め、古い記録を新たな証拠と誤認しないようにする。 [Bitcoin Developer Guide — Payment Processing][Bitcoin Core 28.0 — getblockheader]
理解を深めるには、この項目とあわせて次もお読みください 承認, Proof of Work, Settlement risk, Delivery versus payment. 次の項目からも参照されています Byzantine Generals Problem, Nakamoto consensus, Delivery versus payment.