Finality

最初にポールが確認できるのは、ウォレットが取引を認識したことだけです。ブロックに取り込まれたこととは違います。ブロックができ、その後にさらにブロックが積み重なると、その履歴を置き換えるために上回る必要がある作業量が増えます。こうして実際の Finality は強まります。ただし、攻撃者が使える資源やネットワークの状態も重要です。プロトコルは不可逆性の数学的な証明書を発行しません。受取人が、その支払いを受け入れる根拠の強さを判断します。 [1] [2]

Full Node は Bitcoin のルールを自分で検証するノードです。履歴が長いという理由だけでは受け入れません。まず有効性を確認し、有効な枝の中から累積作業量が最大のものを選びます。これはブロックが示す作業量であり、人数や保有コイン数による投票ではありません。作業量が多くても無効な取引が有効になることはありません。ポールには、支払いがルールに合っているかと、現在使われている有効な履歴のどれだけ深い位置にあるかの両方が大切です。 [1]

この例では、ポールの取引が高さ 800000 のブロックに入り、同じ枝の現在の先端は高さ 800005 にあります。高さはブロックの位置であり、時刻ではありません。計算は 800005 − 800000 + 1 = 6 承認です。取引が入ったブロック自体も含めるので、その後にできたブロックだけを数えるわけではありません。支払いが mempool、つまりそのノードが保持する未承認取引の集合にあるだけなら、承認数は 0 です。待つだけでは増えません。 [2] [3]

ネットワークが一時的に競合するブロックを認識し、その後、作業量がより多い別の有効な枝を進むことがあります。このようなアクティブな履歴の変更を再編成と呼びます。Bitcoin Core 28.0 の文書では、ブロックヘッダーを調べる getblockheader は、そのブロックがアクティブチェーン外なら confirmations = -1 を返します。これはブロックの状態であり、中の支払いがすべて失われたという意味ではありません。ポールの取引は新しい枝にも含まれているかもしれず、未承認で待っていたり、別の取引と競合したりする場合もあります。個別の状態を再確認する必要があります。 [1] [3]

開発者向けガイドは、高額な支払いでよく使われる目安として 6 承認を挙げ、同時にリスク評価の必要性を説明しています。これは受取人の受け入れ基準であり、Bitcoin の合意ルールが切り替わる地点ではありません。ポールは自転車の価値、起こり得る損失、検証の信頼性を考える必要があります。数字が代わりに判断してくれるわけではありません。また、平均でおよそ一時間でも、六つのブロックが必ず一時間以内に届くとは限りません。採掘に固定時刻表はなく、以前からの一般的な目安は全状況への保証ではありません。 [2]

ポールは承認済みの BTC を受け取っていても、自転車の引き渡しや状態について争うことがあります。金融市場インフラに関する国際原則 PFMI は、決済が最終的に完了する時点と、参加者が指図を撤回できなくなる境界を明確にするよう求めています。これは Bitcoin のブロック数とは異なる枠組みです。承認だけで、契約の法的効果、銀行決済の確定性、売った品物の所有権移転は決まりません。支払いの検証は重要ですが、取引のほかの条件の代わりにはなりません。 [4]

ポールと買い手が返金に合意した場合、通常は元の支払いを受け取った人が新しい取引を送ります。元の送金は履歴に残ります。Bitcoin には、依頼に応じて承認済みの支払いを取り消すボタンを持つ中央窓口はありません。再編成はネットワークのアクティブな履歴の変更であって、操作ミスを直す顧客サービスではありません。だからこそ、送る前に相手と金額を確認します。承認をさらに待っても、入力を間違えた送金は直りません。 [5]

決済アプリの運営者にとって、支払いの受け入れで仕事が終わるわけではありません。取引、そのブロック、検証元を記録し、ノードがネットワークから遅れていないかを検知する必要があります。confirmations は照会時点の状態であって、永久の証明書ではありません。数が減ったり競合が生じたりしたら、事前に決めた手順で対処し、アクティブな枝を改めて確認します。古い画面画像は新しい証拠にはなりません。ポールも、以前のウォレット表示だけでなく、今の支払い状態に基づいて判断すべきなのです。 [2] [3]