今週のニュースレターでは、LNのスプライシングに関する議論と、 推奨されるトランザクションの用語のためのBIP提案を掲載しています。 また、Bitcoin Core PR Review Clubのミーティングの概要や、 新しいリリースやリリース候補の発表（libsecp256k1のセキュリティアップデートを含む）、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点など、 恒例のセクションも含まれています。

ニュース

• ● スプライシングの仕様に関する議論: LNの開発者たちは、オフチェーンのLNチャネルの資金の一部をオンチェーンで使用したり（スプライス・アウト）、 オンチェーンの資金をオフチェーンのチャネルに追加したり（スプライス・イン）できるようにする スプライシングのドラフト仕様の進行状況について、 今週Lightning-Devメーリングリストに投稿しました。 オンチェーンのスプライシング・トランザクションが十分な承認数を待つ間も、 チャネルは継続して動作します。

  

  今週の議論は次のようなものでした:

  • ● どのコミットメント署名を送信するか: スプライスが作成されると、ノードは、保留中のすべてのスプライスに対して、 元のファンディング・アウトプットから支払いするものと新しいファンディング・アウトプットから支払うものの両方を含む 並列のコミットメント・トランザクションを保持することになります。 チャネルの状態が更新されるたびに、すべての並列コミットメント・トランザクションを更新する必要があります。 これを処理する簡単な方法は、個々のコミットメント・トランザクションに対して送信されるのと同じメッセージを、 並列コミットメント・トランザクションごとに繰り返し送信する方法です。

    スプライシングの最初のドラフト仕様ではそうなっていました（ニュースレター#17および#146参照）。しかし、今週Lisa Neigutが説明したように、 新しいスプライスの作成には、新しい派生コミットメント・トランザクションに署名する必要があります。 現在のドラフト仕様では、どのような署名でも送信すると、 他のすべての現在のコミットメント・トランザクションの署名も送信する必要があります。 これは冗長で、他のコミットメント・トランザクションの署名はすでに送信されています。 さらに、現在のLNプロトコルで、相手から署名を受け取ったことを確認する方法は、 前のコミットメント・トランザクションの失効ポイントを送信することです。 ここでも、その情報はすでに送信されています。署名と古い失効ポイントを再送することは問題ではありませんが、 余分な帯域幅と処理が必要になります。すべてのケースで同じ操作を実行することの利点は、 仕様をシンプルに保つことで、実装やテストの複雑さを減らすことができることです。

    代替案は、新しいスプライスが交渉されたときに、新しいコミットメント・トランザクションに必要な最少数の署名と、 それらが受信されたという確認の応答のみを送信する特別なケースです。 これは多少複雑さが増しますが、非常に効率的です。LNノードは、 スプライス・トランザクションが両者が安全だと判断するのに十分な深さまで承認されるまで、 並列コミットメント・トランザクションを管理するだけでいいというのは注目に値します。 その後、LNノードは単一のコミットメントの運用に戻ることができます。

  • ● 相対量とゼロ承認のスプライス: Bastien Teinturierは、いくつかの仕様の更新案について投稿しました。 前述のコミットメントの署名の変更に加えて、相対量を使用するスプライスの提案を推奨しています。 たとえば、「200,000 sat」はアリスがスプライス・インしたい金額を示し、 「-50,000 sat」はアリスがスプライス・アウトしたい金額を示します。 彼はまた、ゼロ承認のスプライシングに関する懸念も提起していますが、 それについて詳細は述べていません。

• ● トランザクション用語のためのBIP提案: Mark “Murch” Erhardtは、 トランザクションのパーツやそれらに関する概念を参照するために使用する用語を提案する情報BIPのドラフトを Bitcoin-Devメーリングリストに投稿しました。 この記事を書いている時点で、この提案に対するすべての返信が取り組みを支持していました。

Bitcoin Core PR Review Club

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

Don’t download witnesses for assumed-valid blocks when running in prune modeは、 Niklas Gögge (dergoegge)によるPRで、ブロックデータの剪定と assumevalidの両方を使用するノードで、 witnessデータをダウンロードしなないようにすることで初期ブロックダウンロード（IBD）のパフォーマンスを向上させます。 この最適化は、最近stack exchangeの質問で議論されたものです。

• assume-validは有効で剪定はしていない場合、ノードがチェックしない（最近のものではない）witnessデータをダウンロードする必要があるのはなぜですか？ この非剪定ケースでも、このPRはwitnessのダウンロードを無効にするべきですか？

  ピアが（非剪定ノードとして自身を通知している）ノードに以前のブロックを要求する可能性があるため、 これらのwitnessデータは必要です。 ➚

