今週のニュースレターでは、ノードのフィンガープリンティングに対して考えられるソリューションと、 JITチャネルにおけるインセンティブ向上ために公開Fraud Proofを利用する議論のリンクを掲載しています。 また、人気のBitcoin基盤ソフトウェアの注目すべき更新について解説する、恒例のセクションも含まれています。

ニュース

  • ● ノードのフィンガープリンティングに対して考えられるソリューション: Naiyomaは、複数のネットワーク上で同じノードを識別するためにaddrメッセージのタイムスタンプを利用する ノードのフィンガープリンティング問題（ニュースレター #360参照）についての ソリューションをDelving Bitcoinに投稿しました。

    前回の更新から、研究者らはこの問題についてさらに多くの知見を得て、考慮すべき新たな要因を特定しました。 重要な知見の1つは、アドレスを管理するコード構造であるAddrManに関するものです。AddrManは、 タイムスタンプが30日以上前のアドレスを古くなったアドレスとみなします。これは通常、 ピアがオフラインになっていることに起因します。したがって、対策を検討する際には、 2つの重要な要素を考慮する必要があります。古いタイムスタンプを新しいものに更新すると、 古いアドレスが継続的にゴシップされ続けてしまう可能性があり、逆に古くすると、 ゴシップが早期に停止してしまう可能性があります。これらの考慮事項から、 以前検討されていた一部のソリューションは破棄され、新たなソリューションが提示されました:

    1. シンプルなファジング: アドレスのタイムスタンプに[-5, +5]日の範囲でランダムな歪みを加えます。 ただし、この歪みは時間の経過とともに平均化される可能性があります。

    2. ネットワーク別の固定タイムスタンプ: リクエストに応答する際、特定のネットワークについては実際のタイムスタンプを保持し、 それ以外のネットワークではタイムスタンプを過去のランダム化された値に設定します。ただし、 古いアドレスが必要以上に長く流通し続ける可能性があります。

    3. アドレスを古くする方向のみのファジング: [1, 10]日の範囲のランダムな歪みを適用し、 アドレスを新しくすることなく古くする方向のみに変化させます。ただし、 アドレスが30日のしきい値に早く到達してしまう可能性があります。

    4. 経年変化を考慮したタイムスタンプノイズのファジング: [-1, +5]日の範囲でランダムな歪みを適用し、 アドレスが新しくなる可能性をわずかに残しつつ、主に古くなる方向に変化させます。ただし、 古いアドレスが必要以上に長く流通し続ける可能性があります。

    5. ハイブリッドアプローチ: 最後の選択肢は、上記のアプローチのうち2つを組み合わせるというものです。

    Naiyomaは、関心のある他の開発者からのフィードバックを求めており、 ソリューション2をテストしている彼女のPRを共有しています。

  • ● JITチャネルにおける公開Fraud Proof: Thomas Voegtlinは、LSPの不正行為を示すために公開Fraud Proofを利用することで、 JIT（Just-In-Time）チャネルの背後にあるゲーム理論を改善する提案について Delving Bitcoinに投稿しました。

    アリスは、LSPであるボブとJITチャネルの開設を交渉します。アリスがキャロルからsatsを受け取る必要がある場合、 アリスはプリイメージを作成します。キャロルはボブにHTLCを送信します。アリスはボブにプリイメージを開示し、 LSPがチャネルのファンディングトランザクションをブロードキャストすることを期待します。 ボブがアリスとのチャネルを開設することなくHTLCを請求した場合はどうなるでしょうか？

    Voegtlinは、チェーンをパブリックな調停レイヤーとして利用することを提案しています。 アリスはOP_RETURNを使用してプリイメージを公開し、これにより誰もが開示内容を検証でき、 特定のブロック高に日付を記録できるようにします。一方ボブは、nブロックまで有効なUTXOコミットメントを作成します。 もしボブが、コミットしたトランザクションとは異なるトランザクションで同じUTXOを使用したり、 ファンディングトランザクションをブロードキャストしなかったり、二重使用を試みたりした場合、 Fraud Proofが生成され、他のクライアントがアリスを信頼する必要なく、LSPとしてのボブの評判が損なわれることになります。

    Voegtlinは、詳細な説明を含む論文も提供しており、 他の開発者にこの提案のフィードバックを求めています。

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

