今週のニュースレターでは、ライトニングネットワークのチャネルジャミングを緩和するために提案されたコントラクトプロトコルと、 テスト用のBitcoin Coreの静的バイナリの提供、Bitcoin Coreのピアごとのトランザクションレート制限をグローバルな方式に置き換える変更について掲載しています。 また、新しいリリースとリリース候補の発表や、人気のBitcoin基盤ソフトウェアへの注目すべき更新など 恒例のセクションも含まれています。

ニュース

  • ● ジャミング解決のための条件付きメッセージ転送コントラクト: Antoine Riardは、ライトニングネットワークにおけるチャネルジャミングを緩和する新しいアプローチを Delving Bitcoinに投稿しました。ジャミングとは、攻撃者がHTLCやPTLCを送信した後、 それらを未解決のまま保持し、自身は一切コストを負担することなく経路上のチャネル流動性を拘束する一種のサービス拒否（DoS）攻撃です。 Riardの提案は、支払いが保留された期間に比例した保留手数料「withhold fee」を課すことで保持を高コスト化し、 現在は無料で行える攻撃をコストのかかるものに変えます。

    この仕組みは、条件付きメッセージ転送契約（conditional message transfer contract、CMTC）と呼ばれるBitcoin Scriptの構成です。 これを利用することでチャネルの両参加者は、特定のメッセージ（支払いのプリイメージなど）が、 Riardが「共通の時計」とみなす特定のブロック高までに交換されたかどうかを、後から証明できるようになります。 両者は期間（タイムウィンドウ）について合意し、その期間内の各時点にアダプターポイントを割り当てることで、 メッセージが配信された時点に応じて保留手数料を精算できるようになります。このコントラクトには、以下の3つの精算経路が用意されています:

    • ● メッセージ転送の成功: プリイメージがボブからアリスへ配信され、 暗号学的に確認されると、両者は配信時間に基づいて保留手数料を両者で分配します。

    • ● ライブネスチャレンジ: アリスがオフラインで署名できない場合、 ボブはコントラクトを終了し、所定のペナルティ手数料を差し引いたロック済み資金を回収できます。

    • ● メッセージ転送の失敗: ボブがオフラインであるか、 その他の理由でメッセージを転送できなかった場合、アリスはコントラクトを終了し、保留手数料を回収できます。

    Riardは、提案された解決策には暗号学的な正しさとインセンティブの両面でさらなる分析が必要であり、 このアプローチ、あるいはその拡張がBitcoinの他の種類の問題を解決できるかどうかは現時点では未定であると述べています。

  • ● テスト用のBitcoin Coreの静的バイナリの公開: Michael Ford（fanquake）は、 プロジェクトの既存のGuixインフラストラクチャを用いて生成した、 Bitcoin Coreのリリースバイナリの静的リンク版テストビルドの発表を Bitcoin-Devメーリングリストに投稿しました。テストバイナリは、 x86_64およびaarch64 Linux向けのbitcoindとその他のコマンドラインユーティリティが提供されており、 今後さらに多くのプラットフォームへの対応が予定されています。なお、bitcoin-qt GUIバイナリに変更はありません。

    Bitcoin Coreの現在のLinux向けのリリースバイナリは動的リンク方式を採用しています。これは、 必要なコードの大部分は含んでいるものの、ユーザーのOSが提供するCライブラリ（glibc）やいくつかの関連ライブラリに依存しています。 これらのライブラリはプログラムの起動のたびに毎回読み込まれますが、この依存関係にはいくつかのリスクが伴います。 具体的には、互換性のあるglibc（現在はバージョン2.31以降）を提供するシステムでしか動作せず、 その挙動はホストのライブラリによって変わる可能性があります。また、ノードが実際に実行するコードの一部は、 ユーザーの検証可能な「再現可能ビルド」の対象外となってしまうことなどが挙げられます。一方、 静的バイナリは必要なコードをすべて含むため、検証済みの同一の実行ファイルが、古いリリースや、 Alpine Linuxのように異なるCライブラリの上に構築されたディストリビューション、 システムライブラリを一切同梱しない最小限のコンテナイメージを含む、ほぼすべてのLinuxシステムで同じように動作します。 新しいバイナリは引き続き位置独立実行形式（position-independent executable）であり、 現行リリースのASLR（アドレス空間配置のランダム化）による脆弱性緩和機構を維持しつつ、サイズの増加は約1 MBにとどまります。

    このメーリングリストへの投稿は、Fordが2022年に開始したBitcoin Core #25573における長年の取り組みの続きです。 この作業には、GCCコンパイラおよびglibc自体への変更が必要であり、その中には、 glibcの静的リンクにおける歴史的な最大の懸念事項であった名前解決コードの修正も含まれます。 Guixビルドプロセスへの準備的な変更のいくつか（Bitcoin Core #35537を参照）は既にマージされていますが、 本体のPRは依然オープンでレビュー中です。LinuxでBitcoin Coreを実行している読者は、 テストバイナリを試し、問題があれば（あるいは成功した場合も）メーリングリストまたはPRに報告することが推奨されています。

  • ● ピアごとのトランザクションレート制限からグローバルレート制限への変更: Anthony Townsは、ピアごとのトランザクションレート制限をグローバルな制限方式に置き換えるBitcoin Core #34628がマージされたことを Delving Bitcoinに投稿しました。

    ノードは各ピアに対して、そのピアへ送信予定のトランザクション通知のキュー（m_tx_inventory_to_sendと呼ばれます）を保持し、 それらの通知を「祖先トランザクションの手数料率（ancestor feerate）」でソートして、最良のものから先に送信します。 帯域幅を節約し、リレートポロジーの探査を困難にするため、ノードは各ピアに対して1秒あたり約7件を超えるトランザクションを通知しません。 通常時にはこのレートでキューを排出するのに十分ですが、トランザクションの急激なバーストが発生すると、 この制限による排出速度よりも速くキューが埋まることがあります。ノードは通知のたびに増大するキューを再ソートするため、 これは過度なCPU消費を引き起こす可能性があり、ニュースレター #324で以前に説明されたサービス拒否（DoS）攻撃の要因となっていました。

    TownsのPRは、ピアごとのレート制限を、件数（トランザクション数）とサイズ（シリアライズされたウィットネスサイズ）によって 全通知を計測する2つのトークンバケット方式を用いたグローバルレート制限に置き換えます。十分な容量がある場合、 受信したトランザクションは即座にリレーされ、そうでない場合は手数料率とクラスターmempoolのルールに従ってソートされた 単一のグローバルバックログに追加されます。そのバックログから選択されたトランザクションは、 プライバシーのためのバッチ処理に使われる小さなピアごとのキューに配置されます。 ピアごとに別々のキューを持つ代わりに共有された1つのバックログをソートすることで、 元の設計においてDoS攻撃の要因となっていた「ピアごとの繰り返しソート」を回避します。

