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

Bitcoin Optech Newsletter #429

Oct 30, 2026

今週のニュースレターでは、マルチパーティウォレットでサイレントペイメントトランザクションを作成するためのプロトコルと、 Core Lightningの旧バージョンに影響するサービス拒否（DoS）脆弱性の責任ある開示、容易に発見可能な脆弱性に対するBitcoin Coreの更新されたセキュリティポリシーについて掲載しています。また、Bitcoin Stack Exchangeから選ばれた質問とその回答、新しいリリースとリリース候補の発表、人気のあるBitcoin基盤ソフトウェアの注目すべき更新など、恒例のセクションも含まれています。

ニュース

● マルチパーティウォレット向けのサイレントペイメント: Oleksandr Kurbatovは、サイレントペイメントトランザクションでマルチパーティのインプットを使用するためのプロトコルの説明をDelving Bitcoinに投稿しました。 BIP352は、セキュリティ証明が存在しないため、この種のインプットの使用を推奨していません。このプロトコルでは、マルチパーティの送信者が、署名者それぞれの寄与の加重和としてECDHシェアを計算できるようにすると同時に、 AggDLEQと呼ばれる集約DLEQ（離散対数の等価性）証明を提供して、 ECDHシェアがインプットの鍵から正しく導出されていることを証明します。この提案は、FROSTやMuSig2など、複数のマルチパーティプロトコルで動作します。

提案されたプロトコルは2つのラウンドで構成されます。コーディネーターは、署名者の集合、署名プロトコルの係数とtweak、鍵マテリアル、トランザクション、セッションIDを含むコンテキストを提供します。第1ラウンドでは、各署名者が2つのランダムなnonceを生成し、自身の鍵の断片から計算したECDHシェアやnonceのコミットメントなど、 AggDLEQに必要なメッセージをコーディネーターに返送します。コーディネーターはこれらのメッセージを使って、結合されたECDHシェアとチャレンジを計算します。第2ラウンドでは、各署名者が提供されたチャレンジに基づいて証明への寄与を生成します。応答が正しければ、コーディネーターはすべての応答をBIP374と互換性のある単一の証明へと集約します。

Kurbatovは、AggDLEQメッセージが署名者間でウォレットのコーディネーターチャネル上でのみ交換されるため、このプロトコルはBIP352、BIP374、BIP375、MuSig2やFROSTの署名プロトコルへの変更も、新しいPSBTフィールドも必要としないと述べています。また、セキュリティ証明を含む論文は内部レビュー中であるものの、不正な署名者とコーディネーターが証明や署名を偽造できないという主張は、その困難性が未解決の問題である仮定に依存していると指摘しています。
● CLNの自己参照チャネルアナウンスDoSの開示: Nishant Bansalは、 Core Lightning（CLN）バージョン25.02から26.04に影響するサービス拒否脆弱性の開示を Delving Bitcoinに投稿しました。CLNは、チャネルアナウンス内の2つのノードIDが異なることをチェックしていなかったため、同じノードを両端点として指定するアナウンスが検証を通過し、メモリ上のチャネルグラフに読み込まれる前にディスク上のゴシップストアに書き込まれていました。これを読み込むと不明なノードが2回追加され、gossipd内の重複禁止アサーションに引っかかってノードがクラッシュしました。保存されたメッセージは、オペレーターが手動で削除するまで再起動のたびにノードを再びクラッシュさせ、アップグレードだけではこれは解消されませんでした。

攻撃者に必要なのは、自身が管理する2-of-2アウトプットに資金を投入し、それらの鍵と新しいノード鍵でアナウンスに署名することだけであったため、コストはオンチェーン手数料に限られていました。古いCLNリリースはこのようなアナウンスをクラッシュすることなく受け入れて中継するため、攻撃者が直接到達できない脆弱なノードにもアナウンスを伝達する可能性がありました。

