今週のニュースレターでは、BitcoinのP2Pネットワークにパッケージリレーを追加することについての継続的な議論の要約と、 最近のLN開発者ミーティングの概要、LN上の支払者とルーティングノードの両者にとって利益となる方法で 信頼性と低手数料の両方を最適化する方法についての議論を掲載しています。 また、最近のリリースとリリース候補の概要に加えて、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。

ニュース

• ● パッケージリレーBIPの継続的な議論: パッケージリレーに関する 最近のBIPドラフト（ニュースレター #201参照）に、ここ数週間で追加のコメントが寄せられました。

  • ● ポリシーの制限: Anthony Townsは、パッケージリレーをサポートする2つのピア間のネゴシエーションに、 各ピアのパッケージの最大サイズと深さの制限に関する情報を含めるべきかどうか尋ねました。 そうしなければ、デフォルト以外の設定のノードが、不要なパッケージについて繰り返し通知を受け取り、 帯域幅を浪費する可能性があります。BIPの作者であるGloria Zhaoは、パッケージリレープロトコルの最初のバージョンでは、 25トランザクションと101,000 vbyteの最大パッケージサイズを用いることを示唆しています。

  • ● パッケージグラフの通知のみ: Eric Voskuilは、 低手数料率の祖先について高手数料率の子孫があることを知ったピアは、 パッケージグラフと呼ばれるその2つの関係をピアに通知することを推奨しています。 受信側のピアは、自分が持っていないトランザクションを要求できます。 スレッドの別の部分でTownsは、すべてのトランザクションを受け取るまでグラフを検証することはできないので、 トランザクションが他のピアによってリレーされるのを防ぐために、 ピアがグラフについて嘘をつけないことを保証するよう注意しなければならなくなると指摘しています。

  • ● 短縮IDの使用: 複数の開発者が、BIP152スタイルの短い識別子の使用を提案しました。 Zhaoは、（作成にコストのかかる）短縮IDはノードが最初に新しいブロックのProof of Workの検証を行うブロックリレーに適しており、 攻撃者がこの仕組みを悪用してノードのリソースを消費するとコスト高になると説明しています。 しかし、作成コストの低いデータのリレーでは、短縮IDを何度も悪用するサービス拒否攻撃が発生する可能性があります。

  • ● 非標準の親 Suhas Daftuarは、 パッケージリレーを実装したノードが同じデータを繰り返し要求するシナリオについて説明しています。 これは、ソフトフォークがアクティベートされた後など、 古いノードと新しいノードでリレーポリシーが異なる場合に特に起こりやすいと思われます。

  • ● ブロックハッシュビーコンのチャンレンジ: Daftuarは、この提案のある機能が他のソフトウェアに問題を引き起こす可能性があることも指摘しています。 現在のBIPドラフトは、各パッケージの通知に各ノードのブロックチェーン上の最新ブロックのハッシュが含まれています。 これにより、受信側のピアが、以前のブロック（もしくは代替チェーン）からのパッケージを無視でき、 この場合、パッケージは受信側のピアの現在のmempoolでは動作しない可能性があります。 ただし、Daftuarは、トランザクションを送信するソフトウェアの中には、 最終的にパッケージを送信したいものや、 現在のチェーンの先頭のハッシュを追跡していないものもたくさんあると指摘しています。

