承認

送信は確認ではありません。各ノードは、そのメモリプールへの入場許可ポリシーを個別に適用し、時間、料金、競合、パッケージの制限または設定により、異なるノードには異なるセットが表示される場合があります。 RBF は未確認のトランザクションを置き換えることができ、販売者が確認した支払いはブロックに入ることなく消える可能性があります。つまり、zero-conf は速度と引き換えに、二重支払いや不完全なネットワーク ビューのリスクを犠牲にします。 txid もエクスプローラー ページも決済ではありません。 [ビットコイン開発者ガイド — トランザクション] [ビットコイン コア — JSON-RPC の一貫性] [BIP 125 — オプトインの完全な手数料による置換]

マイナーはトランザクションを選択して候補ブロックに入れることができますが、最初の確認は、検証ノードがブロックを受け入れ、そのブロックが最大のチェーンワークを持つアクティブなチェーンに存在する場合にのみ行われます。フルノードは、作業証明、スクリプト、インプットの有無、金額、その他のコンセンサスルールを検証します。マイナーは単にリストを掲載するだけでは無効な支出を償還することはできません。マークル ルートはトランザクションをブロックにコミットし、前のブロックへの参照によってそのブロックが作業履歴の証明に配置されます。 [ビットコインコア — 検証] [ビットコインコア — validation.cpp]

トランザクション ブロックの高さが h で、ノードの現在の先端が H の場合、カウントは H − h + 1 になります。つまり、ブロック自体が最初にカウントされます。値はそのノードの最も検証されたブロックに対して生成されるため、ヒントはノード間でわずかに異なる場合があります。これはトランザクション内に書き込まれず、時間の経過とともに増加することもなく、タイムスタンプから確実に判断することもできません。 Bitcoin Core は、ブロックハッシュ、ブロック高さ、および確認をウォレットまたは UTXO ビューの状態として返します。 [ビットコイン開発者ガイド — ブロックチェーン] [ビットコインコア RPC — gettransaction] [ビットコインコア RPC — getbestblockhash]

競合する有効なブランチがより多くのチェーンワークを取得すると、ノードは古いチップのブロックを切り離し、勝ったブランチを接続します。デタッチされたブロックからのトランザクションは、有効なままであればメモリプールに戻るか、異なる高さでコミットするか、新しいブランチが同じ入力を消費したために競合する可能性があります。ビットコインコアの否定的な確認は、コンセンサスの否定的なブロックではなく、競合の深さに関するウォレットの規則です。 [ビットコインコア RPC — gettransaction] [ビットコインコア — validation.cpp]

追加の確認によりトランザクションの作業証明が追加されるため、通常はコストが高くなり、履歴が書き換えられる可能性が低くなります。決定的な最終性は作成されません。ホワイトペーパーのキャッチアップ計算とそれ以降のモデルはどちらも、攻撃者のハッシュレート シェア、誠実なネットワークの動作、受信者の観察に依存します。 「6 つの確認」は歴史的な工夫であり、コンセンサス定数や普遍的な安全限界ではありません。原理的には、深い再組織化は依然として可能です。 [ビットコインのホワイトペーパー — プルーフ・オブ・ワークと計算] [ローゼンフェルド — ハッシュレートに基づく二重支出の分析]

カウントは、トランザクション自体ではなく、受信者、交換局、またはダウンストリーム プロトコルによって必要とされます。コーヒー、高額商品の返品不可発行、証券取引所の預金、チャネルの開設では、損失率と待機率が異なります。ポリシーでは、値、パフォーマンスの可逆性、攻撃者の動機とハッシュレート、競合または RBF、保管場所とバックエンド、Eclipse リスク、チェーンの異常な状態を考慮する必要があります。確認により、チェーンが上書きされるリスクが軽減されます。盗難されたキー、間違ったアドレス、または取引相手の詐欺は修正されません。 [BIP 125 — オプトインの完全代替手数料] [ローゼンフェルド — ハッシュレートベースの二重支出の分析]

ビットコインはブロック間の平均を約 10 分にすることを目指していますが、プルーフ・オブ・ワークの到着はランダムであり、次のブロックが数秒または数時間で到着する可能性があります。手数料を高くすると、マイナーの選択順序と RBF または CPFP パッケージの経済性が向上しますが、手数料なしでは固定時間が確保され、ブロックの作成が高速化されません。安価なトランザクションは多くのブロックを待機するか、メモリプールから削除される可能性があります。見積もりは確率であり、期限ではありません。 [ビットコイン開発者ガイド — ブロックチェーン] [ビットコイン開発者ガイド — トランザクション]

フルノードは文字列を検証し、独自のアクティブなヒントに従って応答します。 SPV クライアントはヘッダー内の作業証明とマークル証明の包含をチェックしますが、すべてのコンセンサス ルール自体を実行するわけではありません。保管サービスには、独自の信用およびリスク ポリシーも追加されます。フルノードの RPC 結果も、reorg によって変更できるスナップショットです。したがって、問題は「確認の数」だけではなく、ユーザーが誰のチェーンビュー、検証、保管を信頼するかということも重要です。 [ビットコイン ホワイトペーパー — プルーフオブワークと計算] [ビットコイン コア — 検証] [ビットコイン コア — JSON-RPC の一貫性]

他の授業も確認から始まります。 Coinbase の出力は COINBASE_MATURITY = 100 の対象となり、100 個の新しいブロック後にのみ使用できます。これは通常の支払いポリシーとは異なるルールです。 BIP112 CHECKSEQUENCEVERIFY (CSV) スクリプトによって強制される BIP68 相対タイムロックは、出力コミット ブロックから経過時間を測定します。未確認の親は子孫を依存させます。子がアサートされるには、その祖先が同じブロックまたはそれより古いブロック内に存在する必要があります。 [ビットコインコア — consensus.h] [BIP 112 — CHECKSEQUENCEVERIFY]

BOLT 2 を使用すると、Lightning チャネル受信者は、channel_ready の前に minimum_ Depth 資金調達トランザクションを選択できます。数値は二重支出のリスクファイナンスを意味します。 zero-conf チャネルは minimum_ Depth をゼロに設定し、即時ファイナリティではなく、意識的にファンドの信頼とプロトコルの制約に依存します。 Coinbaseの資金調達は入学手続き中です。オペレータは、送信された txid をオープン チャネルとして考慮するのではなく、資金調達アウトポイント、アクティブなチェーンの深さ、および再組織を監視する必要があります。 [BOLT 2 — ピア プロトコル] [ビットコイン オプテック — ゼロ-conf チャネル]