Bansalは、後にCore Lightning #9115で提案されたゴシップのファズターゲットを使ってこのバグを発見しました。これは4月に責任ある開示が行われ、 CLN 26.04.1（ニュースレター #398参照）において Core Lightning #9082によって修正されました。この修正は、 node_id_1がnode_id_2より厳密に小さくないアナウンスをすべて拒否します。 BOLTs #1333は、それまで送信者にのみIDの順序付けを要求していたBOLT7に、同じ要件を受信者側にも追加しました。影響を受けるバージョンをまだ使用しているオペレーターは、最新リリースにアップグレードする必要があります。
● Bitcoin Coreのセキュリティポリシー更新: Antoine Poinsotは、 Bitcoin Coreが容易に発見可能と分類する脆弱性（たとえば大規模言語モデルへの単純なプロンプトで見つかるもの）について、セキュリティポリシー（ニュースレター #306参照）を改訂したことを Bitcoin-Devメーリングリストに投稿しました。プロジェクトではこうしたバグの報告が増加しており、これらは再発見されたり、非公開の修正から推測されたりする可能性があります。ポリシーが通常適用する、次のメジャーリリースと深刻度に基づく猶予期間を待つのではなく、Bitcoin Coreは現在、すべてのメンテナンス対象リリースに修正をバックポートし、できるだけ早くポイントリリースを公開し、それと同時にアドバイザリを公開します。今週の注目すべきコードセクションで説明する3つの脆弱性（Bitcoin Core #36665、 #36667、#36669）は、この新しい分類の下で開示されました。これらの修正は32.0がタグ付けされた後にマージされたため、32.0はリリースされず、代わりにBitcoin Core 32.1（後述）が、31.2、30.4、29.5とともにこれらの修正を含んで提供されています。

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

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

● なぜBitcoinはトランザクションIDとwitnessトランザクションIDの両方を使うのですか？ Pieter Wuilleは、segwitで署名やその他の改変可能なデータをwitnessに移動し、 txidはそれを除外することで、未承認トランザクションの事前署名されたチェーンが引き続き機能するようにしたと説明しています。そのためインプットは依然としてtxidを参照します。ブロックはさらにwtxidにもコミットしており、これにより改ざんされたwitnessデータを含むブロックを渡されたノードは、ピアが提供するあらゆるバリエーションを再処理するのではなく、そのブロックを永久に拒否できます。 BIP339は後に、同様のサービス拒否対策上の理由から、wtxidの使用をトランザクションリレーにも拡張しました。
● Bitcoin CoreでMuSigに署名する方法 Ava Chowは、 MuSig2の署名には2つのラウンドが必要なため、各ウォレットはPSBTを2回処理しなければならないと説明しています。1回めのパスではウォレットの公開nonceを追加し、すべてのnonceが揃った後に結合されたPSBTに対して実行する2回めのパスでは部分署名を追加し、その後finalizepsbtがトランザクションを生成します。質問者は、Bitcoin CoreでMuSig2アドレスを作成し、それを使用する例を公開しました。
● Bitcoin P2Pプロトコルバージョン70017は70016と比べて何が変わったのですか？ Ava Chowは、BIP434がversionハンドシェイク中に交換される新しいfeatureメッセージを導入するため、新しいバージョン番号を割り当てていると説明しています。このメッセージ自体は、接続の存続期間中にピアがオプション機能を通知・交渉できるようにするもので、新機能ごとにプロトコルバージョンを上げたり専用メッセージを定義したりしてきた従来の慣行を置き換えます（ニュースレター #386参照）。 Bitcoin Coreは今年初めにこのメッセージとバージョン番号の引き上げを実装しており（ニュースレター #410参照）、両方とも後述のBitcoin Core 32.1に含まれています。

リリースとリリース候補

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

