今週のニュースレターでは、ノードがフルRBFを有効にするオプションについての継続的な議論と、 BIP324のバージョン2暗号化トランスポートプロトコルの設計要素に関するフィードバックの要求、 LNの障害と遅延を特定のノードに確実に帰すための提案、 最新のLNのHTLCのアンカーアウトプットを使用する代替案に関する議論のリンクを掲載しています。 また、LNDのセキュリティクリティカルなアップデートを含む、新しいソフトウェアリリースとリリース候補の発表や、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

  • ● mempoolの一貫性: Anthony Townsは、 Bitcoin Coreの開発ブランチにmempoolfullrbfオプションを追加することで行われたような（ニュースレター#205、 #208、#222および#223参照）、 トランザクションのリレーとmempoolの受け入れに関するBitcoin Coreのポリシーを構成しやすくすることの結果について Bitcoin-Devメーリングリストで議論を始めました。 彼は、「これはCoreが過去に行ったこととは異なる。以前は、新しいポリシーは誰にとっても良いものであることを （あるいは、できるだけそうなるように）確認しようとし、それが実装されるとすぐに有効にしてきた。 追加されたオプションはいずれも、Txの伝播に大きく影響しない方法でリソースの使用を制限するためのもので、 新しい動作が物議を醸す際に利用者が従来の動作に戻すため（たとえば、0.12から0.18までの-mempoolreplacement=0オプションなど）、 また実装のテストやデバッグを簡単にするためのものだった。デフォルトでオンにする自信がないのに、 オプトイン可能な新しいリレー動作を提供するのは、私が過去に見たCoreのアプローチとは一致しない。」と主張しました。

    Townsは次に、これが開発の新しい方向性かどうかを考えています: 「フルRBFは長い間議論の的だったが、開発者には広く好まれている。[…]そのため、 これは単に特殊ケースで、前例はないのかもしれない。人々が他の誤ったデフォルトオプションを提案すると、 ユーザーにはオプションがあるという現在進行中の議論があるにも関わらず、それがマージされることに対して大きな抵抗があるだろう。」 しかし、それが新しい方向性であると仮定して、その決定がもたらすいくつかの潜在的な結果を評価しています:

    • ● デフォルトで無効化されたオプションをマージする方が簡単なはず: もしユーザーに多くのオプションを与えることが良いのであれば、リレーポリシーの多くの側面を設定可能にすることができます。 たとえば、Bitcoin Knotsでは、アドレスの再利用をするトランザクションのリレーを拒否するように ノードに設定するspkreuse（script pubkey reuse）オプションが提供されています。

    • ● より寛容なポリシーは、広く受け入れられるか、より良いピアリングを必要とする: Bitcoin Coreノードはアウトバウンド接続を介してデフォルトで8つのピアとトランザクションをリレーします。 そのため、ノードが同じポリシーをサポートする少なくとも1つのランダムに選択されたピアを見つける可能性が95%になる前に、 ネットワークの少なくとも30%がより寛容なポリシーをサポートする必要があります。 ポリシーをサポートするノードが少ないほど、ノードがそのポリシーをサポートするピアを見つける可能性は低くなります。

    • ● 良いピアリングにはトレードオフがある: Bitcoinノードは、P2Pでaddr、addrv2およびversionメッセージのservicesフィールドを使用して 自身の機能を通知することができ、共通の関心を持つノードが互いを見つけて（優先ピアリングと呼ばれる）サブネットワークを形成することができます。 また、共通の関心を持つフルノードのオペレーターは、 他のソフトウェアを使用して独自のリレーネットワーク（LNノード間のネットワークなど）を形成することもできます。 これにより、ポリシーを実装するノードが少数でも効果的にリレーすることができますが、 希少なポリシーを実装しているノードは特定されやすく、検閲もしやすくなります。 また、マイナーはこれらのサブネットワークや代替ネットワークに参加する必要があり、 マイニングの複雑さやコストが増加します。そのため、トランザクション選択の一元化のプレッシャーが高まり、 これも検閲を容易にします。

      さらに、一部のピアと異なるポリシーを実装しているノードは、 2つのピアが既に同じ情報のいくつかを保持している場合に、レイテンシーや帯域幅を最小化する Compact Block Relayやerlayなどの技術を十分に活用できなくなります。

    Townsの投稿には、洞察力に富んだ複数の反応が寄せられており、この記事の執筆時点で議論が続いています。 来週のニュースレターで最新情報をお伝えする予定です。

  • ● BIP324のメッセージ識別子: Pieter Wuilleは、Bitcoin-Devメーリングリストに バージョン2 P2P暗号化トランスポートプロトコル (v2 transport) のBIP324ドラフト仕様のアップデートに対する返答を投稿しました。 帯域幅を削減するために、v2トランスポートでは既存のプロトコルの12バイトのメッセージ名を1バイトの短い識別子に置き換えるようにします。 たとえば、12バイトにパディングされるversionというメッセージ名は、0x00に置き換えられます。 しかし、メッセージ名を短くすると、将来ネットワークにメッセージを追加する際に、異なる提案で衝突が発生するリスクが高くなります。 Wuilleは、この問題に対処するための4つの異なるアプローチのトレードオフを説明し、このテーマについてコミュニティの意見を求めています。

  • ● LNのルーティング失敗の属性: LN支払いの試行は、最終的に受信者がペイメントプリイメージのリリースを拒否したり、 ルーティングノードの1つが一時的にオフラインになるなど、さまざまな理由で失敗に終わることがあります。 どのノードによって支払いが失敗したかという情報は、送信者が近い将来の支払いでそのノードを避けるのにとても有益な情報ですが、 現在のLNプロトコルは、ルーティングノードがその情報を送信者に伝えるための認証方法を提供していません。

    数年前、Joost Jagerが解決策を提案し（ニュースレター #51参照）、 彼はそれを改良し詳細を追加して更新しました。 この仕組みでは、支払いが失敗したノードのペア（または前の失敗のメッセージを検閲または文字化けされたノードのペア）を確実に識別することができます。 Jagerの提案の主な欠点は、他のLNの特性が同じままであれば、失敗のオニオンメッセージのサイズが大幅に増加することです。 ただし、LNの最大ホップ数を減らせば、失敗のオニオンメッセージのサイズはそれほど大きくする必要はないでしょう。

    代わりに、Rusty Russellは、最終的な支払いが失敗した場合でも 各ルーティングノードに1 sat支払われるSpontaneous Paymentに似た仕組みを使用する提案を行いました。 送信者は、送信したsatoshiの量と戻ってきたsatoshiの量を比較することで、どのホップで支払いが失敗したかを特定することができます。

  • ● アンカーアウトプットの回避策: Bastien Teinturierは、 アンカーアウトプットを、異なる手数料率が設定されたHTLCの複数の事前署名バージョンに置き換える提案を Lightning-Devメーリングリストに投稿しました。 アンカーアウトプットは、LNの2者間のコントラクトプロトコルで固定できない方法で、 CPFPの仕組みを使用してトランザクションに手数料を追加することを可能にするCPFP carve-outルールの開発と共に導入されました。 しかし、Teinturierは、CPFPを使用するには、各LNノードが非LNのUTXOをいつでも使用できるようプールしておく必要があると指摘しています。 それと比べて、手数料が異なる複数のバージョンのHTLCに事前署名しておけば、手数料をHTLCの値から直接支払うことができ、 追加のUTXO管理は必要ありません。

    彼は、他のLN開発者に複数の手数料率のHTLCに移行するためのアイディアへの支持を求めています。 この記事を書いている時点では、すべての議論はTeinturierのPRで行われています。

