今週のニュースレターでは、LDKの旧バージョンに影響する脆弱性と、 2023年に最初に公開された脆弱性の新たに開示された側面、 コンパクトブロックの再構築の統計に関する新たな議論を掲載しています。 また、Bitcoin Stack Exchangeで人気の質問のまとめや、 新しいリリースとリリース候補の発表、人気のBitcoinインフラストラクチャソフトウェアの最近の変更など 恒例のセクションも含まれています。

ニュース

  • LDKの請求処理の脆弱性: Matt Morehouseは、 彼が責任を持って開示し、 LDKバージョン0.1で修正されたLDKに影響する脆弱性をDelving Bitcoinに投稿しました。 チャネルが複数の保留中のHTLCがある状態で一方的に閉じられると、 LDKはトランザクション手数料を節約するため、同じトランザクションで可能な限り多くのHTLCを解決しようとします。 ただし、チャネルの相手がバッチ化されたHTLCのいずれかを最初に承認できた場合、 それはバッチトランザクションと競合し、バッチトランザクションは無効になります。その場合、 LDKは競合を取り除いた更新したバッチトランザクションを正しく作成します。 残念ながら、取引相手のトランザクションが複数の別々のバッチと競合する場合、 LDKは誤って最初のバッチのみを更新し、残りのバッチは承認されません。

    ノードは期限までにHTLCを解決する必要があります。さもないと、相手が資金を盗むことができます。 タイムロックにより、相手がそれぞれの期限前にHTLCを使用することが防止されます。 LDKのほとんどの旧バージョンでは、これらのHTLCを別のバッチにまとめ、 相手が競合するトランザクションを承認する前に承認されるようにして、資金が盗まれないようにしていました。 資金は盗まれないものの相手がすぐに解決できるHTLCの場合、相手が資金をスタックさせるリスクがありました。 Morehouseは、この問題は「LDKバージョン0.1にアップグレードし、 ロックアップする原因となったコミットメントおよびHTLCの一連のトランザクションをリプレイする」ことで修正できると書いています。

    しかし、リリース候補のLDK 0.1-betaではロジックが変更され(ニュースレター #335参照)、 すべての種類のHTLCをまとめてバッチ処理するようになったため、攻撃者はタイムロックされたHTLCとの競合を作成できるようになりました。 タイムロックが期限切れになった後も、そのHTLCの解決がスタックしたままであれば、盗難が可能でした。 LDK 0.1のリリースバージョンにアップグレードすると、この形式の脆弱性も修正されます。

    Morehouseの投稿では、さらに詳細が提供され、同じ根本原因から生じる将来の脆弱性を防ぐための 可能な方法についても説明されています。

  • マイナーの悪用による置換サイクル攻撃: Antoine Riardは、2023年に彼が最初に公開した置換サイクル攻撃( ニュースレター #274参照)で可能な追加の脆弱性の開示をBitcoin-Dev メーリングリストに投稿しました。要約すると:

    1. ボブはマロリー(およびおそらく他の人)に支払うトランザクションをブロードキャストします。

    2. マロリーはボブのトランザクションをピン留めします。

    3. ボブはピン留めされたことに気づかず、(RBFまたはCPFPにより) 手数料を引き上げます。

    4. ボブの最初のトランザクションはピン留めされているので、ボブの手数料の引き上げは伝播されません。 ただし、マロリーは何らかの方法でそれを受け取ります。手順3と4が繰り返され、 ボブの手数料が大幅に引き上げられる可能性があります。

    5. マロリーはボブの最も高い手数料の引き上げをマイニングします。 このトランザクションは伝播されていないので、他の誰もマイニングしようとしません。 これにより、マロリーは他のマイナーよりも多くての手数料を獲得できます。

    6. マロリーは置換サイクルを使用して、トランザクションのピンを別のトランザクションに移動し、 追加の資金を割り当てることなく攻撃を繰り返すことができるため(おそらく異なる被害者に対して)、 攻撃を経済的に効率的に行うことができます。

    私たちはこの脆弱性を重大なリスクとは判断していません。脆弱性を悪用するには特殊な状況が必要で、 そのような状況は稀で、ネットワークの状態を誤って判断すると攻撃者が資金を失う可能性があります。 攻撃者がこの脆弱性を定期的に悪用した場合、ブロック監視ツールを構築、 使用するコミュニティメンバーによって、その行動は検知されると考えています。

  • コンパクトブロックの再構築に関する統計の更新: 以前のスレッド(ニュースレター #315参照)に続き、 開発者の0xB10Cは、彼のBitcoin Coreノードがコンパクトブロックの再構築を実行するために 追加のトランザクションを要求する必要があった頻度に関する統計の更新をDelving Bitcoinに投稿しました。 ノードがコンパクトブロックを受信すると、そのブロック内のトランザクションの内、 mempool(またはコンパクトブロックの再構築を支援するための特別な予備である extrapool )に含まれていないトランザクションを要求する必要があります。これは、 ブロックの伝播速度を著しく低下させ、マイナーの集中化を助長します。

    0xB10Cは、mempoolのサイズが大きくなるにつれて、要求の頻度が大幅に増加することを発見しました。 複数の開発者が、考えられる原因について議論し、最初のデータでは、 欠落しているトランザクションはオーファン(親が不明な子トランザクション)であることが示されました。 Bitcoin Coreは、親が短時間に到着する場合に備えて、そのトランザクションを一時的に保存しています。 最近Bitcoin Coreにマージされた(ニュースレター #338参照)、 オーファントランザクションの親の追跡と要求の改善によって、この状況を改善できる可能性があります。

    開発者は、他の可能な解決策についても議論しました。攻撃者はオーファントランザクションを無料で作成できるため、 ノードがオーファントランザクションを長期間保持することは合理的ではありませんが、 より多くのオーファントランザクションおよびその他の排除されたトランザクションをextrapoolに長期間保持することは可能かもしれません。 この記事の執筆時点では、議論の結論は出ていません。

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

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

リリースとリリース候補

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

  • LDK v0.1.1は、LN対応アプリケーションを構築するための人気のライブラリのセキュリティリリースです。 少なくともチャネル資金の1%を犠牲にすることを厭わない攻撃者は、 被害者を騙して他の無関係なチャネルを閉鎖させることができ、その結果、 被害者はトランザクション手数料に不必要にお金を使用することになる可能性があります。 この脆弱性を発見したMatt Morehouseは、この脆弱性についてDelving Bitcoinに投稿しています。Optechは、 来週のニュースレターで、より詳細な要約を提供する予定です。このリリースには、 APIの更新とバグ修正も含まれています。

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

最近のBitcoin CoreCore LightningEclairLDKLNDlibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBDKBitcoin Improvement Proposals(BIP)Lightning BOLTsBitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • Bitcoin Core #31376は、タイムワープバグを悪用したブロックテンプレートを マイナーが作成できないようにするチェックをtestnet4だけではなく、 すべてのネットワークに適用するよう拡張します。この変更は、 タイムワープバグを恒久的に修正する可能性のある将来のソフトフォークに備えたものです。

  • Bitcoin Core #31583は、getmininginfogetblockgetblockheadergetblockchaininfogetchainstates RPCコマンドを更新し、 nBitsフィールド(ブロックの難易度ターゲットのコンパクトな表現)とtargetフィールドを返すようにしました。 さらに、getmininginfoは、次のブロックの高さ、nBits、難易度およびターゲットを指定するnextオブジェクトを追加します。 ターゲットを導出および取得するために、このPRでは、DeriveTarget()およびGetTarget()ヘルパー関数を導入しています。 これらの変更は、Stratum V2の実装に役立ちます。

  • Bitcoin Core #31590は、GetPrivKey()メソッドをリファクタリングし、 ディスクリプター内のx-only公開鍵の秘密鍵を取得する際に、 両方のパリティビット値について公開鍵をチェックするようにしました。 これまでは、格納されている公開鍵に正しいパリティビットがない場合、秘密鍵を取得できず、 トランザクションに署名できませんでした。

  • Eclair #2982は、lock-utxos-during-funding設定を導入し、 Liquidity Adsの販売者が、 誠実なユーザーがUTXOを長期間使用できないようにする流動性の嫌がらせを行う攻撃の一種を緩和できるようになりました。 デフォルトの設定はtrueで、UTXOはファンディングプロセス中にロックされ、悪用される可能性があります。 falseに設定すると、UTXOのロックが無効になり、攻撃を完全に防止できますが、誠実なピアに悪影響を与える可能性があります。 このPRでは、ピアが応答しなくなった場合に着信チャネルを自動的に中止する、 設定可能なタイムアウトの仕組みも追加されています。

  • BDK #1614では、承認済みのトランザクションをダウンロードするために BIP158で定義されているコンパクトブロックフィルターを使用するためのサポートが追加されました。 これは、bdk_bitcoind_rpcクレートにBIP158モジュールを追加し、 scriptPubkeyのリストに関係するトランザクションを含むブロックを入手するために使用できる新しい FilterIter型を追加することで実現されます。

  • BOLTs #1110では、ピアストレージプロトコルの仕様がマージされ、 ノードは要求したピアのために64kBまでの暗号化されたブロブを保存し、このサービスに課金できるようになります。 これはすでにCore Lightning(ニュースレター#238参照)と Eclair(ニュースレター#335参照)に実装されています。

もっと知りたいですか?

このニュースレターで言及されたトピックについてもっと議論したい方は、 (ニュース レターが公開された翌日の)木曜日の15:30 UTCから Riverside.fmで毎週開催されているBitcoin Optech Recapにご参加ください。この議 論は録画もされ、ポッドキャストページからご覧いただけます。