今週のニュースレターでは、閾値署名におけるユーザビリティとセキュリティのトレードオフに関する研究と、 ネストされた閾値署名を単層の署名グループに変換するアプローチの概要、 制限されたルールセットの下でUTXOセットにデータを埋め込むことができる範囲の検証について掲載しています。 また、Bitcoin Core PR Review Clubミーティングの概要や、 新しいリリースとリリース候補の発表、人気のBitcoinインフラストラクチャプロジェクトにおける注目すべき更新など、 恒例のセクションも含まれています。

ニュース

  • ● 最適な閾値署名: Sindura Saraswathiは、マルチシグ方式で最適な閾値を決定するKorok Rayとの研究を Delving Bitcoinに投稿しました。この研究では、 ユーザビリティとセキュリティパラメーターおよび、それらの関係性、 そしてそれらがユーザーが選択すべき閾値にどのように影響するかについて考察しています。 p(τ)とq(τ)を定義し、それらを閉形式の解に組み合わせることで、 セキュリティとユーザビリティの間のギャップを明らかにしています。 Saraswathiはまた、初期段階では高い閾値を使用し、後の段階では徐々に閾値を下げる 劣化型閾値署名の使用についても探求しています。 これは時間の経過とともに攻撃者が資金を奪うためのアクセス権限を拡大することを意味します。 また、Taprootを用いることで、 Taptreeとタイムロックやマルチシグを含むより複雑なコントラクトを通じて、 これらの新しい可能性が利用可能になる可能性があるとも述べています。

  • ● 特定のネストされた閾値署名のフラット化: ZmnSCPxjは、安全性が証明されていない場合のネストされたSchnorr署名の使用を回避する方法について Delving Bitcoinに投稿しました。たとえばアリスが、 ボブ、キャロル、ダンのグループと契約を締結するとします。すべての取引は、 ボブ、キャロル、ダンのうち少なくとも2人とアリスの承認を得る必要があります。 理論的には、これはマルチシグ（例：MuSig）で実現できます。 アリスが1つの部分署名を提供し、閾値署名（例：FROST）を使って ボブ、キャロル、ダンがもう１つの部分署名を生成します。ただしZmnSCPxjは、 「現時点ではFROST-in-MuSigが安全であるという証明はありません」と書いています。 代わりに、ZmnSCPxjは閾値署名のみを使ってこの例を実現することができると指摘しています。 アリスには複数のシェアが与えられます。充足数を妨げるのには十分なものの一方的には署名できない数です。 他の署名者にはそれぞれ1つずつシェアが与えられます。

    この機能の用途としては、マルチオペレーターのステートチェーン、 複数の署名デバイスを使用したいLNユーザー、そしてZmnSCPxjの LSP強化型の冗長的過払いの提案（ ニュースレター #372参照）などが挙げられます。

  • ● UTXOセットへのデータ埋め込みに関する理論的制限: Adam “Waxwing” Gibsonは、 Bitcoinトランザクションの制限的なルールセットの下で、 どの程度までデータをUTXOセットに埋め込むことができるかについての議論をメーリングリストで開始しました。 Gibsonが「ぞっとする」と表現する主な新ルールは、すべてのP2TRアウトプットに、 そのアウトプットが使用可能であることを証明する署名の添付を要求するというものです。 Gibsonは、任意のデータを公開鍵として偽装できるようにこのルールを回避する方法は3つしかないことを証明しようとしています:

    1. BitcoinのSchnorr署名が、 たとえば誤った仮定に基づいているなど、破綻している場合。現時点では明らかにそういうことはありません。

    2. 公開鍵のグラインドによって少量の任意のデータを埋め込むことができる場合（ つまり、多数の異なる秘密鍵を生成し、対応する公開鍵を導出し、 抽出可能な方法でエンコードされた望ましいデータを含まない公開鍵を持つ秘密鍵をすべて破棄します）。 この方法でUTXOセットに n bitの任意のデータを含めるには、 約2nの総当り計算が必要であり、アウトプットあたり数十 bit（数byte）を超える場合は非現実的です。

    3. 第三者が容易に計算できる秘密鍵を使用する場合。これは「秘密鍵の漏洩」の一種です。

    3つめのケースでは、秘密鍵の漏洩により、第三者がアウトプットを使用できるようになり、 UTXOセットからアウトプットが削除される可能性があります。しかし、このスレッドへの返信では、 Bitcoinのような洗練されたシステムではそれを回避できる可能性があると指摘されました。 Anthony Townsからの返信では、「システムを興味深い方法でプログラム可能にすれば、 データの埋め込みはほぼ即座に可能になると思います。 あとは、最適なエンコード率とトランザクションがどれだけ簡単に識別できるかのトレードオフの問題になります。 ただし、データの効率を低下させてまでデータを隠蔽しようとすると、 システムの他のユーザーが利用できるリソースが少なくなるだけで、私にはまったくメリットがないように思えます」と 付け加えられています。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Compact block harnessはCrypt-iQによるPRで、 コンパクトブロックリレーロジック用のテストハーネスを追加することで ファジングテストのカバレッジを向上させます。ファジングとは、 コードにランダムな入力を与え、バグや予期せぬ動作を発見するテスト方法です。

