今週のニュースレターでは、Bitcoin Coreのフリーリレーと手数料の引き上げ方法のアップグレードに関する幅広い議論を掲載しています。 また、Bitcoin Stack Exchangeで人気のある質問とその回答の共有や、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • ● フリーリレーと手数料の引き上げ方法に関するさまざまな議論: Peter Toddは、以前Bitcoin Core開発者に責任を持って開示したフリーリレー攻撃の概要を Bitcoin-Devメーリングリストに投稿しました。これにより、複数の課題と提案が絡み合った議論が行われました。 議論されたトピックには以下のようなものがります:

    • ● フリーリレー攻撃: フリーリレーは、フルノードが mempoolの手数料収入が最小リレーレート（デフォルトで1 sat/vbyte）以上増加することなく、 未承認のトランザクションをリレーする場合に発生します。 フリーリレーには、ある程度のコストがかかることが多いため、技術的には無料ではありませんが、 そのコストは正直なユーザーがリレーに支払うコストをはるかに下回ります。

      フリーリレーにより、攻撃者はリレーするフルノードが使用する帯域幅を大幅に増やすことができ、 リレーノードの数を減らすことができます。独立して運用されるリレーノードの数が少なくなりすぎると、 支払人は基本的にトランザクションをマイナーに直接送信していることになり、 帯域外の手数料と同じ集中化のリスクが発生します。

      Toddの説明した攻撃は、マイナーとユーザー間のmempoolポリシーの違いを悪用します。 多くのマイナーは、フルRBFを有効にしているようですが、 Bitcoin Coreはこれをデフォルトでは有効にしていません（ニュースレター #263参照）。 これにより攻撃者は、フルRBFマイナーと非フルRBFリレーノードで異なる扱いを受ける 異なるバージョンのトランザクションを作成することができます。 リレーノードは、承認される可能性の低い複数のバージョンのトランザクションをリレーすることになり、 リレーノードの帯域幅を浪費することになります。

      フリーリレー攻撃は、攻撃者が他のユーザーの資金を直接盗めるようにするものではありませんが、 突然または長期にわたる攻撃はネットワークを混乱させ、他のタイプの攻撃を容易にするために使用される可能性があります。 私たちの知る限り、これまで混乱を引き起こすフリーリレー攻撃は行われていません。

    • ● フリーリレーとReplace-by-Feerate: Peter Toddは以前、 2つの形式のRBFR（Replace-by-Feerate）を提案しています（ニュースレター #288参照）。 RBFRに対する批判の1つは、フリーリレーを可能にするというものでした。 同程度のフリーリレーは、彼が今週説明した攻撃や類似の攻撃によって既に可能になっているため、 フリーリレーに関する懸念が、トランザクションのPinning攻撃を緩和するために有用な機能の追加を 妨げるべきではないと彼は主張しました。

      少なくとも1つの返信では、 RBFRによって作られるフリーリレーはその設計の基本だが、Bitcoin Coreの設計における他のフリーリレーの問題は、 解決できる可能性があると主張しました。Toddはこれに同意しませんでした。

    • ● TRUCの有用性: Peter Toddは、TRUCは「悪い提案」であると主張しました。 彼は以前このプロトコルを批判しており（ニュースレター #283参照）、 特にTRUCの仕様であるBIP431を批判しています。BIP431は、フリーリレーに関する懸念を利用して、 彼のRBFRの提案よりもTRUCを推奨しています。

      BIP431はまた、ToddのワンショットRBFRのような、（mempoolの最上部に入ると説明されている） 次の数ブロックでマイニングする最も収益の高いトランザクションになるのに十分な手数料率を支払うことに依存する RBFRのバージョンにも反対しています。Bitcoin Coreがクラスター mempoolを使用し始めれば、 これはより簡単になるだろうという点は、Toddも他のメンバーも同意していますが、Toddは現在利用可能な代替案も提案しました。 TRUCは、mempoolの最上部に関する情報を必要としないため、クラスターmempoolや代替方法に依存しません。

      この批判は、ニュースレター #288で要約され、その後の研究（ニュースレター #290で要約）により、 どのようなトランザクション置換ルールセットでも、マイナーの収益性を向上させる選択を常に行うことがいかに難しいかが示されています。 RBFRと比較して、TRUCは（TRUCトランザクションに対して常に置換を許可することを除いて）Bitcoin Coreの置換ルールを変更しないため、 置換のインセンティブ互換性に関する既存の問題が悪化することはありません。

    • ● クラスターmempoolへの道: ニュースレター #285に掲載されているように、 クラスターmempoolの提案では、現在LNのアンカーアウトプットでペイメントチャネルの多額の資金を保護するために使用されている CPFP carve-out（CPFP-CO）を無効にする必要があります。 パッケージリレー（具体的にはパッケージRBF）と組み合わせると、ワンショットRBFRは、 既にアンカーアウトプットを使用したRBFによる手数料の引き上げを繰り返しているLNソフトウェアを変更することなく、 CPFP-COを置き換えることができる可能性があります。ただし、ワンショットRBFRは、 クラスターmempoolなどからmempoolの上位の手数料率を知ることに依存しているため、 RBFRとクラスターmempoolを同時に展開するか、mempoolの上位の手数料率を決定する別の方法を使用する必要があります。

      比較すると、TRUCはCPFP-COの代替手段を提供しますが、これはオプトイン機能です。 TRUCをサポートするためにすべてのLNソフトウェアをアップグレードする必要があり、 既存のすべてのチャネルでチャネルコミットメントのアップグレードを行う必要があります。 これは、かなりの時間がかかる可能性があり、すべてのLNユーザーがアップグレードしたという強力な証拠が得られるまで、 CPFP-COを無効にすることはできません。CPFP-COが無効になるまで、クラスターmempoolを安全に広く展開することはできません。

      以前のOptechニュースレター#286と#287、#289で言及したように、 TRUCの採用が遅く、クラスターmempoolがすぐに利用できないことは、 アンカースタイルのLNのコミットメントトランザクションにTRUCと兄弟の排除を自動的に適用する Imbued TRUC によって対処することができます。LN開発者やImbued TRUC提案のコントリビューターの中には、 そのような結果は避けたいと述べる人もいました。 TRUCへの明示的なアップグレードの方が多くの点で優れており、 LN開発者がチャネルアップグレードの仕組みに取り組む理由は他にも複数ありますが、 クラスターmempoolの開発がLNのコミットメントアップグレードの開発を上回った場合、 Imbued TRUCが再び検討される可能性は十分あります。

      Imbued TRUCとオプトインTRUCの幅広い採用により、CPFP-COを無効にしてクラスターmempoolを展開することが可能になりますが、 どちらのTRUCシステムもクラスターmempoolやトランザクションのインセンティブ互換性を計算するその他の新しい方法に依存していません。 そのため、クラスターmempoolとは関係なくTRUCを分析する方が、RBFRを分析するよりも簡単です。

    この記事の執筆時点では、メーリングリストで議論が続いています。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

