承認

アリスが友人に 20 000 sat を送ります。sat はビットコインの最小単位です。自分のウォレットは送信済みと表示し、友人にも着金予定が見えていますが、承認数はゼロです。矛盾ではありません。取引の情報は、ビットコインを検証するコンピューターであるノード間に広まりましたが、まだブロックには入っていないのです。Mempool は各ノードが未承認取引を保管する場所で、ネットワーク全体で共有する一つの待ち行列ではありません。採用されたブロックに入ると最初の承認がつき、その次のブロックで二つ、さらに次で三つになります。アリスが送り直す必要はありません。取引の配信も、その識別子 txid も、承認を保証しません。未承認取引は、手数料を上げる Replace-by-Fee（RBF）などで置き換えられることがあります。未承認のまま支払いを受け入れることを zero-conf と呼び、同じ資金を使う別の取引が先に承認されるリスクを引き受けます。 [4] [8] [11]

マイナーは新しいブロックに入れる取引を選び、ビットコインの規則が求める、計算コストをかけて得る結果である有効な Proof of Work を探します。その後、ほかのフルノードがブロックを独自に検証します。署名、金額、使用条件は正しいか、資金はまだ使われていないかを確かめるのです。マイナーの投票でも、一企業の承認印でもありません。無効な支払いをブロックに入れても、有効にはできません。ノードが承認済みと数えるのは、自分が採用したチェーンにある取引です。有効な分岐の中から、chainwork と呼ぶ累積作業量が最大のものを選びます。各ブロックは前のブロックを参照するため、古い履歴を変えるには、その後も作り直す必要があります。 [2] [7]

ビットコインが目指すのは平均十分のブロック間隔であり、時刻表ではありません。次のブロックは数秒後かもしれず、ずっと後かもしれません。一時間待っただけで六承認になるわけではないのです。手数料率を上げればマイナーに選ばれやすくなる場合はありますが、ブロック生成自体は速まりません。ウォレットによっては、未承認取引をより高い手数料の取引に替える RBF や、後続取引が十分な手数料を加え、親取引と一緒に採用する利益を生む CPFP（Child Pays for Parent） が使えます。利用できるかはウォレットと取引次第です。手数料が低いと長く待ったり、ノードの Mempool から外れたりします。待ち時間の表示は予測であり、約束された期限ではありません。 [3] [4]

受取人やサービスが、何承認で支払いを受け入れるかを決めます。少額の買い物と、取り返せない形で高額商品を渡す場合とでは、許容できるリスクが違います。取引所が複数の承認を待つなら、取引はブロックチェーンに記録済みでも、口座残高にはまだ反映されないことがあります。必ずしも失敗ではありません。自分のウォレットで金額、宛先、状態を確認し、サービスの入金条件も確かめましょう。情報源も重要です。攻撃者がノードを孤立させ、限られたネットワークの見方を押しつける攻撃を Eclipse Attack と呼びます。適切な待ち方は金額、取り返しの可否、相手への信頼、検証方法で変わります。承認数だけでは鍵の盗難を防げません。 [11] [13]

支払いの記録の上に、歴史の新しいページが重なっていくと考えてみてください。攻撃者は古い一ページを変えるだけでは足りず、十分な累積作業量を持つ別の有効な続きも作らなければなりません。通常の前提では、承認が増えるほど難しくなります。ただし結果は攻撃者の計算能力やネットワークの状態にも左右されます。よく言われる六承認は歴史的な目安で、合意規則や完全な安全を与える魔法の境界ではありません。書き換えの確率を、あらゆる状況に共通する一つの固定値で示すことはできません。承認が増えても、間違った宛先や詐欺師への送金は直りません。 [1] [13]

二人のマイナーがほぼ同時にブロックを見つけると、攻撃がなくても一時的に分岐します。ノードが別の分岐を新たに採用することを再編と呼びます。取引の出力は金額と使用条件を記録します。次の取引の入力はその出力を参照して使います。未使用の出力を UTXO と呼びます。競合する有効な分岐が、より多くの累積作業量、つまり chainwork を得ると、ノードは元のチェーンの末尾のブロックを外し、勝った分岐をつなぎます。外されたブロックのトランザクションは、まだ有効なら Mempool に戻ることも、別の高さで承認されることもあります。また、新しい分岐がその入力の参照先と同じ出力を使っていれば、競合する取引になる場合もあります。Bitcoin Core の confirmations の負の値は、ウォレットが競合の深さを表す方法です。コンセンサスルール上、ブロックの数が負になるという意味ではありません。 [5] [7]

