en | ja | es | cs | hi | zh | de | fr | pt

Bitcoin Optech Newsletter #427

Oct 16, 2026

今週のニュースレターでは、Eclairの旧バージョンにおける2件のサービス拒否（DoS）脆弱性の開示と、ライトニングチャネル内で複雑な複数ラウンドのコントラクトを実行するために提案されたスキームを掲載しています。また、新しいリリースやリリース候補の発表、人気のあるBitcoin基盤ソフトウェアの注目すべき更新など恒例のセクションも含まれています。

ニュース

● Eclair v0.14.1で修正された2件のDoS脆弱性の開示: Erick Cestariは、 Eclair v0.14.0以前のチャネル開設処理における2件のサービス拒否（DoS）脆弱性の責任ある開示を Delving Bitcoinに投稿しました。どちらもEclair #3324で修正され、 7月にv0.14.1でリリースされており、旧バージョンを実行しているユーザーはアップグレードする必要があります。

1つめは、Matt Morehouseが彼のsmiteファザーを使って発見したもので、 temporary_channel_idの重複チェックにおける競合状態です。 Eclairはopen_channelメッセージを受け入れる前にそのIDがすでに使用されているかどうかをチェックしていましたが、新しいチャネルを記録するのは後のステップだったため、攻撃者が同一のopen_channelメッセージを立て続けに複数送信すると、重複チェックをすり抜けてしまうことがありました。その結果、Eclairは1つのIDに対して2つのチャネル状態を作成し、後から作成された状態が先のものを置き換えることで、アクセス不可能なチャネル状態が残るようになります。この状態はピアが切断されるまで約25 kBのメモリを占有し続けます。この攻撃を繰り返すことで、毎秒約1 MBのメモリがリークし、最終的にノードのメモリが枯渇するか、CPUリソースのすべてがガベージコレクションに費やされる事態が発生します。

2つめは、Cestariが発見したもので、ファンディングトランザクションが未承認である保留中のチャネル数に対する Eclairの制限をバイパスするものです。重複チェックはtemporary_channel_idしか見ていなかったため、攻撃者はチャネル開設を開始した後、そのチャネルの最終的なchannel_idを次のopen_channelの temporary_channel_idとして再利用することができました。制限機能は再利用されたIDを二重にカウントし、新しいチャネルが最終的なIDを受け取ると両方のエントリを削除していたため、保留中チャネルの数が際限なく増えてもカウントは2を超えることがありませんでした。その一方で、各保留中チャネルはピアのinit機能のコピーを保存しており、非常に高いビット位置に未知の奇数の機能ビットを1つ設定するだけで、そのコピーのサイズを約65 kBまで膨らませることが可能です。Cestariのテストでは、オンチェーンコストを一切かけずに、 1つの接続だけでノードの4 GBのメモリを約48分で枯渇させることが確認されました。保留中のチャネルはデータベースに書き込まれるため、メモリ上限を引き上げるか、手動で該当行を削除するまで、ノードは再起動のたびに再びクラッシュする状態でした。

質問への返答でMorehouseは、ACINQが数ヶ月前にノードにパッチを適用しているため、 PhoenixのようにEclairノードをLSPとして使用するモバイルウォレットは影響を受けないと述べました。
● ライトニングチャネル内のオフチェーンコントラクト: Adam Gibsonは、ライトニングチャネル内で複雑な複数ラウンドの二者間コントラクトを実行しつつ、紛争発生時には一定数のオンチェーントランザクションで解決を図る、LN-GAPと呼ばれるプロトコルの提案について Bitcoin-Devメーリングリストに投稿しました。提案を紹介するために、 Gibsonはオンチェーンで実行するのが難しいゲームの良い例と彼が考えるチェスのゲームを実装しました。このゲームでは勝者が全額を獲得します。提案のリポジトリと論文の両方が公開されています。

2人のプレイヤー、アリスとボブは、ある一連のルールに合意します。各プレイヤーは自分の手を指します。紛争が発生した場合、アリスはオンチェーンでルールを強制できます。しかしGibsonは、ライトニングは公開された状態に関するルールを強制することはできるものの、相手方が停滞したり応答を停止したりした場合にはルールを強制できないと指摘しています。この問題に対処するため、 Gibsonはベニュー（venue）という仕組みを導入します。これは、署名済みメッセージ（チェスゲームの一手とその署名）が特定の期限前に公開されたかどうかを証明する役割を担う、メンバー委員会のようなものです。ベニューは、メッセージの内容そのものではなく、公開のタイミングが適切であったかどうかのみを証明します。紛争が発生した場合、アリスは「ボブからイベント（指し手）が公開されていない」と主張するトランザクションを送信します。これに対してボブは、反論（彼の一手とベニューによる証明）を含む2つめのトランザクションを送信できます。最後にアリスは、ボブの反論が無効であること（イベントがルールに準拠していないこと）を証明するトランザクションを送信できます。