リリースとリリース候補

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

  • ● BTCPay Server 2.4.2は、2.4.2より前のすべてのリリースに影響する重大な脆弱性を修正するセキュリティリリースです。 認証されていないリモートの攻撃者が、LNDノードの.macaroon認証情報ファイルを取得し、それを用いてノードを制御下に置き、 資金を移動させることが可能でした。プロジェクトは、この脆弱性が実際に悪用され、資金が盗まれたと報告しています。 LNDを使用しているBTCPay Serverの運用者は、直ちに2.4.2およびLND 0.21.1に更新し、 不正な動作がないかノードを監査するとともに、攻撃者が既にmacaroon認証情報を取得している可能性があるため、 それらをローテーションすべきです。BTCPay Serverのオンチェーンウォレットや他のLightning実装を使用しているデプロイ環境は、 この特定のリスクにはさらされていません。

  • ● LND v0.21.2-betaは、この人気のLNノード実装のメンテナンスリリースです。 2件のデータベースマイグレーション失敗を修正し、チャネルグラフ同期中のメモリ使用量に上限を設け、 オニオンメッセージ、RBFによる協調閉鎖、インボイスの更新、ブラインドペイメントの転送、 HTLCの解決に影響するバグを修正しています。

  • ● LND v0.20.3-betaは、LNDの0.20リリースブランチのメンテナンスリリースです。 チャネルグラフ同期中のメモリ使用量の上限や、協調閉鎖、インボイスの更新、ブラインドペイメントの転送、 HTLCの解決に関する修正など、0.21.2-betaにも含まれるいくつかの修正をバックポートしています。

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

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

  • ● Bitcoin Core #35493は、必要なすべての秘密鍵を備えたMuSig2 ディスクリプター（ニュースレター #366参照）をインポートする際に、 秘密鍵が不足していると示す誤った警告が表示される問題を修正します。これまで、 importdescriptors RPCは、ディスクリプターを展開した際に生成されるすべての公開鍵について（ 単独の秘密鍵を持たないMuSigの集約鍵も含めて）、対応する秘密鍵の有無を確認していました。 このため、参加者全員の秘密鍵を含むディスクリプターであっても不完全であると報告される可能性がありました。 完全性チェックはMuSig参加者の鍵を考慮するようになったため、完全なディスクリプターは警告なしにインポートされる一方、 参加者の秘密鍵が不足しているものは引き続き警告が表示されるようになります。

  • ● Core Lightning #9150は、チャネル経由の成功した支払いを記録し、 askrene RPCコマンド（ニュースレター #316参照）が以降のルーティング試行に向けて流動性の推定値を調整できるようにする、 新しい種類の流動性情報impressionsを導入します。加えて、getroutes RPCコマンドが更新され、 送信元の資金が不足している場合や宛先の受信容量が不足している場合など、 ルーティングが失敗した際により具体的なエラーメッセージを提供するようになりました。また、このPRは、 別の通貨建てのBOLT12オファーから生成されるインボイスについて、 為替レートの変動を考慮してデフォルトで有効期限を10分に制限します。

  • ● BIPs #2248は、Bitcoin-Devメーリングリストでの議論を受けて、 BIPエディターのリストからLuke Dashjrを削除するようBIP3を更新します。 エディター陣についての以前の記事はニュースレター #299を参照してください。

  • ● BIPs #2225および#2245は、アクティベーションの試みが失敗したBIP110 （ニュースレター #412参照）を更新します。 #2245はそのステータスを「Closed」に変更します。 #2225は、BIP433のポリシー規則である、pay-to-anchor（P2A）の使用に際して witness stackを空にすることを求める規則を、コンセンサス要件に格上げします。

  • ● Eclair #3346は、クラッシュを修正し、オンチェーンおよびチャネル処理に関する複数の改善を行います。 復号した支払い失敗メッセージをルーティング情報として使用する前に、 それが支払い経路上の有効な中間位置に対応しているかを検証するようになり、 受取人から送られる不正な形式または悪意を持って細工された失敗メッセージが、 範囲外アクセスを引き起こして支払いライフサイクルのアクターをクラッシュさせることを防ぎます。 また、Bitcoin Coreから分類できないエラーメッセージを受け取った際に、 時間的制約のあるトランザクションを放棄してしまう代わりに、 オンチェーントランザクションのブロードキャストを再試行するようになりました。 ピアのゼロ手数料コミットメントをCPFPで手数料引き上げする際に、 親トランザクションのウェイトのみでなく、親子パッケージ全体のウェイトを正しく計算するようになりました。 最後に、Eclairはchannel_readyを送信する際に、最新のRBF試行が承認されたものであると仮定するのではなく、 実際に承認されたファンディングRBF試行に紐づくMuSig2 nonceを使用するようになりました。

  • ● Eclair #3341は、BOLT7で現在未定義のmessage_flagsやchannel_flagsを使用する 将来のchannel_updateゴシップメッセージをリレーするための準備を行います。 これまでは、未知のフラグビットが1に設定された更新をEclairが受信すると、その値を破棄し、 更新を転送する際にそのビットを0としてエンコードしていました。これは署名対象のメッセージを改変することになり、 その署名を無効にしていました。今後、Eclairはchannel_updateメッセージのデコードおよび再エンコードの際に未知のフラグ値を保持するため、 Eclairノードはまだ理解できないフラグを含む更新をリレーできるようになります。

  • ● LND #11019は、レガシーな協調閉鎖のステートマシンにおけるデータ競合を修正します。 これは、（チャネルのHTLCおよびコミットメント状態を追跡する）link goroutineと （リモートピアからのcloseメッセージを処理する）peer goroutineが並行して進行する際に発生する可能性がありました。 今後は、linkがcloser自体を進行させる代わりに、チャネルがフラッシュされた（保留中のHTLCが排出された）ことをピアのチャネルマネージャーに報告するようになり、 すべてのcloseステートマシンの遷移が単一のgoroutine上で実行されることが保証されます。またこのPRは、 RBFによる協調閉鎖の経路（ニュースレター #347参照）において、 事前シャットダウンスクリプトがネゴシエートされていない場合でも（ニュースレター #76参照）、 ピアの配信スクリプトが存在し、受け入れ可能なアウトプットタイプを使用していることを確認するようにします。

  • ● LND #11023は、update_feeの処理をBOLT2の置換可能状態モデルに合わせるとともに、 コミットされていない冗長な手数料更新によって更新ログが肥大化するのを防ぎます。 前回の手数料更新がいずれの当事者のコミットメントトランザクションにも取り込まれる前に新しい手数料更新が到着した場合、 LNDは以前の手数料の値をその場で置き換えるようになりました。またこのPRは、 チャネルのメールボックスのキューイングメッセージ数を1,000件かつシリアライズデータ量を4 MiBに制限します。 メッセージを受け入れられない場合、LNDはメッセージを破棄して後続のメッセージを順不同で処理するのではなく、 ピアとの接続を切断します。これにより、再接続時に順序付けられたチャネル状態を復元できます。

  • ● Libsecp256k1 #1904は、独自のSHA256圧縮関数を提供するアプリケーション向けの起動時の自己テストを強化します（ニュースレター #396参照）。 従来の自己テストは63 byteの単一メッセージをハッシュするものであり、一般的な不適切な実装は検出できても、 複数ブロックの処理やアライメントされていない入力、初期状態以外のSHA256状態を扱う際に失敗する実装は検出できませんでした。 新しいテストは、異なるメッセージ長と入力アライメントを使用します。提供された圧縮関数の結果が期待されるSHA256の結果と異なる場合はそれを拒否するため、 欠陥のある実装を、後で誤った結果を生成する前に初期化時に検出できます。

  • ● HWI #839は、BIP174およびBIP370の完全なテストベクタースイートを追加した際に明らかになった、 複数のPSBTのパースとトランザクション再構築の問題を修正します。 PSBTv2からトランザクションを再構築する際、HWIはロックタイムを0のままにするのではなく計算された値を適用するようになり、 インプットにPSBT_IN_SEQUENCEが含まれていない場合は指定された最終sequence値（0xffffffff）を使用するようになりました。 PSBTv0については、HWIはv2専用のインプット・アウトプットフィールドを拒否し、 グローバルな未署名トランザクションを非ウィットネスシリアライゼーションで厳密にパースする一方、 空の未署名トランザクションを存在するものとして正しく認識します。またこのPRは、 必要とされる高さベースおよび時刻ベースのロックタイムが、指定された範囲内に収まることを検証し、 BIP370のロックタイム決定に関するテストも追加しています。

もっと知りたいですか？

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