今週のニュースレターでは、Schnorr署名のハーフアグリゲーションや、 x-only pubkeyを確実に使用できないプロトコルに対する回避策、 LN支払いの転送を意図的に遅くすることについての議論を掲載しています。 また、Bitcoin Core PR Review Clubの概要や、リリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点など、 恒例のセクションも含まれています。

ニュース

  • ● BIP340署名のハーフアグリゲーション: Jonas Nickは、 Bitcoin-Devメーリングリストに、 BitcoinのSchnorr署名のハーフアグリゲーションに関するBIPドラフトと ブログ記事を投稿しました。 プログの記事で言及されているように、この提案は、 「複数の署名を集約して、個々の署名の合計の約半分の長さの単一の署名にすることができます。 重要なのは、この方式が非対話型であることです。 つまり、署名者が関与することなく、第三者によって署名のセットをハーフアグリゲーションすることができるのです。」

    別のドキュメントでは、 ハーフアグリゲーションがBitcoinとLNノードのオペレーターにどんな利益をもたらすかの例や、 コンセンサスプロトコルにハーフアグリゲーションを追加するソフトフォークの設計で考慮する必要があるいくつかの懸念事項が示されています。

  • ● x-onlyの回避策: Bitcoinの公開鍵は、 x座標とy座標の交点として参照される2次元グラフ上の点です。 任意のx座標に対して、有効なy座標は2つしかなく、これらはxの値から計算できます。 このため、Taprootの設計では、 BIP340形式のSchnorr署名で使用されるすべての公開鍵は、 2つのy座標のうち特定の1つだけを使用することを要求する最適化が行われ、 トランザクションに含まれる公開鍵はy座標を完全に省略できるようになり、 オリジナルのTaprootの設計より署名毎に1 vbyteの節約が可能になりました。

    当時、（x-only public keyと呼ばれる）この手法は、 大きなトレードオフのない最適化と考えられていましたが、 その後のOP_TAPLEAF_UPDATE_VERIFY（TLUV）の設計作業により、 x-only pubkeyでは提案に計算上の制限、 もしくはブロックチェーンまたはUTXOセット内に余分なデータを保存する必要があることが判明しました。 この問題は、公開鍵の他の高度な使用法にも影響を与える可能性があります。

    今週、Tim Ruffingは、Bitcoin-Devメーリングリストに、 署名者によるわずかな追加計算を必要とする回避策の可能性を投稿しました。 リソースに制約のあるハードウェア署名デバイスでも、ユーザーをあまり待たせずに実行できる可能性のあるものです。

  • ● 意図的に遅いLN支払いの転送を許可する: 再帰的/ネストされた MuSig2（ニュースレター #204参照）と、 それを使用するノードが支払いのルーティング時に追加する遅延に関するスレッドへの返信で、 開発者のPeter Toddは、Lightning-Devメーリングリストに、 「プライバシーのために、よりゆっくりと行われる支払いに人々がオプトインできるようにすることは価値はありますか？」 と尋ねました。たとえば、アリスとボブがそれぞれ、 ほぼ同時期にキャロルの転送ノードを介してダンの転送ノードにゆっくりと支払いを転送した場合、 キャロルは両方の支払いをまとめて転送することができ、 第三者が残高調査やネットワーク活動の監視などを通じて発見可能な参加者のプライバシー漏洩の情報量を減らすことができます。 開発者のMatt Coralloは、興味深いアイディアであると同意しました。

Bitcoin Core PR Review Club

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