最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、Lightning BLIPs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • ● Bitcoin Core #33796は、トランザクションの構造に対するコンテキストフリーなコンセンサスレベルのチェックを実行するための btck_check_transaction()をlibbitcoinkernel C API（ニュースレター #380参照）に追加します。 これには、空のインプットのリストやアウトプットのリスト、不正なコインベースscriptSig長、 重複したインプット、コインベース以外のトランザクションにおけるnull prevout、 有効な範囲外のアウトプットの金額の拒否が含まれます。これらのチェックは、chainstate、 UTXOセットまたはスクリプトの検証を必要としません。

  • ● Bitcoin Core #21283は、PSBTv0との後方互換性を維持しつつ、BIP370 PSBTv2サポートを実装します。PSBTv2は、完全な未署名トランザクションを必要とする代わりに、 バージョン、ロックタイム、インプット、アウトプット、トランザクションの変更可能性といった トランザクション構築データをPSBTフィールドに直接格納します。

  • ● BIPs #2150は、ダストUTXOの処分プロトコル用の仕様であるBIP451を追加します。これは、 ウォレットが不要なダストUTXOを単一のゼロ値のOP_RETURNアウトプットに使用することで 安全に処分するための標準を定義しており、インプットの値すべてがトランザクション手数料として支払われます。 このプロトコルには、承認済みダストUTXOをアドレス毎に処分するなどのプライバシー保護のための構築ルールや、 mempool内で見つかった無関係なダスト処分トランザクションをRBFを介してバッチ処理できるようにする ALL|ANYONECANPAY署名が含まれています。

  • ● Eclair #3144は、Simple Taproot Channelsを 公式の機能ビットを使用するよう更新し、デフォルトで有効化します。ただし、 これらのチャネルのアナウンスはまだサポートされていません。BOLT仕様およびLNDの実装（ニュースレター #401参照）に揃えるため、テストベクトルが追加されています。

  • ● Eclair #2887は、Eclairの以前の実験的なスプライシング実装との後方互換性を維持しつつ、 BOLT仕様にマージされた（ニュースレター #398参照）公式のスプライシングプロトコルのサポートを追加します。

  • ● LDK #4592は、新しいゼロ手数料コミットメント（0FC）チャネルを開設する前に、 ノードが十分な準備金を持っているかどうかをチェックするようになりました。これはそれらのチャネルを アンカーチャネルとしてカウントすることで実現されます。 これまで、LDKの準備金チェックは古いanchors_zero_fee_htlc_tx機能を使用するチャネルのみをカウントしていたため、 ノードが同時強制閉鎖時にウォレットが安全に手数料を引き上げられる数を超えて0FCチャネルを開設できてしまっていました。

  • ● LND #9153は、ローカルノード以外の視点から経路を構築・デシリアライズするために、 Route protoメッセージにsource_pub_keyフィールドを追加します。 sourceが提供されていない場合、LNDは従来どおりローカルノードを使用します。

  • ● Rust Bitcoin #5835は、BitcoinのP2Pメッセージのヘッダーで使用される4 byteのペイロードチェックサムを計算する V1MessageHeaderコンストラクタを追加します。これにより、 呼び出し元はシリアライズされたペイロードとコマンドのヘッダーを構築してからネットワーク経由でメッセージを送信できるため、 ネットワークメッセージの構築が簡素化されます。

  • ● BOLTs #995は、Simple Taproot Channels用の拡張BOLTが追加され、 機能ビット80/81が割り当てられています。この仕様では、P2TRファンディングアウトプットと MuSig2鍵集約、TaprootコミットメントおよびHTLCスクリプト、 そしてチャネルの開設、コミットメントの更新、協調閉鎖、 再接続時にMuSig2部分署名とナンスを交換するための新しいTLVフィールドを使用する、 最小限のTaprootベースのチャネルタイプが定義されています。revoke_and_ackおよび channel_reestablishのナンスフィールドは、スプライシング時など 複数のアクティブなコミットメントトランザクションをサポートするために、 ファンディングtxidをキーとして使用します。この拡張機能は意図的にゴシップの変更を除外しているため、 アナウンスされるTaprootチャネルは今後の課題となります。

  • ● BOLTs #1228では、ゼロ手数料コミットメント（0FC）チャネルが規定され、 機能ビット40/41が割り当てられています。このチャネルタイプでは、feerate_per_kwは0に設定され、 コミットメントトランザクションとHTLCトランザクションは v3トランザクションリレー（TRUC）を使用し、 マイニング手数料はCPFPを使用して子トランザクションによって支払われます。 コミットメントトランザクションには、トリムされたアウトプットと切り捨てられたmillisatoshisから資金が拠出される 共有のP2A（pay-to-anchor）アウトプット（240 satsが上限）が含まれており、 ほとんどの場合、親コミットメントトランザクションが直接手数料を支払う必要はありません。この仕様では、 TRUCの10 kvBというトランザクションサイズ制限のため、このチャネルタイプにおけるHTLCの最大数を114に制限しています。

  • ● BOLTs #1327は、低手数料率においてBIP125置換ルールへの準拠を保証するため、 RBFの手数料率の引き上げルールを更新します。既存の25/24倍の手数料率乗数のみを適用するのではなく、 この仕様では、置換時の手数料率を、当該乗数または追加で25 sat/kwのいずれか大きい方の値だけ引き上げることが要求されるようになります。 これはニュースレター #400で取り上げられたLDKの動作と一致します。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 16:30 UTCに Riverside.fmで毎週配信されているBitcoin Optech Recapにご参加ください。 この議論は録画もされ、ポッドキャストページからご覧いただけます。