• ● LN開発者ミーティングの概要: Olaoluwa Osuntokunは、 先週オークランドで行われたLNの開発者ミーティングの詳細な要約を報告しました:

  • ● TaprootベースのLNチャネル: 参加者は、 Taprootの機能を完全に利用するための最初のステップについて議論しました。 この後のステップでは、おそらくPTLC（ニュースレター #164参照）のサポートも含まれるでしょう。

  • ● TapscriptとMuSig2: Taprootベースのチャネルへの切り替えの一部として、 ブロックスペースを最も効率的に使用する方法で既存のScriptをTapscriptに変換する必要があります。 また、署名者両者が協調して行動することが期待されるすべてのケースで、 署名の作成にMuSig2を使用したいという要望もあります。 この2つは、期待通りに動作することを保証するために実装とテストが必要です。

  • ● 再帰的なMuSig2: MuSig2のシンプルな実装では、アリスとボブが共同で1つの署名を作成することができます。 再帰的なMuSig2では、たとえば、アリスが自分のホットウォレットとハードウェア署名デバイスの両方を使用して、 ボブが特別な手順を踏んだりアリスが複数の鍵で署名していることを知ることなく、署名の一部を作成することができるようになります。 再帰的なMuSig2が利用できるように、LNのMuSig2の使用をどう設計するかが議論されました。 また、再帰的なMuSig2の安全性についても議論されています。

  • ● 拡張BOLTs: LNプロトコル仕様の変更を定義するための代替手法。 現在、仕様の変更は既存の仕様に対するパッチ（差分）として作成されています。 しかし、一部の開発者は、プロトコルへの主な変更が1つ以上のドキュメントで定義されるBIPのような方法を好んでいます。 そのような開発者は、個別のドキュメントの方が書きやすく読みやすいため、開発を簡略化しスピードアップできると考えています。

  • ● ゴシップネットワークのアップデート: ミーティングではLNのゴシップのアップデート（ニュースレター #188参照）に関する既存の議論を継続しました。 要約によると、参加者は短期的にはMuSig2ベースのTaprootチャネルのサポートにフォーカスし、 またTLVセマンティクスを完全に使用するためにプロトコルをアップグレードするのが望ましいとしています。

  • ● Minisketchベースの効率的なゴシップ: ニュースレター #198に掲載したように、 ノード間のLNゴシップの同期に使用される帯域幅の量を削減するために、Minisketchを使用する研究が続けられており、 これにより、アプデートの間の最小許容時間を削減することができるかもしれません。

  • ● オニオンメッセージのDoS: いくつかのLN実装は、 メッセージングにkeysend支払いを使用する代替手段として、 また提案中のBOLT12 Offerプロトコルの通信レイヤーとして、 既にオニオンメッセージをサポートしています。 しかし、ニュースレター #190に掲載したように、 一部の開発者はオニオンメッセージがいつくかの異なる種類のDoS攻撃に対して脆弱である可能性があることを懸念しています。 DoS攻撃を防ぐためのいくつかの方法が議論されました。

  • ● ブラインドパス: 数年前に提案され（ニュースレター #85参照）現在オニオンメッセージに使用されている技術は、 ユーザーがLNノードの身元を明かすことなく支払いを受けられるようにするため、 通常の支払いへの使用も実験されています。この方法の課題は、 より多くのルーティング情報を通信する必要があるため、より大きなインボイスが必要になることです。 そのため、ブラインドパスの効果的な実装はBOLT12 OfferやLNURLなどの新しいインボイス管理プロトコルに依存することになるかもしれません。 その他、いくつかの懸念事項についても議論されました。

  • ● 証明と残高の共有: さまざまなテクニックを使用して、 ノードがネットワーク上のチャネルの残高を証明することが可能です。 このような証明は、証明を行うノードにとっては事実上無料ですが、ネットワークの一般ユーザーにとっては、 プライバシーを損なうだけでなく問題を引き起こす可能性があります。 個別のチャネルジャミング攻撃に対する緩和策は、 証明を制限するのに役立つかもしれませんが、現時点ではまだ懸念が残っています。 そこで参加者は、証明をより困難にする可能性のあるノード設定のいくつかの迅速な変更について議論しました。

    さらに、以前議論された思考実験として、 証明するノードが知るであろう情報を、証明を必要とせずに自由に共有できるようになったとします。 もし、すべてのノードがこれを行えば、帯域幅の要件とプライバシーの喪失によりLNの重要なメリットは失われますが、 ルーティング支払いははるかに効率化されます。誰もこのアイディアを提案しませんが、 以前の研究トピックでは、各ノードが証明によって知ることができる情報の一部を、 その直接のピアとだけ共有することが議論されました。 これにより、Just-In-Time (JIT)チャネルリバランスを補完するなど、 支払いのルーティングの成功率を大幅に改善できると主張されました。

  • ● トランポリンルーティングとモバイルの支払い: トランポリンルーティングは、 送信者がネットワーク上の別のノードに経路探索をアウトソースすることを可能にします。 オプションとして、 送信者または受信者のいずれかのネットワークの身元を中間ノードが知るのを防ぐというLNの通常のプライバシーを維持できます。 このアウトソーシングは、他のノードへの他の支払いをルーティングしないモバイルLNクライアントにとって特に有用です。 ミーティングの要約に記載したように、トランポリン支払いは、 最初のホップによる支払いの保留（ニュースレター #171参照）と組み合わせることができ、 受信ノードが次にオンラインになるまで支払いが支払い者の直接のチャネルピアによって保留され、 頻繁にオフラインになるモバイルノードが別の頻繁にオフラインになるモバイルノードからの支払いを確実に受け取ることができるようになります。

  • ● LNURL＋BOLT12: LNURLプロトコルを使用すると ノードはWebサーバーにBOLT11インボイスを要求することができます。 BOLT12 Offerプロトコルを使用すると、ネットワーク上のノードにインボイスを要求できます。 これらのプロトコルの別の側面として、参加者は、ノードがどちらか、 もしくは両方を使用できるように、2つのプロトコルを相互に互換性を持たせる方法について議論しました。

