執筆者: BitMEX リサーチ
ビットコイン ブロックチェーンには 2 つの同一のトランザクション セットがあり、1 つのトランザクション セットがもう 1 つのトランザクション セットを「挟み込んで」おり、両方とも 2010 年 11 月中旬に発生しました。トランザクションが重複すると混乱が生じる可能性があり、ビットコイン開発者は長年にわたりさまざまな方法でこれに対抗してきました。この問題はまだ 100% 解決されておらず、次に重複取引が発生する可能性は 2046 年になる可能性があります。重複取引に関連するリスクは現在最小限ですが、検討する価値のある興味深い問題です。

概要
通常のビットコイン トランザクションでは、前のトランザクションのトランザクション ID (TXID) を参照して、前のトランザクションからの出力を少なくとも 1 つ使用します。これらの未使用の出力は 1 回しか使用できません。2 回使用できる場合は、ビットコインを 2 回使用したことになるため、価値がなくなります。しかし、実際にはビットコインには 2 つの同一のトランザクション セットが存在します。これが可能なのは、Coinbase トランザクションにはトランザクション入力がなく、新しく生成されたコインがあるためです。したがって、2 つの異なる Coinbase トランザクションが同じ金額を同じアドレスに送信し、まったく同じ方法で構築され、同一になる可能性があります。これらのトランザクションは同一であり、TXID はトランザクション データのハッシュ ダイジェストであるため、TXID も一致します。 TXID が複製される唯一の他の方法はハッシュ衝突によるものですが、これは暗号的に安全なハッシュ関数では起こりそうになく、実現不可能であると考えられています。 SHA256 のようなハッシュ衝突は、ビットコインでも他のどこでも発生したことはありません。
重複トランザクションの両方のセットは、2010 年 11 月 14 日の 08:37 UTC から 2010 年 11 月 15 日の 00:38 UTC までの間の約 16 時間の範囲の同様の時間に発生しました。重複トランザクションの最初のセットは、2 番目のセットの間に挟まれます。 d5d2….8599 は最初に重複トランザクションとなったため、最初の重複トランザクションとして分類しますが、奇妙なことに、このトランザクションは別の重複トランザクション e3bf….b468 の後にブロックチェーン上に最初に現れました。
繰り返し取引の詳細
以下の画像では、mempool.space ブロック エクスプローラーからの 2 つのスクリーンショットが表示され、最初の重複トランザクションが 2 つの異なるブロックで繰り返されていることがわかります。


