今週のニュースレターでは、LNDの旧バージョンに影響する脆弱性の開示の発表と、 サイレントペイメント用のPSBTに関する継続的な議論を掲載しています。 また、サービスとクライアントソフトウェアの最近の変更や、 リリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも掲載しています。

ニュース

  • ● LNDの旧バージョンに影響する脆弱性の開示: Matt Morehouseは、 LNDの0.17.0より前のバージョンに影響する脆弱性の開示をDelving Bitcoinに投稿しました。 LNは、複数の暗号化されたペイロードを含むOnion暗号化パケットを使用して、 支払いの指示とOnionメッセージをリレーします。 各ペイローにはその長さのプレフィックスが付与されてており、 2019年以降、支払いには最大1,300バイトまでのサイズが許可されています。 その後導入されたOnionメッセージは、最大32,768バイトです。しかし、ペイロードサイズのプレフィックスは、 最大264バイトまで示すことができるデータ型を使用しています。

    LNDは、ペイロードの指定サイズを最大4GBまで受け入れ、ペイロードを処理する前にその量のメモリを割り当てます。 これは、一部のLNDノードのメモリを使い果たすのに十分で、その結果、ノードがクラッシュしたり、 OSによって終了したりします。また、このように構築された複数のOnionパケットを送信することで、 より多くのメモリを持つノードをクラッシュさせることもできます。クラッシュしたLNノードは、 資金を保護するために必要な時間的制約のあるトランザクションを送信することができず、 資金が盗まれる可能性があります。

    この脆弱性は、最大メモリ割り当て量を65,536バイトに減らすことで修正されました。

    LNDノードを運用している人は、バージョン0.17.0以上にアップグレードする必要があります。 最新のバージョン（執筆時点では0.18.0）へのアップグレードが常に推奨されます。

  • ● サイレントペイメント用のPSBTの継続的な議論: 何人かの開発者が、 PSBTを使用したサイレントペイメントの送信を調整するためのサポートについて議論しています。 前回の要約以降、各署名者が ECDHシェア と、 そのシェアが正しく生成されたことのコンパクトな証明を生成する手法の使用に焦点が当てられてきました。 これらは、PSBTのインプットのセクションに追加されます。 すべての署名者のシェアを受け取ると、受信者のサイレントペイメントスキャンキーと結合され、 アウトプットスクリプトに配置される実際の鍵が生成されます（または、同じトランザクションで複数のサイレントペイメントが作られる場合は、 複数のアウトプットスクリプト用の複数の鍵が生成されます）。

    トランザクションのアウトプットスクリプトが判明したら、各署名者はPSBTを再処理して署名を追加します。 これにより、PSBTの完全な署名には2ラウンドのプロセスが必要になります（MuSig2などの他のプロトコルで必要な他のラウンドに加えて）。 ただし、トランザクション全体に対して署名者が1人だけの場合（たとえば、PSBTが単一のハードウェア署名デバイスに送信されている場合など）、 署名プロセスは1ラウンドで完了できます。

    執筆時点では、議論に参加している全員がこのアプローチにほぼ同意しているようですが、 エッジケースに関する議論は継続中です。

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

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

リリースとリリース候補

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

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

今週の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 #29325は、トランザクションのバージョンを符号なし整数として保存するようになりました。 Bitcoin 0.1のオリジナルバージョン以降、トランザクションのバージョンは符号付き整数として保存されていました。 BIP68ソフトフォークでは、トランザクションのバージョンを符号なし整数として扱うようになりましたが、 少なくとも1つのBitcoinの再実装ではこの動作を再現できず、コンセンサスエラーが発生する可能性があります（ ニュースレター #286参照）。常にトランザクションのバージョンを符号なし整数を使用して保存、使用することで、 Bitcoin Coreのコードに基づく将来のBitcoinの実装で正しい型が使用されることが期待されます。

  • ● Eclair #2867では、ブラインドパスでモバイルウォレットに割り当てられる新しい型 EncodedNodeIdを定義します。これにより、ウォレットプロバイダーは、次のノードがモバイルデバイスであることを通知され、 モバイル固有の条件を考慮できるようになります。

  • ● LND #8730は、承認のターゲットを入力として受け取り、 オンチェーントランザクションの手数料の推定をsat/kw（キロweight単位あたりのsatoshi）と sat/vbyteの両方で返すRPCコマンドlncli wallet estimatefeeを導入します。

  • ● LDK #3098は、LDKのRGS（Rapid Gossip Sync）をv2に更新します。 v2は、シリアライズされた構造にフィールドを追加したv1の拡張です。 これらの新しいフィールドには、デフォルトのノード機能の数を示すバイト、 ノード機能の配列、補足機能または各ノードの公開鍵に続くソケットアドレス情報が含まれます。 この更新は、同様にゴシップv2と呼ばれる提案されたBOLT7の更新とは異なります。

  • ● LDK #3078は、設定オプションのmanually_handle_bolt12_invoicesがセットされている場合、 受信時にInvoiceReceivedイベントが生成されることで、BOLT12インボイスの非同期支払いのサポートを追加します。 ChannelManagerでインボイスへ支払いを行うための新しいコマンドsend_payment_for_bolt12_invoiceが公開されました。 これにより、コードでインボイスを評価した上で、支払うか拒否するかを決定できます。

  • ● LDK #3082は、エンコードおよびパース用のインターフェースと、 オファーのInvoiceRequestへの応答としてBOLT12静的インボイスを構築するためのビルダーメソッドを追加することで、 BOLT12静的インボイス（再利用可能な支払いリクエスト）をサポートします。

  • ● LDK #3103は、実際の支払いパスへの頻繁なプローブに基づくベンチマークで パフォーマンススコアラーを使用し始めます。これにより、より現実的なベンチマークが得られることが期待されます。

  • ● LDK #3037は、手数料率が古く低すぎる場合、チャネルを強制的に閉じるようになります。 LDKは、過去1日の間に推定器が返した許容可能な最低手数料率を継続的に追跡します。 各ブロックで、LDKは過去1日間の最低手数料率を下回るチャネルを閉じます。 この目標は、「強制的に閉じる必要がある場合に、チャネルの手数料率が常にコミットメントトランザクションをオンチェーンで承認するのに 十分であることを保証する」ことです。