今週のニュースレターでは、ネスト型MuSig2ライトニングノードのアイディアと、 secp256k1のモジュロスカラー乗算の形式検証を行うプロジェクトを掲載しています。 また、サービスとクライアントソフトウェアの最近のアップデートや、 新しいリリースとリリース候補の発表、人気のビットコイン基盤ソフトウェアの注目すべき更新など、 恒例のセクションも含まれています。

ニュース

  • ● ライトニングネットワークでネスト型MuSig2を使用することに関する議論: ZmnSCPxjは、 最近の論文で議論されているネスト型MuSig2の提案を活用して k-of-nのマルチシグライトニングノードを作るアイディアについてDelving Bitcoinに投稿しました。 具体的には、まずこのような機能を持つことの重要性を説明し、次にライトニングプロトコルの現在の技術的制約について説明した上で、 最後にBOLT仕様を修正する提案を示しています。

    ZmnSCPxjによると、ライトニングにおいてk-of-nの署名スキームが必要とされる理由は、 大口の保有者が手数料と引き換えに自身の流動性をネットワークに提供したいというニーズに由来します。 こうした大口保有者は資金の安全性に関する強力な保証を必要とする可能性があり、 単一の鍵ではそれを提供できないかもしれません。一方、k-of-nのスキームであれば、 k個未満の鍵が侵害されても、必要なセキュリティを提供できます。

    現状では、BOLTの仕様はk-of-nマルチシグスキームを安全に実装する方法を規定していません。 その主な障害となっているのが失効鍵です。BOLTによると、失効鍵はshachainと呼ばれる仕組みを使って生成されますが、 その特性上、k-of-nのマルチシグスキームでの利用には適していません。

    ZmnSCPxjは、globalfeaturesおよびlocalfeaturesの両方で、 no_more_shachainsという新しい機能ビットのペアをシグナリングすることで、 ノードがチャネル相手からの失効鍵に対するshachain検証を行うかどうかをオプションにできるよう、 BOLT仕様を修正することを提案しています。奇数ビットは、レガシーノードとの互換性を保つために自分自身は shachainとして有効な失効鍵を提供しつつ、相手側のshachain検証は行わないことを示します。 一方、偶数ビットは、shachainとして有効な失効鍵の検証も提供も行わないことを示します。 前者は、ZmnSCPxjがゲートウェイノードと定義する、 ネットワークの残りの部分と（偶数ビットを持つ）k-of-nノードとを接続するノードによって使用されます。

    最後にZmnSCPxjは、この提案には大きなトレードオフ、すなわち失効鍵のストレージ要件があることを強調しています。 実際、ノードはコンパクトなshachain表現の代わりに、個々の失効鍵を保存する必要があり、 必要となるディスク量は実質3倍になります。

  • ● secp256k1のモジュロスカラー乗算の形式検証: Remix7531は、secp256k1のモジュロスカラー乗算の形式検証を作成したことを Bitcoin-Devメーリングリストに投稿しました。 このプロジェクトは、bitcoin-core/secp256k1サブセットに対する形式検証が実用的であることを示すものです。

    secp256k1-scalar-fv-testコードベースにおいて、 Remix7531は同ライブラリの実際のCのコードを取り上げ、RocqおよびVST（Verified Software Toolchain）を用いて形式的な数学的仕様に対する正しさを証明しています。 Rocqによる形式化では、メモリエラーの有無、仕様に対する正しさ、そして停止性を証明できます。

    彼は既存のスカラー乗算の証明をRefinedCに移植する予定です。 スカラー乗算の証明を移植することで、同じ検証済みコード上で両フレームワークを直接比較できるようになります。 また、検証面における次のターゲットは、署名のバッチ検証に使われるマルチスカラー乗算用のPippengerアルゴリズムです。