ブロック高は、番号ゼロの最初のブロックから数えた順番です。トランザクションを含むブロックの高さが h、ノードが採用しているチェーンの最後のブロックの高さが H なら、承認数は H − h + 1 です。取引を含むブロック自体を最初の承認として数えます。結果はそのノードの最良の検証済みブロックを基準にするため、新しいブロックが届く時期には、ノードごとに一時的な違いが生じることがあります。この数値はトランザクションの一部ではなく、時間が過ぎるだけでは増えず、タイムスタンプから確実に求めることもできません。Bitcoin Core は、該当するウォレットや UTXO の参照状態が把握している情報に基づいて、blockhash、blockheight、confirmations などを返します。 [3] [5] [6]

SPV は簡易支払い検証、RPC はノードに問い合わせるプログラム用の窓口です。二つのアプリが同じ承認数を示しても、検証方法の違いは重要です。フルノードはチェーンを検証し、自分が検証済みのチェーンの現在の末尾に基づいて回答します。SPV クライアントは、ブロックヘッダーの Proof of Work と、取引が含まれることを示す Merkle 証明を確認しますが、すべてのコンセンサスルールを自分で検証するわけではありません。Merkle 証明では、データの暗号学的な指紋を少数使って、取引がブロックに含まれることを示します。そのブロックの全取引をダウンロードする必要はありません。利用者に代わって資金を預かるサービスは、さらに独自の入金反映とリスク管理のルールを適用します。フルノードの RPC の結果も、ある時点の状態を示すものであり、再編によって変わり得ます。したがって、承認数だけでなく、誰のチェーンの見方、検証、資金保管を信頼しているかも重要です。 [1] [2] [8]

Coinbase Transaction はマイナーに報酬を支払う、ブロックの特殊な最初の取引で、Coinbase 取引所とは無関係です。タイムロックは資金を使える時点を制限します。BIP は技術提案や標準の文書です。承認を起点とするプロトコル上の待機期間もあります。coinbase トランザクションの出力には COINBASE_MATURITY = 100 というルールが適用され、最も早く使えるのは、その coinbase トランザクションを含むブロックより高さが 100 大きいブロックです。これはブロック報酬を使う前に必ず待つ期間であり、通常の支払いの受取人が決める基準とは異なります。BIP68 の相対タイムロックは、使おうとしている出力の承認を基準にし、ブロック数または時間についてのルールに従って経過を評価します。スクリプトは、出力を使うための条件を定めた短いプログラムです。BIP112 の命令 CHECKSEQUENCEVERIFY（CSV）を使えば、その相対的な条件をスクリプトで強制できます。未承認の出力を使う取引は、その出力を作った取引に依存したままです。後続の取引を承認するには、必要な先行取引が同じブロックか、それ以前のブロックに含まれていなければなりません。 [9] [10]

Lightning Network は、ビットコイン取引で資金を入れたチャネルを通じて支払います。BOLT はその技術仕様の名称です。ここではチャネル開設を説明しており、中での毎回の支払いにブロック待ちが必要という意味ではありません。BOLT 2 は、Lightning チャネルを受け入れる側が、channel_ready メッセージを送る前に必要な資金供給トランザクションの承認数を minimum_depth フィールドで指定できるようにしています。この要件には、資金供給の二重支払いリスクを織り込みます。未承認で開くチャネル、すなわち zero-conf channel は、minimum_depth をゼロに設定し、資金供給者への信頼とプロトコルの制約に意識的に依存します。即座に取り消せない決済が得られるわけではありません。資金供給トランザクション自体が coinbase トランザクションである場合、BOLT 2 はチャネルの開設者ではない側に、少なくとも 100 ブロック待つことを義務付けています。運用者は、特定の資金供給出力である funding outpoint、そのアクティブなチェーンでの深さ、そして再編を監視する必要があります。txid を送信しただけでは、チャネルが開いたことにはなりません。 [12] [14]