今週のニュースレターでは、Bitcoin Coreの旧バージョンに影響する脆弱性の修正の発表と、 ハイブリッドチャネルジャミング緩和に関する最新情報、より効率的でプライベートなClient-side Validationに関する論文の要約、 BIPプロセスの更新の提案を掲載しています。また、Bitcoin Stack Exchangeで人気の質問とその回答や、 新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● Bitcoin Core 24.0.1より前のバージョンに影響する脆弱性の開示: Antoine Poinsotは、2023年12月以降のサポートが終了したバージョンのBitcoin Coreに影響する脆弱性の発表のリンクを Bitcoin-Devメーリングリストに投稿しました。 これは、以前の脆弱性の開示に続くものです（ニュースレター#310および#314参照）。

    新しい開示では、Bitcoin Coreのフルノードをクラッシュさせる以前から知られている方法について説明しています。 メモリに保存される長いブロックヘッダーチェーンを送信するという方法です。 各ブロックヘッダーは80 byteで、何も保護がなければ、プロトコルの最小難易度で作成できるため、 最新のASICマイニングを持つ攻撃者であれば、秒間数百万のブロックを生成できます。 ただ、Bitcoin Coreは、初期バージョンで追加されたチェックポイントの副作用により、長年にわたって保護されています。 これにより、攻撃者はヘッダーチェーンの最初のブロックを最小難易度で作成できなくなり、 有効なブロックを作成した場合に報酬を得られる重要なProof of Workを実行せざるを得なくなります。

    しかし、最後のチェックポイントが追加されたのは10年以上前で、 Bitcoin Core開発者は新たなチェックポイントを追加することに消極的でした。 チェックポイントの追加により、トランザクションのファイナリティは 最終的に開発者がチェックポイントを作成することに依存しているという誤った印象を与えるからです。 マイニング機器が改良され、ネットワークのハッシュレートが増加するにつれて、 偽のヘッダーチェーンを作成するコストは低下しました。コストが下がるにつれて、 研究者のDavid JaensonとBraydon Fullerは、それぞれ個別に Bitcoin Core開発者に攻撃を責任を持って開示しました。 開発者は、この問題が既知であるこを回答し、2019年にFullerにこの問題に関する彼の論文を 公開するよう促しました。

    2022年、攻撃のコストがさらに低下したため、開発者のグループがチェックポイントを使用しないソリューションに取り組み始めました。 Bitcoin Core PR #25717（ニュースレター #216）は、その作業の結果です。 その後、Niklas Göggeが#25717のロジックにバグを発見し、 それを修正するためにPR #26355を作成しました。 両方のPRがマージされ、修正を加えたBitcoin Core 24.0.1がリリースされました。

  • ● ハイブリッドジャミング緩和のテストと変更: Carla Kirk-Cohenは、元々Clara ShikhelmanとSergei Tikhomirovによって提案された チャネルジャミング攻撃に対する緩和策の実装を破ろうするさまざまな試みに関する詳細を Delving Bitcoinに投稿しました。 ハイブリッドジャミング緩和には、HTLCエンドースメントと 支払いが成功しても失敗しても無条件に支払われる少額の 前払い手数料 の組み合わせが含まれます。

    何名かの開発者が、1時間のチャネルジャミングの挑戦に招待され、 Kirk-CohenとShikhelmanが有望と思われる攻撃について詳しく説明しました。 ほとんどの攻撃は失敗しました。攻撃者がこの攻撃に費やす費用が他の既知の攻撃よりも多かったか、 ターゲットノードが攻撃中に獲得した収入が シミュレートされたネットワーク上の通常の転送トラフィックで得られる収入よりも多かったかのいずれかです。

    1つの攻撃は成功しました。それは、「ネットワーク内でより短く/より安価なパスを作成し、 そのチャネルを介して転送される支払いを妨害し、経路内でそのノードより前にあるすべてのノードの評価を低下させることで、 ターゲットノードのピアの評価を低下させることを目的とする」シンク攻撃です。 この攻撃に対処するために、Kirk-CohenとShikhelmanは、HTLCエンドースメントの考慮方法に 双方向レピュテーションを導入しました。 ボブがアリスからキャロルに転送される支払いを受け取ると（例：A -> B -> C）、 ボブはアリスがすぐに決済されるHTLCを転送する傾向があるかどうかと（これまでのHTLCエンドースメントと同様に）、 キャロルがすぐに決済されるHTLCを受け入れる傾向があるかどうか（これが新しい機能）の両方を考慮します。 ボブがアリスからエンドースされたHTLCを受け取ると：

    • ボブがアリスとキャロルの両者とも信頼できると考える場合、アリスからキャロルへのHTLCを転送しエンドースします。

    • ボブが信頼できるのはアリスだけと考える場合、アリスからエンドースされたHTLCを転送しません。 ボブはすぐにそれを拒否し、失敗が元の支払人に伝わるようにします。元の支払人は別の経路を使用してすぐに再送信できます。

    • ボブが信頼できるのはキャロルだけと考える場合、ボブはキャパシティに余裕がある場合はアリスからのエンドースされたHTLCを受け入れますが、 それをキャロルに転送する際にはエンドースしません。

    提案の変更を受けて、Kirk-CohenとShikhelmanは、期待通りに機能することを確認するために追加の実験を計画しています。 彼らはまた、2018年5月のJim Posenのメーリングリストへの投稿のリンクも追加しています。 この投稿では、ジャミング攻撃（当時は ループ攻撃 と呼ばれていました）を防ぐための双方向のレピュテーションシステムについて説明しており、 この問題を解決するための以前の並行思考の例です。

  • ● シールドClient-side Validation（CSV）: Jonas Nick、Liam Eagen、Robin Linusは、 新しいClient-side Validationプロトコルに関する論文を Bitcoin-Devメーリングリストに投稿しました。 Client-side Validationにより、トークンの転送は、トークンやその転送に関する情報を公開することなく、 BitcoinのProof of Workによって保護されます。Client-side Validationは、 RGBやTaproot Assetsなどのプロトコルの 重要なコンポーネントです。

    既存のプロトコルの1つの欠点は、トークンを受け取る際にクライアントが検証する必要があるデータ量が、 最悪の場合、そのトークンと関連するトークンのすべての転送履歴と同程度になることです。 言い換えると、ビットコインのように頻繁に交換されるトークンのセットでは、 クライアントはBitcoinのブロックチェーン全体とほぼ同じ大きさの履歴を検証する必要があります。 そのデータを転送するための帯域幅コストとそれを検証するためのCPUコストに加えて、 完全な履歴を転送することは、トークンの以前の受信者のプライバシーを弱めることになります。 それに比べ、シールドCSVは、ゼロ知識証明を使用することで、 これまでの転送について開示することなく一定量のリソースでの検証を可能にします。

    既存プロトコルのもう1つの欠点は、トークンを転送するたびにBitcoinトランザクションにデータを含める必要があることです。 シールドCSVでは、複数の転送を同じ64 byteの更新にまとめることができます。 これにより、新しいBitcoinのブロックが発見されるたびに、 64 byteのデータプッシュを追加した単一のBitcoinトランザクションのみを確認することで、 トークンの何千もの転送を確認できるようになります。

    この論文では詳細に説明されています。特に興味深いのは、 BitVMを使用してコンセンサスの変更なしにビットコインをメインブロックチェーンから シールドCSVに（およびその逆に）トラストレスにブリッジするというアイディアと、 アカウントの使用（セクション2）、ブロックチェーンの再編成がアカウントと転送に与える影響に関する議論（同じくセクション2）、 未承認トランザクションへの依存に関する関連議論（セクション5.2）および、 可能な拡張機能のリスト（Appendix A）です。

  • ● BIPプロセスの更新のドラフト: Mark “Murch” Erhardtは、 BIPリポジトリの更新プロセスを記述したBIPドラフトのプルリクエストが公開されたことの発表を Bitcoin-Devメーリングリストに投稿しました。 興味ある方は、ドラフトを確認し、コメントを残してください。 コミュニティがドラフトの最終バージョンが受け入れられると判断した場合、 それがBIPエディターが使用するプロセスになります。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

  • ● BDK 1.0.0-beta.4は、ウォレットやその他のBitcoin対応アプリケーションを構築するためのこのライブラリのリリース候補です。 元のbdk Rustクレートの名前がbdk_wallet変更され、 低レイヤーのモジュールは、 bdk_chain、bdk_electrum、bdk_esplora、bdk_bitcoind_rpcなどの独自のクレートに抽出されました。 bdk_walletクレートは、「安定した 1.0.0 API を提供する最初のバージョンです」。

  • ● Bitcoin Core 28.0rc2は、主要なフルノード実装の次期メジャーバージョンのリリース候補です。 テストガイドが利用可能です。

