今週のニュースレターでは、Bitcoinのスクリプト言語に対する変更案に関する最近のいくつかの議論を フォローアップしています。また、新しいリリースの発表や、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも含まれています。

ニュース

• ● スクリプトの変更に関する継続的な議論: 以前取り上げた議論に対して、Bitcoin-Devメーリングリストでいくつかの返信がありました。

  • ● コベナンツの研究: Anthony Townsは、 先週言及したRusty Russellの投稿に返信しました。 Townsは、Russellのアプローチを、特に他のコベナンツベースのVaultに関する他のアプローチと比較し、 魅力的ではないと判断しました。Russellはさらに返信の中で、 Vaultにはさまざまな設計があり、Vaultは他のトランザクションタイプに比べて基本的に最適ではないことを指摘し、 Vaultユーザーにとって最適化が重要ではないことを示唆しています。 彼は、BIP345のVaultアプローチは、opcodeのセットよりもアドレス形式に適していると主張しました。 これは、BIP345がopcodeのセットとしてよりも、 1つの機能のために設計されたテンプレート（P2WPKHのような）とする方が理にかなっていることを意味しますが、 スクリプトの残りの部分と予期しない方法で相互作用する可能性があります。

    Townsはまた、一般的に実験を可能にする目的でRussellのアプローチを使用することを検討し、 「より興味深い[…]が、それでもかなり不自由である」と感じています。 彼は、LispスタイルのBitcoin Scriptの代替を提供するという以前の提案（ニュースレター #191参照）を読者に思い出させ、 それがwitnessの評価中にトランザクションのイントロスペクションを実行するための柔軟性と能力の向上をどうもたらすかを示しています。 彼は、テストコードへのリンクを提供し、彼が書いたいくつかのおもちゃの例について言及しました。 Russellは、「置き換えまでにはまだ改善の余地がたくさんあると思う。ほとんどの興味深いケースは不可能なので、 今あるスクリプトと代替案を比較するのは難しい。」と応えています。

    TownsとRussellは、OP_CHECKSIGFROMSTACK、 特にオラクルからの認証済みデータを評価スタックに直接配置できるようにする機能についても簡単に触れています。

  • ● OP_CATの提案: 先週言及した、 OP_CATのBIP提案を発表したEthan Heilmanの投稿に数名から返信がありました。

    OP_CATがスタック要素のサイズの520バイトの制限によって過度に制限されるのではないかという懸念について いくつかの返信で言及された後、Peter Toddは、追加のOP_SUCCESSxを使用せずに、 将来のソフトフォークで制限を引き上げる方法について説明しました。 欠点は、制限を引き上げる前にOP_CATを使用するには、既に有効な少数の追加のopcodeをスクリプトに含める必要があることです。

    Russellのコベナンツの研究に対するAnthony Townsの同様の回答の前に行われた投稿で、 James O’Beirneは、OP_CATを使用してVaultを実装する場合の重大な制限について指摘しています。 彼は、BIP345スタイルのVaultと比較してOP_CATバージョンにかけているいくつかの機能を特に指摘しています。

リリースとリリース候補

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

• ● LDK 0.0.118は、LN対応アプリケーションを構築するためのこのライブラリの最新リリースです。 他の新機能やバグ修正に加えてOfferプロトコルの部分的な実験的サポートが含まれています。

• ● Rust Bitcoin 0.31.1は、Bitcoinデータを扱うためのこのライブラリの最新リリースです。 新しい機能とバグ修正のリストについては、リリースノートをご覧ください。

注: 前回のニュースレターで紹介したBitcoin Core 26.0rc1にはタグが付けられていますが、 macOS用の再現可能なバイナリの作成を妨げるAppleによる変更のため、バイナリはアップロードされていません。 Bitcoin Coreの開発者は、2つめのリリース候補の緩和策に取り組んでいます。

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

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

• ● Bitcoin Core #28685は、以前のニュースレターで言及した、 UTXOセットのハッシュの計算のバグを修正しています。これには、 以前のhash_serialized_2の値が、修正されたハッシュを含むhash_serialized_3に置き換えられる gettxoutsetinfo RPCの破壊的な変更を含みます。

• ● Bitcoin Core #28651により、Miniscriptは、 Taprootアウトプットを使用するためにwitnessの構造に含める必要がある最大バイト数を より正確に推定できるようになりました。この精度の向上は、Bitcoin Coreのウォレットの手数料の過払いを防止するのに役立ちます。

• ● Bitcoin Core #28565は、#27511をベースに構築され、 ネットワーク（IPv4、IPv6、Tor、I2P、CJDNS）ごとにセグメントされた「新規」または「試行済み」の ピアのアドレスの数を公開するgetaddrmaninfo RPCを追加しました。 このセグメンテーションの動機については、ニュースレター #237および ポッドキャスト #237を参照ください。

• ● LND #7828は、ピアが妥当な時間内にLNプロトコルのpingメッセージに応答することを要求するようになりました。 応答しないと接続が切断されます。これは接続がアクティブな状態を維持するのに役立ちます（ 切断された接続によって支払いが滞り、望ましくないチャネルの強制閉鎖が発生する可能性が低減されます）。 LNのpingとpongには他にも多くの利点があります。ネットワークトラフィックの偽装に役立ち、 ネットワークの観察者が支払いを追跡するのが難しくなります（支払いやping、pongはすべて暗号化されているため）。 BOLT1で定義されているように、暗号鍵のローテーションをより頻繁にトリガーします。 特にLNDでは、エクリプス攻撃の防止に pongメッセージを使用しています（ニュースレター #164参照）。

• ● LDK #2660により、呼び出し元がオンチェーントランザクションに対して選択できる手数料率について より柔軟に選択できるようになりました。 これには、最低額の支払い、承認に1日以上かかる可能性がある低手数料率、通常の優先順位、 高優先順位の設定が含まれます。

• ● BOLTs #1086は、転送されたHTLCを作成するための指示が、 ローカルノードが払い戻しを請求できるようになるまで2,016ブロックを超えて待機するような要求であった場合に、 ノードはHTLCを拒否（払い戻し）し、expiry_too_farエラーを返すよう定義しました。 この設定を下げると、特定のチャネルジャミング攻撃や、 長期の保留インボイスによるノードの最悪の場合の収入損失を減らすことができます。 この設定を引き上げると、同じ最大HTLC deltaの設定でより多くのチャネルに支払いを転送することができます（ または、より高い最大HTLC delta設定の場合は同じホップ数で、 先週のニュースレターで説明した置換サイクル攻撃などの特定の攻撃に対する耐性を向上させることができます）。