興味深いことに、関連する URL を Web ブラウザーに入力すると、mempool.space ブロック エクスプローラーは、d5d2….8599 の場合は前のブロックを、e3bf….b468 の場合は後のブロックをデフォルトで表示します。 Blockstream.info と Btcscan.org は mempool.space と同じ動作をします。一方、当社の基本的なテストによると、Blockchain.com と Blockchair.com は動作が異なり、ブラウザに URL を入力すると、重複トランザクションの最新バージョンが常に表示されます。
問題となっている 4 つのブロックのうち、追加のトランザクションが含まれていたのは 1 つ (ブロック 91,812) のみでした。このトランザクションは、1 BTC と 19 BTC の出力を 1 つの 20 BTC 出力に結合します。
これらの出力は使用できますか?
これにより、同じ TXID が 2 セット存在したため、後続のトランザクションで参照の問題が発生しました。各定期取引の価値は 50 BTC です。したがって、これらの繰り返しトランザクションには、合計 4 x 50 BTC = 200 BTC が関係します。または、理解の仕方によっては、2 x 50 BTC = 100 BTC になります。実際には存在しない BTC も 100 個ほどあります。
今日現在、200 BTC はすべて未使用のままです。私たちが知る限りでは(間違っている可能性もありますが)、これらの出力に関連付けられた秘密鍵を持っている人は、それらのビットコインを使うことができます。ただし、一度使用されると、UTXO はデータベースから削除され、重複した 50 BTC は使用できなくなり失われるため、回復できるのは 100 BTC のみとなります。これらのコインが使用される場合、どのブロックから来るのか(以前のブロックか最近のブロックか)は未定義か、または判断不可能である可能性があります。
この人物は、重複したトランザクションを作成する前にすべてのビットコインを使用した可能性があり、その結果、重複した出力が作成され、未使用の出力のデータベースに新しいエントリが作成されます。これは、重複したトランザクションだけでなく、重複した使用済み出力を持つ可能性のある重複したトランザクションも意味します。これが起こると、これらの出力が使用されるときに、より多くの重複トランザクションが作成され、一種の重複チェーンが形成される可能性が高くなります。イベントの順序に注意し、複製を作成する前に必ず使用する必要があります。そうしないと、ビットコインが永久に失われる可能性があります。これらの新しい重複トランザクションは、Coinbase トランザクションではなく、「通常の」トランザクションになります。幸いなことに、これは起こりませんでした。
重複取引の問題
重複した取引は明らかに悪いことです。これらはウォレットやブロックエクスプローラーに混乱を生じさせ、ビットコインの起源も不明瞭にします。また、多くの攻撃や脆弱性も生じます。たとえば、2 つの重複した取引により、誰かに 2 回支払う可能性があります。その後、取引当事者が資金にアクセスしようと決めたときに、回収できる資金は半分しかないことに気づくかもしれません。これは、たとえば、取引プラットフォームを破産させようとする攻撃の場合に考えられますが、攻撃者は入金後すぐに資金を引き出すことができるため、何も失うことはありません。
重複したTXIDを持つトランザクションを許可しない
重複トランザクションの問題を軽減するために、2012 年 2 月に、ビットコイン開発者の Pieter Wuille は、以前の TXID が使用されていない限り、トランザクションで重複する TXID を使用することを禁止する BIP30 ソフトフォーク ソリューションを提案しました。このソフトフォークは、2012 年 3 月 15 日以降のすべてのブロックに適用されます。
2012 年 9 月、ビットコイン開発者の Greg Maxwell 氏はこのルールを修正し、BIP30 チェックが 2012 年 3 月 15 日以降のブロックだけでなく、すべてのブロックに適用されるようにしました。例外は、この記事で前述した 2 つの重複トランザクションです。これにより、いくつかの DOS バグが修正されます。技術的には、これは別のソフトフォークですが、ルールの変更は 6 か月以上経過したブロックにのみ適用されるため、通常のプロトコル ルールの変更に伴うリスクは一切ありません。
この BIP30 チェックは計算コストがかかります。ノードは、新しいブロック内のすべてのトランザクション出力をチェックし、これらの出力エンドポイントが UTXO にすでに存在するかどうかを確認する必要があります。おそらくこれが、Wuille が未使用の出力のみをチェックする理由です。すべての出力をチェックすると計算コストが高くなり、プルーニングできなくなります。
BIP34
2012 年 7 月、ビットコイン開発者の Gavin Andresen 氏は BIP34 ソフトフォーク ソリューションを提案し、2013 年 3 月に有効化されました。このプロトコルの変更により、Coinbase トランザクションにブロックの高さを含めることが義務付けられ、ブロックのバージョン管理も可能になりました。ブロックの高さは、Coinbase トランザクション スクリプト Sig の最初の項目として追加されます。コインベース スクリプト Sig の最初のバイトは、ブロックの高さの数値で使用されるバイト数であり、次のバイトはブロックの高さの数値そのものです。最初の約 160 年間 (223 / (1 日あたり 144 ブロック * 1 年あたり 365 日))、最初のバイトは 0x03 になります。そのため、今日のコインベースの ScriptSig (HEX) は常に 03 で始まります。このソフトフォークにより、重複トランザクションの問題は完全に解決されたようで、すべてのトランザクションは一意になるはずです。
BIP34はすでに採用されていたため、2015年11月にビットコイン開発者のアレックス・モルコスはビットコイン・コア・ソフトウェア・リポジトリにプルリクエストを追加しました。この変更により、ノードはBIP30チェックを停止することになります。結局のところ、BIP34 でこの問題が修正されたので、この高価なチェックは不要になりました。当時は知られていませんでしたが、これは技術的には非常にまれな将来のブロックのためのハードフォークでした。現時点では、2015 年 11 月以前のノード ソフトウェアを実行している人はほとんどいないため、潜在的なハード フォークは問題にならないようです。forkmonitor.info では、2015 年 10 月にリリースされた Bitcoin Core 0.10.3 を実行しています。したがって、これはハードフォーク前のルールであり、クライアントは依然としてコストのかかる BIP30 チェックを実行しています。
ブロック、983,702 の質問
BIP34 が有効化される前にブロック内にコインベース トランザクションが存在し、使用された scriptSigs の最初のバイトが将来の有効なブロックの高さと一致していたことが判明しました。したがって、BIP34 はほぼすべてのケースでこの問題を解決しますが、完全に 100% 解決するわけではありません。 2018 年、ビットコイン開発者のジョン・ニューベリー氏は、以下の表に示すように、これらの潜在的な重複の完全なリストを作成しました。