注目すべきコードとドキュメントの変更

最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • ● Eclair #2909は、createinvoice RPCコマンドにprivateChannelIdsパラメーターを追加し、 BOLT11インボイスにプライベートチャネルの経路探索ヒントを追加します。 これにより、プライベートチャネルのみを持つノードが支払いを受け取れないバグが修正されます。 チャネルのOutPointの漏洩を避けるため、scid_aliasを使用する必要があります。

  • ● LND #9095およびLND #9072は、インボイスのHTLC修飾子、 補助チャネルのファンディングとクロージングに変更を加え、 カスタムチャネル構想の一環としてカスタムデータをRPC/CLIに統合し、 LNDのTaproot Assetsのサポートを強化します。 このPRでは、カスタムアセット固有のデータをRPCコマンドに含めることができるようにし、 コマンドラインインターフェースによる補助チャネルの管理をサポートします。

  • ● LND #8044は、ノードがTaprootチャネルを アナウンスおよび検証できるようにする新しい v1.75ゴシッププロトコル（ニュースレター #261参照）用に 新しいメッセージタイプannouncement_signatures_2、channel_announcement_2、 channel_update_2を追加します。さらに、Taprootチャネルのゴシップの効率とセキュリティを向上させるために、 channel_readyやgossip_timestamp_rangeなどの既存のメッセージにいくつかの変更が加えられています。