今週のニュースレターでは、ブラインドMuSig2を用いたVaultのようなスキームの概要と、 Bitcoinクライアントが新しいP2P機能のサポートをアナウンスしネゴシエーションするための提案を掲載しています。 また、コンセンサスの変更に関する議論や、新しいリリースとリリース候補の発表、 人気のBitcoin基盤ソフトウェアの注目すべき更新など、恒例のセクションも含まれています。

ニュース

  • ● ブラインド共同署名者を用いたVaultの構築: Jonathan T. Halsethは、 ブラインド共同署名者を用いたVaultのようなスキームのプロトタイプを Delving Bitcoinに投稿しました。共同署名者を用いた従来のセットアップとは異なり、 このスキームは、MuSig2のブラインド版を用いることで、 署名者が署名に関わる資金について可能な限り情報を持たないようにします。 署名者が与えられたものに盲目的に署名するようなことを防ぐため、 このスキームでは署名要求にゼロ知識証明を添付し、 トランザクションが事前に定められたポリシー（この場合はタイムロック）に従って有効であることを保証します。

    Halsethは、初期デポジット、リカバリー、Vaultの解除およびVaultの解除後のリカバリーという 4つのトランザクションが事前署名されるスキームのグラフを提供しています。Vaultの解除時に、 共同署名者は署名するトランザクションに適切なタイムロックが正しく設定されていることのゼロ知識証明を要求します。 これにより、不正なVaultの解除が行われた場合に、ユーザーまたはウォッチタワーが資金をスイープする時間を確保できます。

    Halsethは、regtestおよびsignetで利用可能なプロトタイプ実装も提供しています。

  • ● ピア機能のネゴシエーション: Anthony Townsは、 ピアが新機能のサポートをアナウンスおよびネゴシエーションできるようにするP2Pメッセージを定義した 新しいBIPの提案をBitcoin-Devメーリングリストに投稿しました。 このアイディアは2020年に提案されたものと似ており、 Townsのテンプレートの共有の取り組みを含む、さまざまなP2Pユースケースの提案に役立つでしょう。

    歴史的に、P2Pプロトコルの変更は、新機能のサポートを通知するためのバージョンの引き上げに依存しており、 ピアが互換性のあるノードとのみネゴシエーションすることを保証していました。しかしこのアプローチは、 特に共通の採用を必要としない機能について、実装間で不必要な調整の負担を発生させます。

    このBIPは、今後のP2Pアップグレードに対応できるように、verack前のフェーズで アナウンスおよびネゴシエーションするための汎用的なP2Pメッセージを導入することで、 BIP339のメカニズムを一般化することを提案しています。 これにより、調整負担の軽減、パーミッションレスな拡張性の実現、ネットワーク分断の防止、 多様なクライアントとの互換性の最大化が可能になります。