Manual block-relay-only connections with addnodeは、 Martin ZumsandeによるPRで、 ブロックのみをリレーする（トランザクションやピアのアドレスはリレーしない）ノードと手動で接続できるようにします。 このオプションは、特にTorなどのプライバシーネットワーク上で動作するノードに対して、 エクリプス攻撃を防止するのに役立ちます。

  • クリアネットのみのピアと比較して、Torなどのプライバシーネットワークでのみアクティブなピアは、 なぜエクリプス攻撃の影響を受けやすいのですか？

    クリアネット上のノードは、IPアドレスのネットワークグループなどの情報を使って、 「多様な」ピアを選択しようとすることができます。一方、onionアドレスのセットが、 すべて単一の攻撃者に属しているかどうかを見分けるのは難しいため、Tor上ではそれが困難です。 また、Tor上で動作するBitcoinノードの数はとても多いですが、 Bitcoinノードの数が僅かなプライバシーネットワーク上で-onlynetを使用しているノードは、ピアの選択肢があまりないため、 簡単にエクリプス攻撃にさらされます。 ➚

  • addnode RPCのonetryモードとaddモードの違いは何ですか？

    その名前が示すように、onetryはCConnman::OpenNetworkConnection()を一度だけ呼ぼうとします。 失敗した場合、ピアは追加されません。一方、addモードでは、 成功するまで繰り返しノードへの接続を試みます。 ➚

  • このPRでは、MANUALピアとBLOCK_RELAYピアの特性を組み合わせた新しい接続タイプMANUAL_BLOCK_RELAYを導入しています。 既存の接続タイプのロジックを組み合わせるのではなく、追加の接続タイプを持つことの利点と欠点は何ですか？

    P2P接続には多くの属性がありますが、タイプは少ないため、 参加者はフラットな列挙型で接続タイプを使用する方がよりシンプルであることに同意しました。 また、機能と権限の組み合わせで接続を定義すると、 意味をなさないものも含め、接続タイプとロジックの組み合わせが膨大になる可能性についても言及されました。 ➚

  • このPRが軽減しようとする攻撃のうち、BIP324によって修正されるのはどのような攻撃ですか？ また、そうでないものは何ですか？

    BIP324は、盗聴やネットワーク全体の監視を防ぐための暗号化を追加することでプライバシーを強化しますが、 エクリプス攻撃を防ぐためのものではありません。何らかの認証の仕組みがあったとしても、 ピアが正直か、他のピアと異なるものかを識別する助けにはなりません。 ➚

リリースとリリース候補

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

  • ● BTCPay Server 1.6.1は、 この人気のセルフホスト型のペイメントプロセッサソリューションの1.6ブランチのリリースで、 複数の新しい機能とバグ修正が含まれています。

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

今週のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、およびLightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core #25353は、以前ニュースレター #205で説明した mempoolfullrbf設定オプションを導入しました。 このオプションにより、ノードオペレーターは、ノードのトランザクション置換動作を デフォルトのオプトインRBF (BIP125)から、 シグナリング要件を強制することなくノードのmempoolのトランザクションの置換を許可するフルRBFに切り替えることができますが、 オプトインRBFと同じ経済ルールに従います。

  • ● Bitcoin Core #25454では、同じピアへの複数のgetheadersメッセージの送信を回避します。 前のgetheadersメッセージに対する応答を最大2分間待ってから新しいメッセージを発行することで、 帯域幅の使用量を削減します。

  • ● Core Lightning #5239は、CLNのゴシップレート制限を満たす通知のみをリレーするものの、 受信したすべての通知を使用して支払いリレーネットワークのCLNの内部マップを更新するようゴシップ処理コードを改善しました。 これまでは、CLNはレート制限に従って受信メッセージをドロップしていました。 この変更により、CLNがピアに送信するデータ量に影響を与えることなく、 ピアのレート制限がゆるい（もしくはまったくない）場合に、CLNにネットワークのより良いビューを提供できます。

  • ● Core Lightning #5275は、ゼロ承認チャネルの開設と、 それに関連するShort Channel IDentifier (SCID)エイリアス（ニュースレター #203参照）のサポートを追加しました。 これには、listpeersRPC、fundchannelRPC、multifundchannelRPCの更新が含まれています。

  • ● LND #5955は、上記のマージと同様に、ゼロ承認チャネルの開設と、関連するSCIDエイリアスのサポートを追加しています。

  • ● LDK #1567は、近い将来に支払いが送信された場合に、 どの支払いルートが成功する可能性が高いかテストするのに使用できる 基本的な支払い探索APIのサポートを追加しました。 これには、送信ノードが余分な状態を保存することなく、戻ってきた際に、 実際の支払いHTLCからHTLCを分離可能にする方法でHTLCを構築するサポートが含まれています。

  • ● LDK #1589は、LDKのメンテナーにセキュリティの脆弱性を安全に報告するために使用できる セキュリティポリシーを追加しました。

  • ● BTCPay Server #3922は、カストディアンアカウント用の基本的なUIを追加しました。 このアカウントは、（ローカルユーザーが自身の秘密鍵をコントロールするのではなく）Bitcoinの取引所のような 管理者によって資金が管理されるBTCPayインスタンスに関連付けられたアカウントです。 BTCPayインスタンスは、ローカルウォレットとカストディアンアカウントの両方を持つことができ、 両者の資金を簡単に管理することができます。たとえば、 マーチャントはプライベートかつ安全に彼らのウォレットに資金を受け取ったり、 販売するために取引所に迅速に資金を転送することが可能になります。

  • ● BDK #634は、特定の高さにある最良のブロックチェーン上のブロックのヘッダーハッシュを返す get_block_hashメソッドを追加しました。

  • ● BDK #614は、100承認未満のマイナーのコインベーストランザクションのアウトプットである 未成熟なコインベースアウトプットを使用するトランザクションの作成を回避します。