• ● ルーティング手数料を使用した流動性のシグナル: 開発者ZmnSCPxjは、 送信者とルーティングノードとの間のゲーム理論的な行動によって、 最適で安価で信頼性の高い支払いを得る方法についての議論を、Lightning-Devメーリングリストに投稿しました:

  • 送信者はルーティング手数料がより少ない経路を選択すべきです。

  • ルーティングノードはチャネルのキャパシティが減少するにつれて、そのチャネルの使用に多くの手数料を請求する必要があります。 たとえば、チャネル残高のほとんどがアリスによって所有されている場合、 アリスはボブへの支払いの転送を確実にできるので、手数料をあまり請求する必要はありません。 しかし、多くの残高がボブに転送されると、アリスのその後の支払いを転送する能力が低下するため、 より高めの手数料を請求する必要があります。

  ZmnSCPxjは、この議論を需要と供給の経済学で組み立てています。 たとえば、アリスからボブへというように、ある方向に支払いを転送する需要が高まると、 その方向に転送できるその後のsatoshiの量は当然減少します。ルーティング手数料の価格を上げると、 他の方向（たとえばボブからアリス）へのルーティング支払いによって供給が再び増加するまで、需要を減少させることができます。

  送信者は既に手数料の低いもの（他のすべての条件が同じで）を使用するよう自然と動機付けられているので、 ZmnSCPxjは、高供給/低手数料と低供給/高手数料の戦略を選択するルーティングノードは、 自動的にそのチャネルの残高を適度に保ち、 この戦略を採用しないノードよりもそのチャネルのライフタイムにより、より多くの支払いを処理できるようになると主張しています。 ルーティングノードは支払いが成功した場合にのみ手数料を得るため、高-低/低-高 戦略を採用するノードはより競争力がある可能性があります。

  このアプローチの主な利点は、送信者が経路探索をとても簡単に行えることです。 送信者は、キャパシティの範囲内で、最も安い経路に沿って支払いを試みるだけです。 欠点は、高-低/低-高 戦略でルーティングノードの手数料を変更することは、チャネルの残高の変更を意味し、 最近そのチャネルを通過した可能性のある支払いのサイズに関する情報が明らかになることです。 たとえば、アリス→ボブ、ボブ→キャロル、キャロル→ダンの各チャネルのキャパシティが最近1 BTCほど減少した場合、 アリスかそのチャネルパートナーのいずれかが、ダンまたはそのチャネルパートナーに1 BTCの支払いをルーティングしたと推測するのが妥当です。 さらなる問題は、チャネルの手数料の各変更がネットワーク上でゴシップされる必要があることです。 これは帯域幅要件を増加させ、また誤ったルーティングの失敗を引き起こす可能性があります（たとえば、 送信者のサリーは、アリスの高くなった新しい手数料について聞いていないため、 アリスからボブへのチャネルでアリスが拒否する古い低手数料で支払いをルーティングしようとします）。

  ZmnSCPxjは、LNプロトコルに変更を加えることなくノードが現在実装できるものや、 LNゴシッププロトコルに小さなアップデートを必要とするものなど、いくつかの緩和策を説明してこれらの問題に対処しています。 説明されている緩和策は、この記事の執筆時点ではメーリングリスト上では議論されていませんが、 Olaoluwa OsuntokunのLN開発者ミーティングの要約（前の箇条書きでOptechによってさらに要約されています）には掲載されています。

リリースとリリース候補

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

• ● LND 0.15.0-beta.rc6は、この人気のある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 Core #24171は、Initial Block Download (IBD)の動作を変更し、 アウトバウンドピアがブロックデータを提供しない場合にインバウンドピアにブロックデータを要求するようになりました。 これまでは、ノードがアウトバウンドピアを持っていない場合のみ、インバウンドピアにデータを要求していました。 この動作はノードがブロックを提供しないアウトバウンドピアしか持っていない場合に、動作しなくなる原因になることがありました。 ノードはアウトバウンドピアがブロックを提供し始めるようになると、アウトバウンドピアに対してのみデータを要求するようになります。

• ● BDK #593は、 TaprootおよびOutput Script Descriptorのサポートを含むRust Bitcoin 0.28を使用するようになりました。