サービスとクライアントソフトウェアの更新

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

  • ● Coldcard 6.5.0でMuSig2とminiscriptを追加: Coldcard 6.5.0では、MuSig2署名のサポート、 BIP322のProof of Reserve機能、そして最大8リーフまでのTapscriptサポートを含むminiscriptとTaproot機能が追加されました。

  • ● Frigate 1.4.0 リリース: サイレントペイメントのスキャン用の実験的なElectrumサーバーである Frigate v1.4.0（ニュースレター #389参照）は、 最新のGPUコンピューティングとUltrafastSecp256k1を組み合わせることで、 数カ月分のブロックのスキャン時間を１時間から0.5秒に短縮しました。

  • ● Bitcoin Backboneの更新: Bitcoin Backboneは、BIP152のコンパクトブロックのサポート、 トランザクションおよびアドレス管理の改善、マルチプロセスインターフェースの基盤構築など 複数の更新をリリースしました（ニュースレター #368参照）。 発表では、スタンドアロンのヘッダー検証とトランザクション検証のためのBitcoin Kernel APIの拡張も提案されています。

  • ● Utreexod 0.5 リリース: Utreexod v0.5では、SwiftSyncを使用したIBDを導入しました。 これは、暗号学的集約によりIBD中にアキュムレーターの包含証明をダウンロードして検証する必要性をなくし、 IBD中にCompact Stateノードによってダウンロードされるデータを1.4TBから約200GBに削減します。 証明のキャッシュによりさらに削減することも可能です。

  • ● Floresta 0.9.0 リリース: Floresta v0.9.0は、UTXOプルーフの交換用に P2PネットワークをBIP183に合わせ、 libbitcoinconsensusをBitcoin Kernelに置き換えることで、スクリプト検証を約15倍高速化するなど、 さまざまな変更を加えています。

リリースとリリース候補

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

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

  • ● Core Lightning 26.04rc3は、この人気のLNノードの次期メジャーバージョンのリリース候補で、 以前のリリース候補からスプライシング関連の更新やバグ修正が続いています。

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

今週の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 #34401は、libbitcoinkernel C API（ニュースレター #380および#390参照）に追加された btck_BlockHeaderサポートを拡張し、ブロックヘッダーを標準のバイトエンコーディングにシリアライズするメソッドを追加しました。 これにより、C APIを使用する外部プログラムが、別途シリアライズコードを持つことなく、 シリアライズされたヘッダーを保存、送信または比較できるようになります。

  • ● Bitcoin Core #35032は、sendrawtransaction RPCでprivatebroadcastオプション（ ニュースレター #388参照）を使用した際に学習されたネットワークアドレスを、 Bitcoin Coreのピアアドレスマネージャーであるaddrmanに保存しないようにしました。 privatebroadcastオプションは、ユーザーが短命のTorまたはI2P接続、 あるいはTorプロキシを介してIPv4/IPv6ピアにトランザクションをブロードキャストできるようにします。

  • ● Core Lightning #9021は、スプライシングがBOLTの仕様にマージされたことを受け（ニュースレター #398参照）、 スプライシングを実験的ステータスから外し、デフォルトで有効にします。

  • ● Core Lightning #9046は、keysend支払いにおける想定 final_cltv_expiry（最終ホップのCLTV expiry delta）を 22ブロックから42ブロックに引き上げ、LDKの値と一致させて相互運用性を復元します。

  • ● LDK #4515は、ゼロ手数料コミットメント（0FC）チャネル（ニュースレター #371参照）を 実験的な機能ビットからプロダクション用の機能ビットに切り替えます。 0FCチャネルは、2つのアンカーアウトプットを 240satsの1つの共有Pay-to-Anchor (P2A)アウトプットに置き換えます。

  • ● LDK #4558は、不完全なマルチパス支払いに対する既存の受信側のタイムアウトを keysend支払いにも適用します。これまでは、不完全なkeysend MPPは、 通常のタイムアウト期間後にフォールバックされる代わりにCLTVの期限まで保留状態のまま残り、 HTLCスロットを占有し続ける可能性がありました。

  • ● LND #9985は、独自のコミットメントタイプ（SIMPLE_TAPROOT_FINAL）と プロダクション用のフィーチャービット80/81を備えたプロダクション用のSimple Taproot Channelに対するエンドツーエンドのサポートを追加します。 プロダクションでは、OP_CHECKSIG+OP_DROPよりもOP_CHECKSIGVERIFYを優先する最適化された Tapscriptsを使用し、また将来のスプライシングに向けた基盤として、 ファンディングtxidをキーとしたマップベースのナンスのハンドリングをrevoke_and_ackに追加しています。

  • ● BTCPay Server #7250は、LNURL-pay経由で作成された BOLT11インボイスが決済済みかどうかを外部サービスが検証できるようにする、 verifyという名前のオプションの非認証エンドポイントを導入することで、LUD-21のサポートを追加します。

  • ● BIPs #2089は、BIP376を公開しました。このBIPは、 サイレントペイメントアウトプットの署名と使用に必要なBIP352のtweakデータを格納するための 新しいインプット単位のPSBTv2フィールドと、BIP352の33 byteのspend keyと互換性のあるオプションのspend-key BIP32導出フィールドを定義します。 これは、PSBTを用いてサイレントペイメントアウトプットを作成する方法を規定する BIP375（ニュースレター #337参照）を補完するものです。

もっと知りたいですか？

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