今週のニュースレターでは、トランザクションwitnessへのデータ保存に関する議論と、 LNのジャミングの緩和に関する会話を掲載しています。 また、Bitcoin Core PR Review Clubミーティングの概要や、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。

ニュース

  • ● ブロックチェーンへのデータ保存に関する議論: 新しいプロジェクトのユーザーが最近、segwit v1（Taproot）のインプットを含むトランザクションの witness内に大量のデータを保存し始めました。Robert Dickinsonは、 そのようなデータ保存を阻止するためにサイズ制限を課すべきかどうかについての質問を Bitcoin-Devメーリングリストに投稿しました。

    Andrew Poelstraは、データの保存を防ぐ効果的な方法はないと回答しています。 不要なデータの保存を防ぐためにwitnessに新しい制限を加えることは、 Taprootの設計時に議論された利点（ニュースレター #65参照）を損なうことになり、 おそらく別の方法でデータが保存されることになるだけでしょう。 そのような別の方法は、データを生成するコストを上げるかもしれませんが、 おそらくその行動を大幅に抑制するほどの効果はなく、 従来のBitcoinユーザーに対して新たな問題を引き起こすかもしれません。

    この記事を書いている時点では、このトピックについて活発な議論が続いています。 来週のニュースレターで最新情報をお伝えする予定です。

  • ● LNのジャミングの緩和に関する会話のまとめ: Carla Kirk-CohenとClara Shikhelmanは、 チャネルジャミング攻撃への対処の試みに関する最近のビデオ会話の概要を Lightning-Devメーリングリストに投稿しました。 アップグレードメカニズムのトレードオフや、 最近の論文（ニュースレター #226参照）に由来する前払い手数料のシンプルな提案、 CircuitBreakerソフトウェア（ニュースレター #230参照）、 レピュテーション・クレデンシャル（ニュースレター #228参照）に関するアップデート、 LSP（Lightning Service Provider）の仕様のワーキンググループの関連研究などのトピックが議論されています。 詳細なまとめや議事録については、メーリングリストの投稿をご覧ください。

    今後のビデオミーティングは2週間毎に開催される予定です。 今後のミーティングのアナウンスについては、Lightning-Devメーリングリストをご確認ください。

Bitcoin Core PR Review Club

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

