今週のニュースレターでは、サイレントペイメントのスキャンパフォーマンスのワーストケースの改善に関する議論と、 単一の鍵で複数の支払い条件を可能にするアイディアを掲載しています。また、新しいリリースおよびリリース候補の発表、 人気のBitcoin基盤ソフトウェアの注目すべき更新など、恒例のセクションも含まれています。

ニュース

  • ● グループ毎のサイレントペイメント受信者数の制限提案: Sebastian Falbesonerは、サイレントペイメント受信者に対する理論的な攻撃の発見と その緩和策をBitcoin-Devメーリングリストに投稿しました。この攻撃は、 攻撃者が同一のエンティティを標的とした多数のTaprootアウトプット（現在のコンセンサスルールでは1ブロックあたり 最大23,255アウトプット）を持つトランザクションを構成した場合に発生します。 グループサイズに制限がない場合、処理に数十秒ではなく、数分かかることになります。

    これを受けて、単一トランザクション内のグループ毎の受信者数を制限する新しいパラメーター K_maxを追加する緩和策が提案されました。理論上、この変更には後方互換性はありませんが、 実際には十分に大きなK_maxを設定すれば、既存のサイレントペイメントウォレットに影響が及ぶことはないはずです。 FalbesonerはK_max=1000を提案しています。

    Falbesonerは、提案された制限に対するフィードバックや懸念を求めています。 また、ほとんどのサイレントペイメントウォレットの開発者には既に通知済みであり、 この問題を認識しているとも述べています。

  • ● BLISK（Boolean circuit Logic Integrated into the Single Key）: Oleksandr Kurbatovは、ブール論理を用いて複雑な認可ポリシーを表現するために設計されたプロトコルである BLISKについてDelving Bitcoinに投稿しました。たとえば、 MuSig2のようなプロトコルは効率的でプライバシーを保護するものの、 カーディナリティ（k-of-n）しか表現できず、「誰が」支払えるかを特定することができません。

    BLISKはシンプルなAND/ORブール回路を構成し、論理ゲートを既知の暗号技術にマッピングします。 具体的には、ANDゲートはn-of-nマルチシグの構成を適用することで実現され、 各参加者が有効な署名を提供する必要があります。一方、ORゲートはECDHなどの 鍵合意プロトコルを活用することで実現され、参加者は誰でも自分の秘密鍵と他の参加者の公開鍵を用いて共有シークレットを導出できます。 また、非対話型ゼロ知識証明を適用することで、回路の解決を検証可能にし、不正行為を防止します。 BLISKは、回路を単一の署名検証鍵に帰着させます。これは、1つの公開鍵に対して 1つのSchnorr署名を検証すればいいことを意味します。

    他のアプローチと比較したBLISKのもう1つの重要な利点は、新しい鍵ペアを生成する必要がないことです。 実際に、既存の鍵を特定の署名インスタンスに接続することが可能です。

    Kurbatovは、このプロトコルの概念実証を提供していますが フレームワークはまだ運用環境に提供できる成熟度には達していないと述べています。