リリースとリリース候補

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

  • ● LND 0.15.4-betaおよび0.14.4-betaは、 最近のブロックの処理の問題に関するバグ修正を含むセキュリティクリティカルなリリースです。 すべてのユーザーにアップグレードが必要です。

  • ● Bitcoin Core 24.0 RC2は、ネットワークで最も広く使われているフルノード実装の次期バージョンのリリース候補です。 テストのガイドが利用できるようになっています。

    警告: このリリース候補には、mempoolfullrbf設定オプションが含まれており、 いくつかのプロトコルやアプリケーション開発者は、ニュースレター#222および#223で説明したように、 マーチャントサービスに対して問題を引き起こす可能性があると考えています。 Optechは、影響を受ける可能性のあるサービスに対して、RCを評価し、公開討論に参加することを推奨しています。

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

今週の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 #23927は、プルーニングされたピアでのgetblockfrompeerを、 ノードの現在の同期進捗以下の高さに制限します。 これは、将来のブロックを取得することで、ノードのブロックファイルがプルーニングの対象外になるのを防止します。

    Bitcoin Coreは、約130MBのファイルにブロックを受信した順に格納します。 プルーニングはブロックファイル全体を廃棄しますが、同期処理されていないブロックを含むファイルは廃棄しません。 データ容量の小ささとgetblockfrompeerRPCの繰り返しの組み合わせにより、 複数のブロックファイルがプルーニングの対象外になり、プルーニングノードが許可されたデータ量を超える原因になる可能性があります。

  • ● Bitcoin Core #25957は、ウォレットに関連するUTXOを使用したり作成したりしないブロックをスキップするために、 （有効になっている場合に）Block Filter Indexを使用することで、 ディスクリプターウォレットの再スキャンのパフォーマンスを向上します。

  • ● Bitcoin Core #23578は、HWIと最近マージされたBIP371のサポート（ニュースレター #207）を使用して、 Taprootのkeypath支払いに対する外部署名のサポートを可能にしました。

  • ● Core Lightning #5646は、実験的なOfferのサポートを更新し、 x-only public keyを削除しました（代わりに余分な1バイトを含む圧縮公開鍵を使用します）。 また、別の実験的なプロトコルであるブラインドペイメントの転送も実装しています。 PRの説明では、「ブラインドペイメントのインボイスの生成や実際の支払いは含まれない」と警告しています。

  • ● LND #6517では、新しいRPCとイベントが追加され、 ユーザーは新しいチャネル残高の分配を反映するためにコミットメントトランザクションが更新されることで、 入ってくる支払い（HTLC）が完全にロックされた際に監視できるようになります。

  • ● LND #7001は、転送履歴のRPC（fwdinghistory）に新しいフィールドを追加し、 どのチャネルパートナーが自分に支払い（HTLCが）を転送したかと、自分が支払いをリレーしたパートナーを表示します。

  • ● LND #6831は、HTLCのインターセプターの実装（ニュースレター #104参照）を更新し、 インターセプターに接続されたクライアントが妥当な時間内に支払いの処理を完了しなかった場合に、 自動的に受信した支払い（HTLC）を拒否します。有効期限が近づく前にHTLCが承認または拒否されない場合、 チャネルパートナーは自身の資金を保護するためにチャネルを強制クローズする必要があります。 このマージされたPRの自動拒否は、チャネルを開いたままにすることを保証します。送信者はいつでも再び支払いの送信を試せます。