二重支払い

各入力は、txid とインデックスを使用して前の出力を参照します。少なくとも 1 つの入力が同じ未使用のアウトポイントを参照しているが、同時に支払うことができない場合、2 つのトランザクションは競合します。ブロックを検証するとき、ノードは入力が存在し、指定された履歴または同じブロック内の他の場所で以前に使用されていないことを確認します。有効な UTXO セットでは 1 つのブランチのみが残ります。この攻撃は SATOSHI のコピーを生成するのではなく、受信者に負けたブランチ上で動作させようとします。 [ビットコイン ホワイトペーパー — トランザクション、タイムスタンプ サーバー、計算] [ビットコイン開発者ガイド — トランザクション] [ビットコイン コア — validation.cpp]

マイニングの前に、グローバルなメモリプールや、コミットされていないトランザクションのコンセンサス順序はありません。ピアは、プロモーション、トポロジ、料金ポリシー、パッケージのステータス、または Eclipse 分離によるさまざまな競合を最初に確認できます。 First-Seen は中継ポリシーであり、最初のオプションを確認するマイナーの義務ではありません。販売者のバックエンドの txid は、署名された候補者が 1 人到着したことを証明するだけであり、ネットワーク全体がそれを確認したことやブロックを獲得したことを証明するものではありません。 [ビットコイン開発者ガイド — 支払い処理] [ビットコイン コア — Mempool の代替品]

Replace-by-fee を使用すると、ノードは手数料と DoS 対策ルールを満たすメモリプールの競合を置き換えることができます。 full-RBF は、バージョン 28 以降の Bitcoin Core のデフォルト ポリシーです。送信者は、滞留した支払い手数料を合法的に増額し、受信者の出力を保存したり、値をリダイレクトしたりできます。どちらの場合も、コンセンサスは共通の候補を特定し、有効なマイニング履歴内のバリアントを受け入れます。 RBF 信号、交換、またはバンプだけでは不正行為を証明できません。シグナルのないトランザクションは、やはりゼロ-conf では安全ではありません。 [ビットコイン コア — Mempool の交換] [BIP 125 — オプトインの完全な手数料による交換]

競合攻撃では、支払者は 1 つのトランザクションを販売者に送信し、競合をマイナーまたは他のピアに送信するため、ブロックが 1 つのオプションを選択する前に販売者は返品不可の商品を発行します。結果は、プロモーション、販売者のネットワーク ビュー、マイナーの選択、転送時間によって異なります。より独立したリスナーは検出を改善しますが、決定的なファイナリティは作成されません。人種、フィニー、および Vector76 の名前はシナリオ モデルであり、トランザクション配列やさまざまなコンセンサス ルールではありません。 [ビットコイン開発者ガイド - 支払い処理] [Karam et al. — ビットコインにおける不正行為]

マイニング能力を持つフィニー型攻撃者は、まず値を返す競合を含むブロックを非公開で見つけ、次に同じ UTXO で販売者にゼロ conf を支払い、商品を受け取った後に隠しブロックを公開します。この計画は、ブロックが使用可能なままであり、正直なライバルのブロックが準備を妨害する前にネットワークによって受け入れられた場合にのみ成功します。攻撃者はブロック報酬とマイニングコストの両方を危険にさらします。マーチャントのトランザクションが検証済みブロックに含まれるのを待つと、従来のシーケンスは終了しますが、後の再編成リスクは除去されません。 [ビットコイン ホワイトペーパー — トランザクション、タイムスタンプ サーバー、計算] [Karame et al. — ビットコインにおける不正行為]

競合が確認されると、単に支払いをメモリプールから押し出すことはできなくなります。代替の有効なブランチは支払いをスキップし、2 番目の支出を含めて、受信者のアクティブなチェーンよりも多くのチェーンワークを獲得する必要があります。再組織化は、ほぼ同時のブロックでの不正行為や、ソフトウェアやネットワークのインシデントがなくても発生する可能性があります。被害者に対する二重支出が成功しても、紛争に勝つことで価値が得られるだけです。 Bitcoin Core は、紛失したウォレット トランザクションに対する否定的な確認とウォレットの競合を表示できます。 [ビットコインコア — 検証] [ビットコインコア — validation.cpp] [ビットコインコア RPC — gettransaction]

攻撃者のハッシュレートシェア、確認の深さ、取得可能な値によって、プライベートで誠実な作業の確率的競争が決まります。 50% 未満であっても可能性がゼロというわけではありません。永久多数派は追いつく可能性を大幅に高めますが、マイナーが署名を偽造したり、外部 UTXO を消費したり、発行量を超過したり、フルノードに無効なブロックを強制的に受け入れたりすることはできません。コストには、ハッシュパワー、エネルギー、失われた正当な報酬、損失のリスク、流動性、エクスポージャが含まれます。収入には市場での地位も含まれるため、マシンのレンタル料だけでは十分ではありません。 [ビットコイン ホワイトペーパー — トランザクション、タイムスタンプ サーバー、計算] [ローゼンフェルド — ハッシュレート ベースの二重支払いの分析] [ガライ、キアイアス、レオナルドス — ビットコイン バックボーン プロトコル]

コミットが追加されるたびに、代替ブランチはさらに多くのバックログをやり直すことになり、前提条件を考慮すると、成功の可能性が低くなります。普遍的な安全な番号はありません。コーヒー、車、証券取引所の預金と返金不可の出金は、異なる価値、動機、修正の可能性を示します。よく引用される 6 つの肯定は慣例であり、合意ではありません。このポリシーでは、ハッシュレートの配布、異常な再編成、バックエンドの信頼性、Eclipse リスク、ハンドオーバーの可逆性も監視する必要があります。 [ビットコイン開発者ガイド — 支払い処理] [ローゼンフェルド — ハッシュレートベースの二重支払いの分析]

バックエンドは、競合するメモリプールの自身のフルノードでの支出を監視し、gettxspendingprevout を呼び出し、ウォレット競合を読み取り、アクティブなチップを比較し、確認の喪失について警告することができます。ピアや独立ノードが増えると死角は減りますが、競合が検出されないということは弱い証拠であり、攻撃者が競合を傍受したり、他の場所に送信したりする可能性があります。エクスプローラーにはカスタム ノード ビューが表示されますが、遅延する可能性があります。検出により分注を停止できます。マイナーに勝つように指示したり、ゼロ conf を確認に変えたりすることはできません。 [ビットコインコア RPC — gettransaction] [ビットコインコア RPC — gettxspendingprevout] [Karame et al. — ビットコインにおける不正行為]

オンチェーン決済の場合、独自の完全なノードで検証し、注文を正確な txid、出力、および金額でバインドし、損失の可能性に応じて深さを設定し、再組織または競合が発生した場合はフルフィルメントを停止し、クレジットされた残高を出金可能な金額から分離します。未確認の変更の子孫を親から独立したものとして扱わないでください。 Lightning は、高速定期支払いを異なる方法で処理します。確認された資金調達アウトポイントがチャネルを固定し、コミットメント/取り消しルールがオフチェーン状態を制御します。 zero-conf チャネルは意図的に資金提供者を信頼しており、資金の二重支出のリスクを排除しません。 [BOLT 2 — ピア プロトコル] [ビットコイン オプテック — ゼロ-conf チャネル]