リリースとリリース候補

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

  • ● Bitcoin Core 29.3は、以前のメジャーリリースシリーズに対するメンテナンスリリースで、 複数のウォレット移行の修正（ニュースレター#387参照）、 レガシースクリプトにおける二次的なsighashの影響を軽減するインプット毎のsighashの中間状態のキャッシュ（ニュースレター #367参照）、コンセンサスで無効なトランザクションに対するピア排除の廃止（ニュースレター #367参照）が含まれています。すべての詳細はリリースノートをご覧ください。

  • ● LDK 0.2.2は、LN対応アプリケーションを構築するためのこのライブラリのメンテナンスリリースです。 SplicePrototype機能フラグを本番用の機能ビット（63）に更新し、非同期の ChannelMonitorUpdate永続化操作が再起動時にハングして強制閉鎖につながる可能性がある問題を修正し、 ピアから無効なスプライシングメッセージを受信した際に発生するデバッグアサーション障害を修正しています。

  • ● HWI 3.2.0は、複数のハードウェア署名デバイスに共通インターフェースを提供するこのパッケージのリリースです。 新しいリリースでは、Jade PlusやBitBox02 Novaデバイスのサポート、 testnet4、Jade用のネイティブPSBT署名および、 BIP373で規定されたMuSig2 PSBTフィールドのサポートが追加されています。

  • ● Bitcoin Inquisition 29.2は、提案中のソフトフォークやその他の主要なプロトコル変更を実験するために設計された signetフルノードのリリースです。Bitcoin Core 29.3r2をベースとし、 このリリースではBIP54（コンセンサスクリーンアップ）提案を実装し、 testnet4を無効化しています。

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

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

  • ● Bitcoin Core #32420は、マイニングIPCインターフェース（ニュースレター #310参照）を更新し、 コインベースのscriptSigにダミーのextraNonceを含めないようにしました。 CreateNewBlock()に新しくinclude_dummy_extranonceオプションが追加され、 IPCコードパスではこれにfalseが設定されます。Stratum v2クライアントは、 scriptSigでコンセンサスで必要なBIP34の高さのみを受け取り、 余分なデータを除去したり無視したりする必要がなくなります。

  • ● Core Lightning #8772は、レガシーオニオン支払いフォーマットのサポートを削除しました。 CLNは2022年にレガシーオニオンの作成を止めましたが（ニュースレター #193参照）、 LNDの旧バージョンが生成するわずかに残ったレガシーオニオンを処理するために、 v24.05で変換レイヤーを追加していました。LND v0.18.3以降、これらは生成されなくなったため、サポートが不要になりました。 レガシーフォーマットは2022年にBOLT仕様から削除されています（ニュースレター #220参照）。

  • ● LND #10507は、GetInfo RPCレスポンスに新しいwallet_syncedブールフィールドを追加しました。 これはウォレットが現在のチェーンの先端へのキャッチアップを完了したかどうかを示します。 既存のsynced_to_chainブールフィールドとは異なり、この新しいフィールドはtrueを返す前に、 （チャネルアナウンスを検証する）チャネルグラフルーターや、 （ブロック駆動イベントを調整するサブシステムである）blockbeat dispatcherの同期を必要としません。

  • ● LDK #4387は、スプライシングの機能フラグを暫定ビット155から 運用ビット63に切り替えました。LDK v0.2はビット155を使用していましたが、 Eclairも現在のドラフト仕様より前に作られた互換性のないPhoenix固有のスプライシング実装にこのビットを使用しています。 これにより、EclairノードがLDKノードに接続する際に自身のプロトコルでスプライシングを試行し、 デシリアライゼーションの失敗と再接続が発生していました。

  • ● LDK #4355は、スプライシングおよびデュアル・ファンディングチャネルのネゴシエーション中に交換されるコミットメント署名の非同期署名サポートを追加しました。 EcdsaChannelSigner::sign_counterparty_commitmentを受信すると、 非同期署名者は即座にリターンし、署名の準備ができた時点でChannelManager::signer_unblockedを介してコールバックします。 デュアルファンディングチャネルで非同期署名を完全にサポートするには、まだ追加の作業が必要です。

  • ● LDK #4354は、negotiate_anchors_zero_fee_htlc_tx設定オプションをデフォルトでtrueに設定することで、 アンカーアウトプットを持つチャネルをデフォルトにしました。 自動チャネル受け入れは削除され、すべてのインバウンドチャネル要求は手動で承認する必要があります。 これにより、強制閉鎖が発生した場合に、ウォレットが手数料を賄うのに十分なオンチェーン資金を確保できるようにします。

  • ● LDK #4303は、ChannelManagerの再起動後にHTLCが二重転送される可能性がある2つのバグを修正しました。 1つはアウトバウンドHTLCがまだ保留中セル（内部キュー）にあるが見落とされるケース、 もう1つは既に転送・決済されてアウトバウンドチャネルから削除されているが、 インバウンド側の保留中セルにまだ解決エントリーが残っているケースです。 このPRはまた、インバウンドHTLCのオニオンが取り消し不能な形で転送された後にプルーニングする処理も追加しています。

  • ● HWI #784は、BIP327で規定されたMuSig2フィールドの PSBTシリアライゼーションおよびデシリアライゼーションサポートを追加しました。 これには、インプットとアウトプットの両方に対する参加者の公開鍵、公開ナンス、部分署名が含まれます。

  • ● BIPs #2092は、BIP434のfeatureメッセージに1 byteのv2 P2PトランスポートメッセージタイプIDを割り当て、開発者が競合を回避できるように BIP間で1 byteのIDの割り当てを追跡する補助ファイルをBIP324に追加します。このファイルには、 BIP183で提案されたUtreexoの割り当ても記録されています。

  • ● BIPs #2004は、Chain Code Delegation（ニュースレター #364参照）に関する BIP89を追加しました。これは協調カストディの手法であり、代理人は委任者のBIP32チェーンコードを知らず、 どのアドレスが資金を受け取ったかを知ることなく署名を生成するのに必要な情報のみを委任者と共有します。

  • ● BIPs #2017は、コンセンサスレベルでデータ伝送トランザクションフィールドを約1年間一時的に制限する提案である RDTS（Reduced Data Temporary Softfork）を規定するBIP110を追加します。 このルールでは、（83 byteまでのOP_RETURNを除いて）34 byteを超えるscriptPubKey、 256 byteを超えるpushdataおよびwitnessスタック要素、未定義のwitnessバージョンの使用、 Taproot annex、257 byteを超えるコントロールブロック、 OP_SUCCESS opcodeおよび、Tapscript内のOP_IF/OP_NOTIFが無効化されます。 アクティベーション前に作成されたUTXOを使用するインプットは除外されます。 アクティベーションでは、マイナーのシグナリングの閾値を55%に引き下げ、 2026年9月頃までに強制ロックインを行う、修正版のBIP9デプロイメントが使用されます。 この提案に関する以前の記事については、ニュースレター #379をご覧ください。

  • ● Bitcoin Inquisition #99では、signetにBIP54 コンセンサスクリーンアップソフトフォークルールの実装が追加されました。 実装された4つの緩和策は、トランザクション毎の潜在的に実行されるレガシーsigops数の制限、 2時間の猶予期間によるタイムワープ攻撃の防止（および負の難易度調整インターバルの防止）、 コインベーストランザクションのブロック高へのタイムロックの義務化および 64 byteトランザクションの無効化です。

もっと知りたいですか？

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