● Bitcoin Core 32.1は、ネットワークの主要なフルノード実装の最新メジャーリリースです。バージョン32.0はタグ付けされましたが、直前に問題が見つかったため正式にはリリースされませんでした。このリリースには、後述の3つのセキュリティ修正が含まれています。その他の変更には、 mempoolベースの手数料推定、デフォルトでPSBTv2の使用、監視専用ウォレットのエクスポート、ブロック検証の高速化が含まれます。既存のトランザクションインデックスおよびトランザクションアウトプットの使用インデックスは互換性を維持しますが、ディスク容量を節約するには再構築が必要です。詳細とアップグレード時の考慮事項についてはリリースノートをご覧ください。バージョン29.x以前はライフサイクルの終了に達しており、今後更新は提供されません。
● Bitcoin Core 31.2は、主要なフルノード実装のメンテナンスリリースです。 32.1と同じ3つのセキュリティ修正が含まれています。また、BIP323がマイナー向けの追加nonce領域として予約するバージョンビットをBIP9の未知のソフトフォーク警告から除外し（ニュースレター #409参照）、-privatebroadcastキューを10,000トランザクションに制限し、 chainstateデータベースを定期的にコンパクト化します。詳細はリリースノートをご覧ください。
● Bitcoin Core 30.4は、以前のメジャーリリースシリーズのメンテナンスリリースです。 32.1と同じ3つのセキュリティ修正、BIP323警告の変更、および1つのDNSシードの削除が含まれています。詳細はリリースノートをご覧ください。
● Bitcoin Core 29.5は、以前のメジャーリリースシリーズのメンテナンスリリースです。 32.1と同じ3つのセキュリティ修正と、1つのDNSシードの削除が含まれています。詳細はリリースノートをご覧ください。
● Eclair 0.14.6は、このLNノード実装のセキュリティリリースです。後述のスプライシングの強制閉鎖とオンザフライファンディングの手数料追跡に関する修正が含まれています。修正された問題の一部は悪意のあるピアによって悪用される可能性があるため、プロジェクトはアップグレードを強く推奨しています。
● LND v0.21.5-betaとv0.20.6-betaは、この人気のLNノード実装のメンテナンスリリースで、ニュースレター #428で取り上げたリリース候補に続くものです。どちらも、後述のコミットメントの手数料率の修正に加えて、TLVレコードパース時の過剰なメモリ割り当てと SQLデータベースのデッドロックの修正、SQLバックエンドのノードにおける起動時クリーンアップの高速化が含まれています。

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