コンセンサスの変更

Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション

  • ● 2106年のタイムスタンプオーバーフローのuint64への移行: Asher Haimは、Bitcoin開発者に対してブロックタイムスタンプをuint32からuint64へ移行する迅速な準備の呼びかけを Bitcoin-Devメーリングリストに投稿しました。Haimは、 2106年以降を参照する長期金融契約が驚くほど早く現れる可能性があることから、迅速な対応が必要な理由を説明しています。 これはまだBIP形式の具体的な提案ではなく、タイムロックやBitcoinエコシステムの他のパーツに関連する多くの詳細を追加で詰める必要があります。 2024年1月のBitBlendの提案が1つの具体的な解決策として挙げられています。

  • ● 2106年のソフトフォークに向けたBIP54タイムスタンプ制限の緩和: Josh Domanは、2106年のブロックタイムスタンプオーバーフロー問題に対するソフトフォークソリューションを可能にするため、 コンセンサスクリーンアップ提案を修正して特殊なブロックタイムスタンプの動作をより許容するようにすることに価値があるかどうかの問いかけを Bitcoin-DevメーリングリストとDelving Bitcoinに投稿しました。 ZmnSCPxjは、2021年に類似の提案をしていました。両フォーラムの議論は、 ハードフォークを追求すべき健全なエンジニアリング上の理由がある場合に、 それを回避することに価値があるかどうかという問いに集中しました。Greg Maxwellは、 BIP54が解決しようとしているタイムワープ攻撃の修正を元に戻すリスクだけでも、 このような形で制限を緩和しようとすべきでない十分な理由になると述べました。

  • ● CTVフットガンの理解と軽減: Chris Stewartは、 OP_CHECKTEMPLATEVERIFY (CTV)を用いた「フットガン」（ 自分の足を撃つような落とし穴）についての議論をDelving Bitcoinに投稿しました。 具体的には、インプットが1つのCTVハッシュで、指定されたアウトプットの合計金額よりも低い金額が、 そのCTVハッシュを無条件に要求するscriptPubKeyに送金された場合、その結果のアウトプットは永遠に使えなくなります。 彼は、CTVユーザーがすべてのCTVがハッシュを2つ以上のインプットにコミットすることで、 この問題を軽減できると提案しています。こうすることで、常に追加のインプットを構築し、 そのようなアウトプットを使用可能にすることができます。

    Greg Sandersはこのアプローチのいくつかの制限について回答し、 1440000bytesはこれは次のトランザクションテンプレートが無条件に強制される場合にのみ適用されると言及しました。 Greg Maxwellは、これがトランザクションテンプレートコベナンツ全般を避けるべき理由だと主張しました。 Brandon Blackは、受け取りアドレスでのCTVの使用は確かにリスクのあるアプリケーション設計であり、 OP_CHECKCONTRACTVERIFY（BIP443）などの別のopcodeをCTVと組み合わせることで、 より安全なアプリケーションが可能になるかもしれないと示唆しました。

  • ● CTVアクティベーション会議: 開発者の1440000bytesは、 CTV（BIP119）アクティベーション会議を開催しました。 会議の参加者は、CTVアクティベーションクライアントは保守的なパラメーター（つまり、 長いシグナリング期間とアクティベーション期間）とBIP9を使用すべきであることに同意しました。 執筆時点で、他の開発者はメーリングリストで意見を表明していません。

  • ● より安価なコンソリデーションを可能にするOP_CHECKCONSOLIDATION: billymcbipは、 コンソリデーション（統合）に特化して最適化されたopcodeを提案しました。 OP_CHECKCONSOLIDATION（CC）は、同じトランザクション内のより先にあるインプットと同じ scriptPubKeyを持つインプットに対して実行された場合にのみ1と評価されます。 多くの議論は、同じscriptPubKeyの使用を義務付けることがアドレスの再利用を促進し、 プライバシーを侵害するという点に集中しました。Brandon Blackは、 OP_CHECKCONTRACTVERIFY（BIP443）を用いた同様の（ただしbyte効率は落ちる）機能を提案しました。 この提案は、Tadge Dryjaの以前のOP_CHECKINPUTVERIFYの研究に似ていますが、 byte効率が大幅に高く汎用性は低いです。

  • ● Bitcoinのポスト量子時代にむけたハッシュベースの署名: Mikhail KudinovとJonas Nickは、 Bitcoinで使用するためのハッシュベースの署名の評価に関する取り組みについて、 Bitcoin-Devメーリングリストに投稿しました。 彼らの研究では、現在の標準化された手法と比較して署名サイズを最適化できる大きな可能性が見出されたものの、 BIP32、BIP327、FROSTに代わる適切な手法は見つかりませんでした。 複数の開発者が参加し、この研究や他のポスト量子署名メカニズム、 そしてBitcoin開発の潜在的な方向性について議論しました。

    また、新しい署名検証メカニズムをbyteあたりのCPUサイクル数で比較するのが適切か、 署名あたりのCPUサイクル数で比較するのが適切かについても議論されました。 新しい署名検証が既存のウェイト制限と乗数によって制限され、支払いスループットが低下する場合は、 byteあたりのCPUサイクル数の方が適切と思われます。新しい署名に独自の制限を設け、 ポスト量子Bitcoinにおいて現在の支払いスループットに近い値を実現する場合は、 署名あたりのCPUサイクル数で比較するのがより適切かもしれません。