• IBD中のこの改善によってどれくらいの帯域幅が削減されますか？ つまり、最近のブロック（たとえば高さ781213）までの全witnessデータの累積サイズはどれくらいですか？

  110.6 GBで、全ブロックデータの約25%になります。ある参加者は、 110 GBというのは彼の月間ISPダウンロード制限の約10%なので、これはかなりの削減率だと指摘しました。 参加者はまた、最近のwitnessデータの使用の拡大により、削減率がさらに高まると予想しています。 ➚

• この改善により、ジェネシスブロックまですべてのブロックでダウンロードするデータ量が減りますか？

  いいえ。segwit有効化（ブロック高481824）以降のデータのみです。segwit前のブロックにはwitnessデータがありません。 ➚

• このPRでは、ブロックの要求ロジックとブロックの検証ロジックの2つの主な変更が実装されています。 これらの変更点の詳細について教えてください。

  検証では、スクリプトのチェックをスキップする際、witnessのマークルツリーのチェックもスキップされます。 ブロックの要求ロジックでは、フェッチフラグからMSG_WITNESS_FLAGを削除し、 ピアがwitnessデータを送信しないようにします。 ➚

• このPRがない場合、assume-validではスクリプトの検証がスキップされますが、 witnessデータを含む他のチェックはスキップされません。 このPRによってスキップされるようになるこれらのチェックは何ですか？

  コインベースのマークルルート、witnessのサイズ、witnessスタックアイテムの最大数およびブロックweightです。 ➚

• PRには、前の質問で述べた追加のチェックをスキップするための明示的なコード変更が含まれていません。なぜそれがうまくいくのですか？

  witnessデータを持っていない場合、すべての追加のチェックがパスすることがわかりました。 これはsegwitがソフトフォークだったことを考慮すると、理にかなっています。 PRによって、（assume-validのポイントまで）segwit以前のノードであるかのように装っているだけです。 ➚

リリースとリリース候補

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

• ● Libsecp256k1 0.3.1は、Clangバージョン14以上でコンパイルした場合に、 定数時間で実行されるべきコードが定数時間で実行されない問題を修正したセキュリティリリースです。 この脆弱性により、影響を受けるアプリケーションはタイミングサイドチャネル攻撃を受けやすくなる可能性があります。 著者は影響を受けるアプリケーションを更新することを強くお勧めします。

• ● BDK 1.0.0-alpha.0は、ニュースレター #243で紹介したBDKの主な変更のテストリリースです。 BDKの下流プロジェクトの開発者は、統合テストを開始することが奨励されます。

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

今週の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の注目すべき変更点。

• ● Core Lightning #6012では、CLNプラグインを作成するためのPythonライブラリ（ ニュースレター #26参照）に、CLNのゴシップストアとより良く連携するためのいくつかの重要な改善が実装されています。 この変更により、ゴシップのより良い分析ツールを構築することができ、 ゴシップデータを使用するプラグインの開発がより簡単になります。

• ● Core Lightning #6124では、commandoでruneをブラックリスト化し、 すべてのruneのリストを保持する機能が追加されました。これは、侵害されたruneを追跡し、無効化するのに役立ちます。

• ● Eclair #2607は、ノードが受け取ったすべての支払いを一覧表示する新しいlistreceivedpaymentsRPCを追加しました。

• ● LND #7437は、1つのチャネルだけをファイルにバックアップするためのサポートを追加しました。

• ● LND #7069では、クライアントがウォッチタワーに セッションの削除を要求するメッセージを送信できるようになりました。 これにより、ウォッチタワーは、失効された状態でチャネルを閉じるオンチェーントランザクションの監視を停止することができます。 これにより、ウォッチタワーとクライアント両方のストレージとCPU要件が軽減されます。

• ● BIPs #1372は、Taprootや その他のBIP340互換のSchnorr署名システムで使用できる マルチシグを作成するためのMuSig2プロトコルにBIP327を割り当てました。 BIPで説明されているように、非対話型の鍵集約と、署名の完成が2ラウンドの通信のみで行えるのが利点です。 参加者間の追加設定により、非対話型の署名も可能です。このプロトコルは、参加者とネットワークのユーザー双方にとって、 オンチェーンデータの大幅な削減やプライバシーの強化など、あらゆるマルチシグ方式の利点と互換性があります。