今週のニュースレターでは、最近のLN開発者会議で議論されたいくつかのトピックの概要を紹介します。 また、人気のあるクライアントやサービスの変更や、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

  • ● LN Summit 2024ノート: Olaoluwa Osuntokunは、 最近のLN開発者会議のメモの要約（追加のコメント付き）を Delving Bitcoinに投稿しました。

    • ● バージョン3コミットメントトランザクション: 開発者は、 TRUCトランザクションやP2Aアウトプットを含む 新しいP2P機能を使用して、チャネルを一方的に閉鎖するために使用できるLNのコミットメントトランザクションの セキュリティを向上させる方法について議論しました。議論は、さまざまな設計上のトレードオフに焦点が当てられました。

    • ● PTLC: LNのプライバシーのアップグレードとして、 またスタックレストランザクションのような他の目的にも有用であると 長い間提案されてきましたが、さまざまなPTLC実装のトレードオフに関する最近の研究が議論されました （ニュースレター #268参照）。特に焦点が当てられたのは、 署名アダプターの構成（スクリプト化されたマルチシグを使用するか、 スクリプトレスなMuSig2を使用するかなど）と、 それがコミットメントプロトコルに与える影響についてでした（次の項目参照）。

    • ● ステート更新プロトコル: LNの現在のステート更新プロトコルを、どちらの側からもいつでも更新を提案できるようにするのではなく、 一度に一方からのみ更新を提案できるようにするという提案（ニュースレター#120および #261参照）が議論されました。どちらの側からも更新を提案できるようにすると、 両者が同時に更新を提案する可能性があり、これは判断が難しく、偶発的なチャネルの強制閉鎖につながる可能性があります。 代替案は、一度に一方のみが担当する方式です。たとえば、最初はアリスだけがステートの更新を提案できるようにし、 提案がない場合は、ボブに担当を移すことができます。ボブが更新の提案を終えたら、アリスに担当を戻すことができます。 これによりプロトコルの判断が簡単になり、同時提案の問題が解消され、 非担当者が望まない提案を簡単に拒否できるようになります。この新しいラウンドベースのプロトコルは、 MuSig2ベースの署名アダプターとも相性が良いでしょう。

    • ● SuperScalar: エンドユーザー向けに提案されたチャネルファクトリー構成の開発者が、提案のプレゼンを行い、フィードバックを募りました。 Optechは、今後のニュースレターでSuperScalarの詳細な説明を公開する予定です。

    • ● ゴシップのアップグレード: 開発者は、 LNのゴシッププロトコルのアップグレードについて議論しました。 これは、Simple Taproot Channelのような 新しい種類のファンディングトランザクションをサポートするために最も緊急に必要なものですが、 他の機能のサポートも追加されるかもしれません。議論された新機能の1つは、 ファンディングトランザクション（またはスポンサートランザクション）が ある時点でブロックに含まれていたことを軽量クライアントが検証できるように、 チャネルアナウンスのメッセージにSPVプルーフ（またはSPVプルーフへのコミットメント）を含められるようにすることです。

    • ● 基本的な送金限界に関する研究: （キャパシティが十分でないチャネルなど）ネットワークの制限により成功しない支払いフローに関する調査が 発表されました（ニュースレター #309参照）。LN支払いが実行不可能な場合、 送信者と受信者はオンチェーン支払いを利用することができます。しかし、 オンチェーン支払いのレートは、最大ブロックweightで制限されるため、 BitcoinとLNを組み合わせた最大スループット（1秒あたりの支払いの数）は、 最大オンチェーンレートを実行不可能なLN支払いのレートで割ることで計算することができます。 この大まかな指標を用いると、1秒あたり約47,000件の支払いという最大値を達成するには、 実行不可能率を0.29%未満に抑える必要があります。実行不可能率を低減するために2つの手法が議論されました。 (1) 2人よりも多くが関与する仮想または実際のチャネル。参加者が増えることで、 転送に使用できる資金が増え、転送資金が増えると実行可能率が向上します。 (2) 信頼関係がある参加者間で、オンチェーンでの支払いを強制することなく、 参加者間で支払いを転送できるクレジットチャネル。他のすべてのユーザーは引き続きトラストレスに支払いを受け取ります。

    Osuntokunは、他の参加者にもこのスレッドに訂正や拡張を投稿するよう促しました。

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

リリースとリリース候補

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

  • ● BDK 1.0.0-beta.5は、ウォレットやその他のBitcoin対応アプリケーションを構築するための このライブラリのリリース候補（RC）です。この最新のRCは、「RBFをデフォルトで有効にし、 レート制限により失敗したサーバー要求を再試行するようにbdk_esploraクライアントを更新します。 bdk_electrumクレートでは、use-openssl機能も提供されるようになりました。」

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

最近の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 #30955では、Stratum V2の要件に沿って、 Miningインターフェース（ニュースレター#310参照）に2つの新しいメソッドが導入されました。 submitSolution()メソッドは、ブロック全体ではなく、nonce、タイムスタンプ、 バージョンフィールド、コインベーストランザクションのみを必要とすることで、 マイナーがより効率的にブロックのソリューションを提出できるようにします。 さらに、getCoinbaseMerklePath()が導入され、 NewTemplateメッセージで要求されるマークルパスフィールドが構成されます。 このPRではまた、Bitcoin Core #13191で以前削除されたBlockMerkleBranchも復活しました。

  • ● Eclair #2927は、推奨値よりも低い手数料率を使用する open_channel2およびsplice_initメッセージを拒否することで、 オンザフライ・ファンディング（ニュースレター#323参照）用の 推奨手数料率（ニュースレター#323参照）を強制します。

  • ● Eclair #2922は、BOLTs #1160で提案された最新のスプライシングプロトコルに準拠するために、 チャネル静止（ニュースレター#309参照）のないスプライシングのサポートを削除しました。 最新のプロトコルでは、スプライシング中にノードが静止プロトコルを使用することが求められます。 これまでは、スプライシングは、コミットメントが既に静止している場合にスプライシングメッセージが許可される、 チャネル静止の簡易版として機能する非形式的な仕組みで許可されていました。

  • ● LDK #3235は、ChannelForceClosedイベントに、last_local_balance_msatsフィールドを追加しました。 このフィールドは、チャネルが強制閉鎖される直前のノードのローカル残高をミリサトシ（msats）単位で提供するもので、 ユーザーは丸めによって失われたmsatsを知ることができます。

  • ● LND #8183は、強制閉鎖トランザクションを生成するために必要なインプットを格納するために、 オプションのCloseTxInputsフィールドを静的チャネルバックアップ（SCB）ファイルの chanbackup.Singleに追加しました。これにより、ピアがオフラインになった際に、 最後の復旧オプションとしてchantools scbforcecloseコマンドを使用して、手動で資金を回収できるようになります。 ただし、バックアップ作成後にチャネルが更新された場合、この機能によって資金が失われる可能性があるため、 ユーザーは十分な注意が必要です。さらに、LNDがシャットダウンするたびにチャネルバックアップを更新する ManualUpdateメソッドが導入されました。

  • ● Rust Bitcoin #3450は、Bitcoin CoreがTRUC（Topologically Restricted Until Confirmation）トランザクションを標準として受け入れたことを受け（ ニュースレター#307参照）、トランザクションバージョンの新しいバリエーションとしてv3を追加しました。