リリースとリリース候補

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

  • ● BTCPay Server 2.3.0は、この人気のセルフホスト型ペイメントソリューションのリリースで、 ユーザーインターフェイスとAPIにサブスクリプション機能（ニュースレター #379参照）が追加され、 ペイメントリクエストが改善され、その他の機能やバグ修正もいくつか含まれています。

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

最近の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 #33657は、ブロックのバイト範囲を返す新しいRESTエンドポイント /rest/blockpart/<BLOCKHASH>.bin?offset=X&size=Yを導入します。これにより、 Electrsなどの外部インデックスがブロック全体をダウンロードする代わりに、 特定のトランザクションのみを取得できるようになります。

  • ● Bitcoin Core #32414は、IBD中の既存の対応に加えて、 再インデックス中にUTXOキャッシュを定期的にディスクにフラッシュするようになりました。 これまでは、チェーンの先端に到達した場合のみフラッシュが行われていたため、 dbcacheに大きな値が設定されている場合、再インデックス中にクラッシュすると大きな進捗が失われる可能性がありました。

  • ● Bitcoin Core #32545は、以前導入されたクラスターリニアライゼーションアルゴリズム（ニュースレター #314参照）を、処理困難なクラスターをより効率的に処理するよう設計された スパニング・フォレストリニアライゼーションアルゴリズムに置き換えました。 過去のmempoolデータのテストでは、新しいアルゴリズムは最大64トランザクションまでの 観測されたすべてのクラスターを数十マイクロ秒でリニアライゼーションできることが示されています。 これは、クラスターmempoolプロジェクトの一部です。

  • ● Bitcoin Core #33892は、リレーポリシーを緩和し、親が非TRUCであっても、 パッケージ手数料率がノードの現在の最小リレー手数料を超えており、かつ子に最小手数料を下回る祖先が存在しない場合に、 親が最小リレー手数料を下回っていても日和見的な1P1Cパッケージリレーを許可するようにしました。 これは以前、mempoolのトリミングに関する判断を簡素化するためにTRUCトランザクションのみに制限されていましたが、 クラスター mempoolではもはや懸念事項ではなくなりました。

  • ● Core Lightning #8784は、xpay RPCコマンド（ニュースレター #330参照）に payer_noteフィールドを追加し、支払人がインボイスを要求する際に支払いの説明を提供できるようにしました。 fetchinvoiceコマンドには既に同様のpayer_noteフィールドがあるため、このPRはxpayにも追加し、 その値を基盤となるフローに渡すようにしました。

  • ● LND #9489および#10049は、BuildOnion、SendOnionおよびTrackOnion RPCを備えた実験的なswitchrpc gRPCサブシステムを導入し、 外部コントローラーがHTLCの配信にLNDを使用しながら、 経路探索と支払いのライフサイクルの管理を処理できるようにしました。 サーバーのコンパイルは非デフォルトのswitchrpcビルドタグの背後に隠されています。 LND #10049は具体的に、外部からの試行の追跡のためのストレージ基盤を追加し、 将来の冪等バージョンの基礎を築きました。現在、資金の損失を避けるため、 switch経由で試行をディスパッチできるのは一度に1つのエンティティのみに制限されています。

  • ● BIPs #2051は、BIP3の仕様にいくつかの変更を加えました。 最近追加されたLLMの使用に対するガイダンス（ニュースレター #378参照）を取り消し、 リファレンス実装のフォーマットを拡大し、変更履歴を追加し、その他のいくつかの改善と明確化を行いました。

  • ● BOLTs #1299は、BOLT3仕様を更新し、取引相手to_remoteへの支払いアウトプットで プレコミットメントポイントlocalpubkeyを使用することに関する曖昧な注記を削除しました。 option_static_remotekeyでは、to_remoteアウトプットは、 プレコミットメントポイントなしで資金の回収を可能にするため、受取人の静的なpayment_basepointを使用することが期待されており、 これはもはや有効ではなくなりました。

  • ● BOLTs #1305は、BOLT11仕様を更新し、nフィールド（受け取りノードの33byteの公開鍵）が 必須ではないことを明確にしました。これは、以前必須であると記載していた文章を修正するものです。

もっと知りたいですか？

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