* 注: これらのブロックは 2012 年と 2017 年に Coinbase トランザクションを生成しており、重複ではありません。 209,921 ブロック (最初の半減期からわずか 79 ブロック) は、その間に BIP30 が実装されたため、重複することはできません。
出典: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd
重複する可能性のある Coinbase 取引の件数(年別)

出典: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd
したがって、重複トランザクションが出現する可能性がある次のブロックは、2046 年 1 月頃に生成されるブロック 1,983,702 です。2012 年 1 月のブロック 164,384 の Coinbase トランザクションでは、170 BTC が 7 つの異なる出力アドレスに送信されました。したがって、2046 年のマイナーがこの攻撃を実行したい場合、このブロックを見つけるほど幸運である必要があるだけでなく、手数料として 170 BTC 未満をバーンする必要があり、0.09765625 BTC のブロック補助金の機会費用を含めた合計コストは 170 BTC をわずかに超えることになります。
現在のビットコインの価格が88,500ドルなので、その費用は1,500万ドル以上になる。 2012 年のコイン ライブラリ取引の 7 つのアドレスの所有者は依然として不明であり、キーは紛失している可能性があります。現在、この Coinbase トランザクションの 7 つの出力アドレスすべてが使用されており、そのうち 3 つは同じトランザクションで使用されています。これらの資金はPirate40ポンジースキームに関連している可能性があると考えていますが、これは当社の単なる推測にすぎません。その結果、攻撃者にとって、攻撃はコストがかかるだけでなく、実質的に無意味なものとなるようです。 31年前の2015年11月のノードをハードフォークでネットワークから削除するには、多大な費用がかかります。
次にコピーされる可能性のある脆弱なブロックは、2012 年 3 月の 169985 です。この Coinbase のコストはわずか 50 BTC 強で、170 BTC よりはるかに安いです。もちろん、50 BTC は当時の補助金であり、この Coinbase 取引が 2078 年に簡単に再現できるようになると、補助金ははるかに低くなります。したがって、これを利用するには、マイナーは約 50 BTC の手数料を支払う必要がありますが、これは 2012 年の古い出力に送る必要があるため、取り戻すことはできません。2078 年のビットコインの価格がどうなるかは誰にもわかりませんが、このような攻撃にかかるコストもおそらく法外に高くなるでしょう。したがって、この問題はビットコインにとって大きなリスクではないかもしれませんが、それでも懸念事項です。
2017 年の SegWit アップグレード以降、Coinbase トランザクションにはブロック内のすべてのトランザクションへのコミットメントも含まれるようになりました。これらの BIP34 以前のブロックには、証人コミットメントは含まれていませんでした。したがって、重複したコインベーストランザクションを生成するには、マイナーはブロックから SegWit 出力償還トランザクションを除外する必要があり、ブロックには手数料を支払う他の多くのトランザクションが含まれていない可能性があるため、攻撃の機会コストがさらに増加します。
結論は
コピー取引の難しさやコスト、そしてそれを悪用する機会の稀さを考えると、このコピー取引の脆弱性はビットコインにとって大きなセキュリティ問題にはならないようです。それでも、関係する時間スケールと繰り返される取引の目新しさを考えると、考えてみると興味深いです。それでも、開発者たちは長年この問題に多くの時間を費やしており、一部の開発者の頭の中では 2046 年が問題の解決期限となっている可能性があります。このバグを修正する方法は多数あり、ソフトフォークが必要になる可能性があります。考えられる解決策の 1 つは、SegWit コミットメントを強制することです。
全てのコメント