リリースとリリース候補

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

  • ● BDK 1.0.0-beta.1は、「安定した1.0.0 APIを備えたbdk_walletの最初のベータ版」のリリース候補です。

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

今週の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 #30320は、assumeUTXOの動作を更新し、 現在のベストヘッダーm_best_headerの祖先でない場合は、スナップショットをロードしないようにし、 代わりに通常のノードとして同期します。スナップショットが後でチェーンの再編成によりベストヘッダーの祖先になった場合は、 assumeUTXOスナップショットのロードが再開されます。

  • ● Bitcoin Core #29523は、トランザクションファンディングRPCコマンドfundrawtransaction、 walletcreatefundedpsbtおよびsendにmax_tx_weightオプションを追加しました。 これにより、結果として得られるトランザクションのweightが指定された制限を超えないことが保証され、 将来のRBFの試行や特定のトランザクションプロトコルに役立ちます。 オプションがセットされていない場合は、400,000 weight unit（100,000 vbyte）の MAX_STANDARD_TX_WEIGHTがデフォルトで使用されます。

  • ● Core Lightning #7461では、ノードがBOLT12オファーとインボイスを 自己取得および自己支払いするためのサポートが追加されました。 これにより、ニュースレター #262で説明されているように、 バックグランドでCLNを呼び出すアカウント管理コードが簡素化される可能性があります。 このPRはまた、ノード自体がブラインドパスの先頭であっても、 ノードがインボイスに支払うことを許可します。 さらに（非公表チャネルを持たない）非公表ノードは、 最後から２つめのホップがチャネルピアの１つであるブラインドパスを自動的に追加することで、 オファーを作成できるようになります。

  • ● Eclair #2881では、新しい着信static_remote_keyチャネルのサポートが削除されましたが、 既存のチャネルとこのオプションを使用する発信チャネルのサポートは維持されます。 ノードは着信static_remote_keyの新しいチャネルが廃止されたとみなされるため、 代わりにアンカーアウトプットを使用する必要があります。