Gibsonの提案では、ベニューがユーザーの資金を預かることはありません。さらに、不正行為を行ったメンバーを特定できるようにするため、FROST形式の閾値署名への依存を避けています。そのために、証明はOP_CHECKSIGADDを使って検証されるメンバーごとの「1ビット署名」によって行われます。メンバーには、アダプターを使用してチャネル上でアトミックに支払われる手数料が報酬として与えられます。しかし、この構成は「メンバーの過半数が誠実である」という仮定に依存しています。ベニューのメンバーの半数以上が関係者の一方と共謀した場合、資金が盗まれる可能性があります。

ゲーム以外の応用の可能性としては、ストレージ証明（Proof of Storage）コントラクトなどが考えられます。これは、検証要求（チャレンジ）に応答できなかった場合に保証金が没収されるという仕組みです。また、BitVMX形式のゼロ知識検証器がオンチェーンで行うような処理と同様の、オフチェーンでの紛争解決などが挙げられます。

リリースとリリース候補

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

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

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

最近の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の注目すべき変更点。

● Eclair #3396、#3397、#3400は、スプライシング中に悪意のあるチャネルピアが EclairによるHTLCのオンチェーンでの強制を妨げることができる複数の方法を修正します（ニュースレター #423参照）。これまでは、ピアは遠い絶対ロックタイムを選択したり、相対タイムロック付きのインプットを追加したり、非標準のウィットネスを提供したり、標準のトランザクションウェイト上限を超えたり、あるいは署名済みトランザクションの手数料率を低く設定したりすることで、速やかに公開できないスプライシングトランザクションにEclairが署名するよう仕向けることができました。 1つめのPRは、これらのケースに対するチェックを追加します。2つめのPRは、競合する未承認トランザクションによって拒否されたコミットメントトランザクションとペナルティトランザクションを、 Eclairが再試行するようにします。ピアが後に他のインプットの1つを二重支払いすることで、 RBFによりそのトランザクションを置き換える可能性があるためです。この再試行の修正は、ゼロ承認チャネルを含め、チャネルのファンディングトランザクションが未承認の場合にも適用されます。 3つめのPRは、別の復旧上のギャップを修正します。Eclairが兄弟トランザクションの試行に対するコミットメントを使って強制閉鎖した後に、スプライシングのRBF置換が承認された場合、Eclairはファンディングトランザクションが変更されたことを認識し、承認されたスプライシングアウトプットを使用するコミットメントトランザクションをブロードキャストするようになりました。これまでは、資金がロックされたままになり、HTLCが強制されない可能性がありました。
● Eclair #3399と#3394は、オンザフライファンディングにより、対応する受信HTLCを回収することなくEclairが下流ピアへ支払いをしてしまう2つの経路を修正します（ニュースレター #419参照）。これまでは、Eclairが期限切れの支払いの追跡を停止した後、新しい支払いがそのペイメントハッシュを再利用することができました。その後、下流ピアが元の送信HTLCをオンチェーンで請求してプリイメージを公開した場合、Eclairは元の支払いの受信HTLCではなく、新しい支払いの受信HTLCを誤って履行してしまい、元の受信HTLCがEclairへの支払いなしにタイムアウトすることを許す可能性がありました。 1つめのPRは、決済が現在追跡中の支払いに属しているかどうかをチェックし、属していない場合は、決済とともに保持された受信HTLCの詳細を使用して正しいHTLCを履行するようになりました。 2つめのPRは、資金提供された支払いが、流動性が購入されたチャネル上でのみ転送されることを保証します。これまでは、Eclairは同じピアとの別のチャネル上で転送することができましたが、期限切れ時に上流へ失敗を返す前に資金提供されたチャネルだけをチェックしており、他方のチャネル上の送信HTLCは請求可能なままでした。
● Eclair #3395は、支払人が有効なHMACを持つ不正な形式のペイメントオニオンパケットを構築し、受信HTLCを未解決のまま残せるバグを修正します。支払人は、有効なHMACを提供しながら、パケットの実際の容量よりも大きいホップごとのペイロード長をエンコードできました。これまでは、 Eclairは次のHMACを抽出する前に長さを検証していなかったため、捕捉されない例外が発生していました。その後、リレイヤーはHTLCを失敗させることなく再開し、不正な形式のパケットは再起動後のHTLCクリーンアップの初期化も妨げる可能性がありました。現在、Eclairは、 HMACを含むホップごとのペイロードがパケット内に収まることをチェックします。収まらない場合、 EclairはInvalidOnionVersionを返し、通常の失敗処理を可能にします。
● Eclair #3401は、切断後に転送ノードが資金を失う可能性のあるバグを修正します。Eclairは、対応するチャネル更新が署名されるまでHTLCを履行または失敗させるための命令を保存しており、再接続後にそれらを再試行できるようにしています。これまでは、履行がすでに提案されているがまだ署名されていないという理由で重複または競合する命令が拒否された場合、 Eclairは元の保存済み命令の削除をスケジュールしていました。署名前にチャネルが切断された場合、未署名の更新は破棄され、履行を再実行するための命令が残りませんでした。その結果、送信HTLCがすでに履行されているにもかかわらず、受信HTLCがタイムアウトする可能性がありました。Eclairは現在、決済が署名されるまで元の命令を保持します。
● LDK #5080は、協調的チャネル閉鎖中の再起動により、保留中のHTLCを上流ピアへ失敗として返せなくなる可能性のあるバグを修正します。これまでは、 LDKの再起動時に、協調閉鎖中のチャネルは未解決の支払いをまだ持っている可能性があるにもかかわらず、 HTLCの処理に使用されるルックアップから除外されていました。その結果、下流ピアがHTLCを失敗させた際に、 LDKは上流チャネルが存在しないものと誤って扱い、その失敗を破棄する可能性がありました。LDKはまた、オニオンの復号を待っている受信HTLCを取りこぼす可能性もありました。これにより、上流ピアが期限切れ時にチャネルを強制閉鎖するまで、HTLCが未解決のまま残る可能性がありました。LDKは現在、既存のHTLCを解決するために必要な情報を復元する際に、シャットダウン中のチャネルも含めます。
● LDK #5087は、ダミーホップを使用するブラインドパス上で送信されるオニオンメッセージにおける潜在的なプライバシー漏洩を修正します（ニュースレター #370参照）。ダミーホップとは、パス内での自身の位置を隠すために受信者が処理する追加の暗号化レイヤーです。これまでは、転送ホップはメッセージコンテンツのTLVレコードを含む中間オニオンレイヤーを拒否していましたが、ダミーホップはそれらを受け入れていました。悪意のある送信者は、これらのレコードを最終以外のさまざまなレイヤーに挿入し、最終的なメッセージが応答を生成したかどうかを観察することで、実際の転送がどこで終わりダミーホップがどこから始まるかを明らかにできる可能性がありました。LDKは現在、ダミーホップにおいてもメッセージコンテンツレコードを拒否します。
● LND #11068は、Taproot Assetsに使用される実験的なTaprootオーバーレイチャネルにおける補助的なHTLC署名のチェック漏れを修正します（ニュースレター #324参照）。これらのチャネルでは、Taproot Assetsの署名者（tapd）が、通常のBitcoin署名に加えて、ダストでない各HTLCに対する追加の署名エントリを提供します。これまでは、ピアが必要なBitcoin署名を含むものの補助HTLC署名エントリの一部または全部を省略したコミットメントを送信した場合、受信側のLNDノードはそれを誤って受け入れていました。チャネルが後に強制閉鎖された場合、欠落した署名により、影響を受けたアセットHTLCをオンチェーンで解決できなくなる可能性がありました。LNDは現在、受信した補助署名エントリの数がダストでないHTLCの数と一致することを検証します。一致しない場合、 LNDはコミットメントを拒否し、チャネルを強制閉鎖します。
● Rust Bitcoin #6956は、レガシーおよびSegwit v0の署名ハッシュに使用されるスクリプトデータのための ScriptCode型を導入します。これは、使用される完全なスクリプトとは異なる場合があります。BIP143によれば、 P2WSHスクリプトにOP_CODESEPARATORが含まれている場合、署名ハッシュは署名チェックの前に最後に実行されたセパレーターまで（それを含む）のすべてを除外し、それ以降のセパレーターは保持します。これまでは、p2wsh_signature_hashはwitnessスクリプトを受け取っており、これにより呼び出し側が完全なスクリプトをハッシュして無効な署名を生成してしまう可能性がありました。 APIは現在ScriptCodeを受け取りますが、呼び出し側は依然として最後に実行されたセパレーターを特定し、自身でスクリプトを短縮する必要があります。このPRはまた、P2WPKHインプットの署名に使用される標準スクリプトの、固定サイズでアロケーション不要な表現であるP2wpkhScriptCodeを追加します。
● BDK #2319は、Electrumをバックエンドとするウォレットが、再編成後に同じトランザクションが同じ高さで再びマイニングされた場合、トランザクションの承認を見失う可能性のあるバグを修正します。 BDKは置き換えられたブロックのヘッダーをキャッシュに保持したまま、置き換え後のブロックにおけるトランザクションの承認を認識できず、誤って未承認として表示する可能性がありました。この修正は、同期中に新しく取得したブロックヘッダーでヘッダーキャッシュを更新するようにします。これには1ブロックの再編成後も含まれます。

もっと知りたいですか？

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