このPRはまた、テストハーネス実行時のパフォーマンスを向上させるために、 テスト専用の新しい-fuzzcopydatadir起動オプションも導入されています。

  • ファジングテストは、high_bandwidthをランダムに設定したSENDCMPCTメッセージを送信します。 高帯域幅ピアは何台まで許可され、ファジングハーネスはこの制限をテストしますか？ より一般的には、ピアが高帯域幅または低帯域幅を選択する理由は何ですか？

    高帯域幅ピアの場合、コンパクトブロックは通知なしで、検証が完了する前に送信されます。 これにより、ブロックの伝播速度が大幅に向上します。帯域幅のオーバーヘッドを削減するため、 ノードは高帯域幅モードでコンパクトブロックを送信するピアを最大3つまでしか選択しません。 このモードは、cmpctblockファジングターゲットでは特にテストされません。 ➚

  • ハーネスのcreate_blockを確認してください。生成されたブロックにはいくつのトランザクションが含まれ、 それらはどこから取得されるのですか？ブロック内のトランザクションが少数の場合、 どのようなコンパクトブロックのシナリオを見逃す可能性がありますか？

    生成されたブロックには1〜3個のトランザクションが含まれます。 コインベーストランザクション（常に存在）、オプションでmempoolのトランザクション、 オプションでmempoolにないトランザクションです。ブロックは少数のトランザクションに制限されているため、 トランザクションが多いと発生しやすくなるショートIDの衝突処理のテストなど、 一部のシナリオが見逃される可能性があります。Review Clubの参加者は、 カバレッジを向上させるためにトランザクション数を増やすことを提案しました。 ➚

  • コミットed813c4は、ポインタアドレスではなく ブロックハッシュでm_dirty_blockindexをソートします。これはどのような非決定性を修正するのでしょうか？ 作者は、これによりプロダクションコードの速度は低下するが、 プロダクション版のメリットはないと指摘しています。 なぜここでEnableFuzzDeterminism()を使用できないのでしょうか？ この非決定性は、（PRで現在実装されている方法以外で）どのように処理するのが最適だと思いますか？

    m_dirty_blockindexセットはポインタメモリアドレスでソートされますが、 このアドレスは実行毎に異なるため、非決定的な動作が発生します。この修正では、 代わりにブロックハッシュを使用することで、決定的なソート順序を実現します。 std::setのコンパレーターはその型のコンパイル時のプロパティであり、 実行時に切り替えることができないため、EnableFuzzDeterminism()のような実行時ソリューションは使用できません。 この非決定性は実行パスに影響を与えるため、セットへの挿入毎にファジングツールのコードカバレッジ分析を誤導します。 PRの作者は、ファジングにおけるカバレッジフィードバックの仕組みに関する参考資料として、 afl-fuzzホワイトペーパーを推奨しています。 ➚

リリースとリリース候補

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

  • ● Bitcoin Inquisition 29.1は、提案中のソフトフォークやその他の主要なプロトコル変更を実験するために設計された、 signetフルノードのリリースです。Bitcoin Core 29.1で導入された 新しい最小リレー手数料率のデフォルト（0.1 sat/vb）、 Bitcoin Core 30.0で予定されているdatacarrier制限の拡大、 OP_INTERNALKEY（ニュースレター#285および#332参照）のサポート、 新しいソフトフォークをサポートするための新しい内部インフラが含まれています。

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

最近の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 #33453は、多くのユーザーがこれらのオプションの使用継続を望んでおり、 廃止計画が不明確で、廃止を取り消すことによるデメリットが最小限であることから、 datacarrierとdatacarriersize設定オプションの廃止を取り消します。 このトピックに関する追加の文脈については、ニュースレター#352と#358をご覧ください。

  • ● Bitcoin Core #33504は、承認済みトランザクションがブロックの再編成により mempoolに再び入る際、TRUCトポロジー制限に違反していても、 TRUCチェックの実施をスキップします。これまでは、これらのチェックを実施すると多くのトランザクションが誤って排除されていました。

  • ● Core Lightning #8563は、チャネルが閉じられ忘れられた時点で古いHTLCを削除するのではなく、 ノードが再起動されるまで削除を延期します。これにより、すべてのCLNプロセスを停止させる不要な一時停止を回避し、 パフォーマンスが向上します。このPRはまた、閉じたチャネルのHTLCを除外するようにlisthtlcsを更新しています。

  • ● Core Lightning #8523は、decode RPCおよびonion_message_recvフックから 以前に非推奨とされ無効化されていたblindingフィールドを削除しました。これは、 first_path_keyに置き換えられたためです。experimental-quiesceおよび experimental-offersオプションも削除されました。これらの機能はデフォルトであるためです。

  • ● Core Lightning #8398は、試験的なBOLT12定期オファーに cancelrecurringinvoiceコマンドを追加しました。これにより支払人は、 受信者に対し、そのシリーズからのインボイス要求の受信を停止するよう通知できます。 BOLTs #1240の最新の仕様変更に合わせて、他にもいくつかの更新が行われました。

  • ● LDK #4120は、ピアが切断するかtx_abortを送信した場合、 署名フェーズの前にスプライシングのネゴシエーションが失敗した際に、 インタラクティブファンディング状態をクリアし、スプライシングをクリーンに再試行できるようにします。 ピアがtx_signaturesの交換を開始した後にtx_abortを受信した場合、 LDKはこれをプロトコルエラーとして扱い、チャネルを閉じます。

  • ● LND #10254は、Tor v2 onionサービスのサポートを廃止します。 これは、次の0.21.0リリースで削除される予定です。設定オプションtor.v2は現在非表示になっており、 ユーザーは代わりにv3を使用してください。