Track AddrMan totals by network and table, improve precision of adding fixed seedsは、 Martin ZumsandeとAmiti UttarwarによるPRで、 ある状況下でBitcoin Coreクライアントがより確実にアウトバウンドピアを見つけることができるようにするものです。 これは、AddrMan（ピアのアドレスマネージャー）を拡張し、 ネットワークと、”試行済み”タイプと”新規”のタイプ別にアドレスエントリーの数を追跡することで実現しています。 これにより固定シードをより適切に使用できるようになります。 これは、アウトバウンドピアの選択を改善するためのより大きな取り組みの第一歩です。

  • ネットワークはいつ到達可能と判断されますか？

    アクセスできない場合や、-onlynet=設定オプションで1つ以上の他のネットワークが指定されている場合（ 別のネットワークタイプが実際に利用可能であっても、指定されたもののみが到達可能とみなされます）以外は、 到達可能であるとみなされます。 ➚

  • アドレスのネットワークが到達可能かどうかどうかによって、P2Pネットワーク上で受信したアドレスはどのように扱われますか？ アドレスを保存（AddrManへ追加）したり、ピアに転送したりしますか？

    ネットワークが到達可能であればランダムに選択された2つのピアにアドレスをリレーし、 そうでなければ１つか２つのピアにリレーします（１つか２つかはランダムに選択されます）。 そしてネットワークが到達可能な場合のみアドレスを保存します。 ➚

  • 現在、AddrMan内が到達不能なアドレスのみでスタックし、アウトバウンドピアが見つけられないのはどうしてですか？ このPRはそれをどう修正しているのでしょう？

    -onlynet設定オプションを変更した場合です。たとえば、 ノードが常に-onlynet=onionで実行されており、そのAddrManにはI2Pアドレスがないとします。 その後ノードを-onlynet=i2pで再起動します。固定シードは、いくつかのI2Pアドレスを持っていますが、 このPRがなければ、AddrManが 完全に 空ではないため（以前のonionアドレスがあるため）、 ノードはその固定シードを使用しません。このPRにより、 AddrManには その ネットワークタイプの（現在到達可能な）アドレスがないため、 スタートアップコードは、いくつかのI2P固定シードを追加するようになります。 ➚

  • AddrManに追加したいアドレスが既存のアドレスと衝突した場合、何が起こりますか？ 新しいアドレスを優先し、既存のアドレスは常に削除されますか？

    いいえ、既存のアドレスが「ひどい」アドレスと判断されない限り、（新しいアドレスではなく）既存のアドレスが保持されます （AddrInfo::IsTerrible()参照）。 ➚

  • なぜ到達可能な各ネットワークへのアウトバウンド接続を常に持っていることが有益なのですか？

    利己的な理由としては、攻撃者が複数のネットワーク上でノードを実行する必要があるため、 ノードに対しエクリプス攻撃を行うのが難しくなることです。 利他的な理由は、ネットワーク全体を維持し、ネットワークの分断によるチェーンの分断を避けることができるためです。 マイナーを含む半分のノードが、-onlynet=xで動作し、マイナーを含む残りの半分が-onlynet=yで動作していた場合、 2つのチェーンが出現する可能性があります。このPRがなくても、ノードオペレーターは、 -addnode設定オプションまたはaddnode RPCを使用して、利用可能なネットワークタイプ毎に接続を手動で追加することができます。 ➚

  • このPRがあっても、ThreadOpenConnections()の現在のロジックでは、 ノードが到達可能な各ネットワークへのアウトバウンド接続を常に保証するには不十分なのはなぜですか？

    このPRには、到達可能なネットワーク間の特定のピアの分布を 保証 するものはありません。 たとえば、AddrManに1万個のクリアネットアドレスと50個のI2Pアドレスがある場合、 すべてのピアがクリアネット（IPv4やIPv6）になる可能性が高くなります。 ➚

  • このPRの後、この目標（前の質問を参照）に向けての次のステップは何でしょう？

    次に計画されているステップは、到達可能な各ネットワークに少なくとも1つの接続の保持を試みるため、 接続作成プロセスにロジックを追加することです。このPRはそのための準備です。 ➚

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

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

  • ● Bitcoin Core #25880は、初期同期中のストールタイムアウトを適応的にしました。 Bitcoin Coreは、複数のピアに並行してブロックを要求します。 あるピアが他のピアよりも大幅に遅く、ノードが次のブロック待ちでスタックするようになった場合、 タイムアウト後にそのピアを切断します。状況によっては、 大きなブロックをタイムアウト内に転送できなかった場合に、 低帯域幅接続のノードが連続して複数のピアを切断する可能性があります。 このコードの変更により、タイムアウトを動的に適応するためにノードの動作が修正されました。 タイムアウトは、ブロックが受信されない間、切断されたピア毎にインクリメントされ、 ブロックが再度届き始めると、タイムアウトはブロック毎に縮小されます。

  • ● Core Lightning #5679は、CLNのlistコマンドで、SQLクエリを実行するプラグインを提供します。 このパッチは、Core Lightning #5867で紹介されているように、 リリース前に非推奨となったものを無視することができるため、非推奨なものをより適切に処理します。

  • ● Core Lightning #5821は、preapproveinvoice（pre-approve invoice）RPCと preapprovekeysend（pre-approve keysend）RPCを追加しました。 これにより、呼び出し側がCore Lightningの署名モジュール（hsmd）にBOLT11インボイスまたは keysend支払いの詳細を送り、 そのモジュールに支払いに署名する意思があるかどうか確認できるようになりました。 使用可能な金額がレート制限されているアプリケーションなど、一部のアプリケーションでは、 事前に承認を求める方が、単に支払いを試行して失敗に対処するよりも問題が少なくなる可能性があります。

  • ● Core Lightning #5849は、バックエンドを変更し、ノードがそれぞれ1つのチャネルを持つ 100,000以上のピアを処理できるようにしました。近い将来で、 このようなノードを運用環境で実行する可能性は低いですが（これだけ多くのチャネルを開くだけでも、 12個以上のブロックを必要とします）、動作のテストをすることで、開発者はいくつかのパフォーマンスを改善することができました。

  • ● Core Lightning #5892は、Eclairの実装に取り組んでいる開発者による互換性テストに基づいて、 CLNのOfferの実装を更新しました。

  • ● Eclair #2565は、閉鎖されたチャネルの資金を、 チャネルに資金が提供された際に生成されたアドレスではなく、新しいオンチェーンアドレスに送信するように要求するようになりました。 これは、アウトプットのリンク付けを削減させ、 ユーザーのプライバシーを向上させるのに役立つ可能性があります。 このポリシーの例外は、ユーザーがLNプロトコルのupfront-shutdown-scriptオプションを有効にした場合です。 これは、資金調達時にチャネルパートナーに送られる要求で、その時に指定したクロージングアドレスのみを使用します （詳細は、ニュースレター #158参照）。

  • ● LND #7252は、LNDのデータベースバックエンドとしてSQLiteの使用をサポートしました。 これは現在、既存のデータベースを移行するコードが無いため、LNDの新規インストール時のみサポートされます。

  • ● LND #6527は、サーバーのディスク上のTLS鍵を暗号化する機能を追加しました。 LNDはその制御チャネルへのリモート接続、つまりAPIの実行の認証にTLSを使用します。 TLS鍵はノードのウォレットのデータを使って暗号化されるため、 ウォレットをアンロックするとTLS鍵もアンロックされます。 ウォレットのアンロックは、支払いの送受信のために必要です。