最近の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 #36665は、接続されたピアがWindows、macOS、またはBSD上で動作するノードをクラッシュさせる可能性のあるメモリ枯渇の脆弱性を修正します。 Bitcoin Coreはピアの受信キューが大きくなりすぎるとそのピアからの読み取りを一時停止しますが、 select()ソケットバックエンドは例外的な状態の監視を継続していました。ピアはTCPの緊急データを送信することで追加の読み取りを引き起こし、キューの上限を回避できました。現在は、そのソケットの読み取りが有効な場合にのみ例外的な状態が監視されます。 Linuxは異なるソケットバックエンドを使用しているため影響を受けませんでした。
● Bitcoin Core #36667は、ノードがあるピアに対して持つ送信バッファが20分を超えて上限を超過し続けた場合にそのピアを切断するタイムアウトを追加し、無制限のメモリ増加を緩和します。 Bitcoin Coreは、この上限を超えた後も一部のトランザクションのアナウンスをキューに入れ続けます。通常であれば、 pingのタイムアウトによって読み取りの遅いピアは最終的に切断されます。しかし、 BIP31より前のプロトコルバージョンを主張するピアはこれを回避できました。これにより、悪意のあるピアはキューに入れられたアナウンスが徐々に蓄積される間、接続を開いたまま維持できました。新しいタイムアウトはピアのプロトコルバージョンに関係なく適用されます。 -blocksonlyオプションを使用しているノードは影響がはるかに小さいものでした。
● Bitcoin Core #36669は、再編成中にブロックを切り離すために必要なデータを破損させる可能性のあるundoファイルのオーバーフローを修正します。 undoデータは対応するブロックデータのサイズを超えることがあるため、 undoファイルは4 GiBを超えて32 bitのオフセットが一周し、それによって以前のデータを上書きしてしまう可能性がありました。その後の再編成によってノードが停止し、復旧には修正済みバージョンでの再インデックスが必要になる場合がありました。この修正はファイルオフセットのサイズを64 bitに拡大します。また、 Windowsでは2 GiBを超えると再編成がなくてもノードが停止する可能性があったため、 64 bitのファイル位置指定呼び出しを使用するようにしています。悪用には、特別に構築された数千のブロックをマイニングする必要があります。破損のケースではさらに、標的となるノードのブロックファイル内でそれらのブロックを正確に位置付けし、その後に再編成を行う必要があります。開示文書ではこれは非現実的であるとされています。32 bitシステムまたはFAT32のブロックストレージ上のノードは引き続き影響を受けます。
● BIPs #2130は、ドラフトBIP139「Wallet Metadata Export Format」を追加します。これは、ウォレットのアカウントとそのアウトプットスクリプトディスクリプター、署名者情報、ラベル、トランザクション、コイン、 PSBTをエクスポートするためのJSONフォーマットを規定するものです（ニュースレター #399参照）。このフォーマットは、ウォレット間でのメタデータの転送と、シードバックアップだけでは復元できない情報の復元を可能にします。仕様では、mainnetのエクスポートに秘密鍵やニーモニックシードを含めることを禁止しているため、これらのエクスポートは別途行う鍵のバックアップを補完するものとなります。
● Core Lightning #9627は、支払いの経路を選択する前に、 BOLT4が定めるペイメントオニオンのルーティング情報1,300 byte上限を考慮するようxpayを更新します。これまでは、経路探索は成功しても、選択された経路がこの上限を超えるとオニオンの構築が失敗することがありました。これにより、より短い経路なら成功していたかもしれない場合でも支払いが失敗する可能性がありました。 xpayは現在、受信者の最終ペイロードやインボイスのブラインドパスを考慮した上で利用可能な空き容量を計算し、 askreneのgetroutes RPCに新設されたmaxhopsパラメータを通じて対応するホップ数の上限を渡します。 askreneの経路探索コスト計算にも、より短いルートを優先するためのホップごとのペナルティが追加されています。
● Eclair #3417と#3419は、スプライシングトランザクションが未承認のままである場合の強制閉鎖処理を改善します（ニュースレター #427参照）。ゼロ承認ではないチャネルについて、Eclairは現在、ファンディングトランザクションが承認済みであるか、 Bitcoinバックエンドのmempoolに存在する最新のコミットメントを選択し、ブロックの到着やスプライシングトランザクションの公開に応じてその選択を再評価します。また、アンカーのCPFP手数料計算に未承認のファンディングの祖先トランザクションを含め、以前のファンディング状態に対する失効されていないリモートコミットメントのアウトプットについては、 1承認後に請求を開始します。新しいrequire-confirmed-inputs-for-splicing設定（デフォルトで有効）は、スプライシング時にピアからの承認済みインプットを要求し、前のスプライシングが承認されるまでEclairが別のスプライシングを開始しないようにします。この変更により、Eclairが別のコミットメントに切り替えた後に、以前公開したローカルコミットメントが承認された場合でも、それが認識されるようになります。これまでは、Eclairが自身の残高とHTLCアウトプットを請求しないまま放置してしまう可能性がありました。
● Eclair #3416は、ピアが合意済みのLiquidity Adsの手数料を支払わずにオンザフライファンディングを繰り返し取得できてしまうバグを修正します。これまでは、ピアがこれらの手数料をカバーするために提案された支払いを拒否しても、 Eclairは流動性の購入を完了してしまう可能性がありました。現在、Eclairは支払い不足の購入にフラグを立て、そのピアが将来の支払いから手数料を支払う方式（from_future_htlc）でさらに購入することをブロックします。マルチパスペイメントの他のパーツを決済してもフラグは解除されません。フラグが立てられたピアは、既存の不審なピアの上限に対してカウントされ、上限に達するとこの支払い方式がグローバルに無効化されます。フラグは、再起動時、オペレーターの介入、またはファンディングトランザクションが公開前に中止された場合に解除されます。
● LDK #5314は、オニオンメッセージの転送において、非アナウンスチャネルをそのオンチェーンのファンディングアウトプットに結び付けることを可能にしていたプライバシー漏洩を修正します。攻撃者は、アウトプットのブロックチェーン上の位置から候補となるショートチャネルID（SCID）を導出できます。疑わしいチャネルの両端点に接続し、それらを経由して自分自身に戻るオニオンメッセージを送信することで、攻撃者はSCIDを使って両者の間のチャネルを特定できました。メッセージを受信することで、アウトプットとノードの間の関連が確認されてしまいます。LDKは現在、オニオンメッセージを転送する際に非アナウンスチャネルの実際のSCIDを解決することを拒否します。 SCIDエイリアスは引き続き使用可能です。これは、ニュースレター #426で取り上げたHTLC転送におけるプライバシー保護を補完するものです。
● LDK #5412は、JITチャネル向けのLSPS2サーバーにおけるサービス拒否バグを修正します。これまでは、クライアントが元のリクエストが保留中のまま、同じリクエストIDを繰り返し送信することができました。重複ごとにサービス全体の保留リクエストカウンターが増加し、保存されたエントリが置き換えられていました。 1,000リクエストの上限に達すると、実際に処理すべきリクエストははるかに少ないにもかかわらず、 LSPは他のクライアントからのリクエストを拒否してしまいました。重複IDは現在、カウンターを増加させることも元のリクエストを置き換えることもなく拒否されます。
● LND #11164は、ノードがTaprootチャネルをアナウンスして検証できるようにする最新のTaprootゴシップ提案にメッセージフォーマットを合わせて更新することで、 gossip-v2の実装を前進させます。署名交換メッセージには、スプライシングに備えてファンディングの試行を区別するためのファンディングトランザクションIDが含まれるようになり、ノード鍵とファンディング鍵に対してそれぞれ別のMuSig2部分署名を運ぶようになりました。この変更では、手数料とキャパシティのフィールドのエンコーディングも修正され、デフォルト値を含むオプションフィールドも保持されます。これにより、メッセージがデコードされ再エンコードされる際に署名対象のバイト列が保持され、署名検証の失敗を防ぎます。
● LND #11373と#11380は、LNDの既存の最小コミットメント手数料率である253 sat/kwを、チャネル開設と手数料更新の際に一貫して適用します。これまでは、max-commit-fee-rate-anchors=1を設定するとレートが 1 sat/vbyte（250 sat/kwに相当し、最小値をわずかに下回る）に制限されていました。チャネルはそのレートで開設できましたが、以降のコミットメントの更新がそれを拒否するため、イニシエーターがレートを引き上げるまでHTLCを転送することができませんでした。LNDは現在、ローカルで提案する開設時のレートを最小値まで引き上げ、最小値を下回る受信提案を拒否します。また、コミットメントへの署名時にのみ拒否するのではなく、受信および送信する手数料更新を記録または送信する前に最小値と照合するようになりました。 LNDは最小値を下回って開設された既存チャネルの手数料率を引き上げようと試みますが、イニシエーターが引き上げ分を負担できない場合、それらのチャネルは引き続きHTLCを転送することができません。
● BTCPay Server #7744と#7748は、マーチャントがアプリケーションのAPIキーを承認する際の2つの誤りを修正します。マーチャントがチェックを外したオプションの権限が、それでも付与されてしまう可能性がありました。さらに、アプリケーションが別のストアをスコープとする権限を要求し、マーチャントが選択したストアの代わりにそのスコープが使用されてしまう可能性がありました。これらの修正により、マーチャントの権限選択が保持され、マーチャントのストア選択を適用する前にアプリケーションが指定したストアスコープが取り除かれます。これらの変更はキーの発行に影響するもので、ニュースレター #428で取り上げた権限適用の修正に続くものです。以前に発行されたキーはその権限を保持しているため、意図しないアクセスを許可している場合は取り消す必要がある場合があります。

もっと知りたいですか？

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