今週のニュースレターでは、クラスターmempool展開後のリレーの拡張のアイディアと、 2023年のLNスタイルのアンカーアウトプットのトポロジーと研究結果、 Bitcoin-Devメーリングリストの新しいホストの発表および、 フリーソフトウェアの貢献者に感謝するI Love Free Software Dayのお祝いについて掲載しています。 また、Bitcoin Core PR Review Clubミーティングの要約や、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

  • ● クラスターmempool展開後のリレーの拡張に関するアイディア: Gregory Sandersは、クラスターmempoolのサポートが完全に実装、テストされ、 展開された後で、個々のトランザクションが特定のmempoolポリシーにオプトインできるようにするためのいくつかのアイディアを Delving Bitcoinに投稿しました。この改良は、 v3トランザクションリレーの機能に基づいており、 もう必要ないと思われるルールを緩和し、トランザクション（またはトランザクションのパッケージ）が 次のブロックまたは2ブロック以内にマイニングされる可能性が高い手数料率を支払うという要件を追加します。

  • ● 1年前にv3セマンティクスがアンカーアウトプットに適用されていたらどうなっていただろう？ Suhas Daftuarは、アンカースタイルのLNコミットメントと 手数料引き上げのトランザクションにv3トランザクションリレーポリシーを自動的に適用するアイディア（ 基礎となるv3の埋め込みの提案についてはニュースレター #286参照）に関する研究結果を Delving Bitcoinに投稿しました。 つまり彼は、2023年にアンカーの支払いのように見える14,124個のトランザクションを記録しました。そのうち、

    • 約94%は、v3ルールの下で成功するでしょう。

    • 約2.1%は、複数の親を持っていました（たとえば、 CPFPのバッチ支払いの試行など）。一部のLNウォレットは、 短時間に複数のチャネルを閉じる際に、効率化のためにこのような動作をするものがあります。 アンカースタイルのアウトプットにv3の特性を組み込む場合は、この動作を無効にする必要があります。

    • 約1.8%は、親の最初の子ではありませんでした。v3が組み込まれた場合、 2つめの子はパッケージ内の最初の子を置き換えることができます（ニュースレター #287参照）。

    • 約1.2%は、明らかにコミットメントトランザクションの孫であり、 つまり、アンカーアウトプットの支払いのさらに支払いでした。 LNウォレットは、複数のアンカーチャネルを順番に閉鎖したり、 アンカーチャネル閉鎖のお釣りから新しいチャネルを開設したりと、さまざまな理由でこれを行う可能性があります。 アンカースタイルのアウトプットにv3の特性が組み込まれた場合、LNウォレットはこの動作を使用できなくなります。

    • 約1.2%は、マイニングされず、それ以上分析されませんでした。

    • 約0.1%は、無関係な未承認のアウトプットを使用しており、 その結果、アンカーの支払いは許容される1つ以上の親を持つようになりました。 開発者のBastien Teinturierは、これはEclairの動作かもしれないと考えており、 Eclairは現在のコードでもこの状況を自動的に解決すると指摘しています。

    • 1,000 vbyteを超えるものは0.1%未満でした。 これは、LNウォレットが変更すべき動作でもあります。 Daftuarのさらなる調査によると、ほぼすべてのアンカーの支払いは500 vbyte未満であり、 v3のサイズ制限が縮小される可能性が示唆されました。そうすると、 アンカーの支払いに対するPinning攻撃の試行を防ぐためのコストが低くなりますが、 LNウォレットが数個よりも多くのUTXOから手数料を拠出することができなくなります。 Teinturierは、「1,000 vbyteの値を下げることは非常に魅力的ですが、 過去のデータでは（保留中のHTLCがとても少ない）誠実な試みしか示されておらず、 ネットワーク上での広範な攻撃はまだ確認されていないため、 どのような値がより良い値になるかを把握するのは困難です」と述べています。

    このトピックに関する追加の議論や研究が期待されますが、 Bitcoin Coreがアンカーの支払いをv3トランザクションとして安全に扱い始める前に、 LNウォレットはv3セマンティクスによりよく適合するために、 いくつかの小さな変更を加える必要があるかもしれないというのが、今回の結果からの私たちの印象です。

  • ● Bitcoin-Devメーリングリストに移動: プロトコル開発を議論するメーリングリストは、 新しいメールアドレスと新しいサーバーでホストされるようになりました。 引き続き投稿を受け取りたい人は、再登録が必要です。 詳細は、Bryan Bishopの移行メールをご覧ください。 移行に関する過去の議論については、ニュースレター#276と#288をご覧ください。

  • ● I Love Free Software Day: 毎年2月14日、FSFやFSFEなどの組織は、 FOSS（Free and Open Source Software）のユーザーに向けて、 「フリーソフトウェアを保守し貢献しているすべての人々に「ありがとう！」を言おう」と奨励しています。 2月14日以降にこのニュースレターを読んでいる場合でも、BitcoinのFOSSプロジェクトに貢献してくれている お気に入りの人たちに感謝の気持ちを伝えることをお勧めします。

Bitcoin Core PR Review Club

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

Add maxfeerate and maxburnamount args to submitpackageは、 Greg Sanders（GitHubではinstagibbs）によるPRで、単一トランザクションのRPC sendrawtransactionとtestmempoolacceptには既に存在する機能をsubmitpackage RPCに追加するものです。 このPRは、より大きなパッケージリレープロジェクトの一部です。 具体的には、このPRはパッケージの送信者が（PRのタイトルにある）引数を指定できるようにするもので、 これにより要求されたパッケージ内のトランザクションのサニティチェックを可能にし、 偶発的な資金の損失を防ぐことができます。Review Clubミーティングは、 Abubakar Sadiq Ismail（GitHubではismaelsadeeq）が主催しました。

  • なぜ送信されたパッケージに対してこれらのチェックを行うことが重要なのですか？

    パッケージ内のトランザクションに、個々のトランザクションの送信と同じセーフガードが適用されることは、ユーザーにとって有益です。 ➚

  • maxburnamountとmaxfeerate以外に、mempoolに受け入れられる前にパッケージに対して実行されるべき他の重要なチェックはありますか？

    はい。2つの例が、基本手数料のチェックと最大標準トランザクションサイズです。 これらは低コストのチェックであるため、早期にチェックすることができ、パッケージを迅速に失敗させることができます。 ➚

  • maxburnamountとmaxfeerateのオプションは、トランザクションがmempoolに入ってリレーされるのを防ぐことができます。 これらのオプションはポリシールールとみなすことができますか？それは何故で、あるいはそうでない場合は何故ですか？

    これはポリシーです。これらのチェックはマイニングされたブロックのトランザクションには適用されません（つまり、これはコンセンサスではありません）。 これらはピアからのトランザクションリレーにも影響せず、RPCを使用してローカルで送信されたトランザクションにのみ影響します。 ➚

  • なぜ基本手数料率ではなく、変更された手数料率に対してmaxfeerateを検証するのですか？

    （以前のReview Club24152、24538および 27501で、変更版と基本手数料の概念を取り上げました） ほとんどの参加者は、sendrawtransactionとtestmempoolacceptがそのチェックで基本手数料を使用しているため、 変更された手数料ではなく基本手数料を使用する必要があると考えていました。その方が一貫性があるように思えるからです。 （修正版と基本手数料を異なるものとする）prioritisetransactionは、通常マイナーのみが使用するため、 実用的な違いは生じない可能性があります。 ➚

  • パッケージの手数料率ではなく、パッケージの個々のトランザクションの変更された手数料率に対してmaxfeerateを検証します。 これが不正確になるのはどのような場合ですか？

    パッケージの子トランザクションが、その変更された手数料率が個々にmaxfeerateを超える場合、拒否されますが、 パッケージとしてチェックされている場合は拒否されません。 ➚

  • その不正確さの可能性を考えると、なぜ代わりにmaxfeerateをパッケージの手数料率に対してチェックしないのですか？

    それは別の不正確さを引き起こす可能性があるためです。トランザクションAの手数料がゼロで、 BがCPFPによりAの手数料を引き上げると仮定します。AとBは両方とも物理的に大きいので、 どちらもmaxfeerateを超過しません。しかし、今、AとBの両方を使用する高手数料率のCが追加されました。 （これは2つの階層しかないため許可されるトポロジーですが、submitpackage RPCではこのトポロジーが許可されないことが指摘されました） この場合、Cは手数料の多くがAとBに吸収されるため受け入れられますが、Cは拒否されるべきです。 ➚

  • なぜmaxfeerateは、maxburnamountのようにデコード後すぐにチェックされないのですか？

    トランザクションインプットにはインプットの金額が明示的に記載されていないことはよく知られています。 これは親のアウトプットを探した後でのみ知ることができます。手数料率には手数料が必要であるため、 インプットの金額が必要です。 ➚

  • testmempoolaccept RPCのmaxfeerateチェックは、submitpackage RPCとどう異なりますか？ なぜ同じにはならないのでしょうか？

    先ほどに説明したように、submitpackageは変更された手数料を使用しますが、 testmempoolacceptは基本手数料を使用します。また、 トランザクションはmempoolに追加されず、処理後にブロードキャストされるため、 手数料率のチェックはtestacceptパッケージの処理後に行われます。 そのため、安全にmaxfeerateのチェックを行い、適切なエラーメッセージを返すことができます。 同じことをsubmitpackageで行うことはできません。パッケージのトランザクションが既にmempoolに受け入れられ、 ピアにブロードキャストされている可能性があり、チェックが冗長になるからです。 ➚

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

今週の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 #28948は、 バージョン3トランザクションリレーのサポートを追加し（ただし、有効にはなっていません）、 未承認の親を持たないv3トランザクションが、通常のトランザクションの受け入れルールに従ってmempoolに入ることが可能になりました。 v3トランザクションは、CPFPによる手数料の引き上げをすることができますが、 子トランザクションは1,000 vbyte以下の場合に限定されます。 各親のv3は、未承認の子トランザクションを1つだけmempoolに持つことができ、 各子は未承認の親を1つだけ持つことができます。親トランザクションか子トランザクションのどちらかは、 常に手数料による置換が可能です。このルールは、Bitcoin Coreのリレーポリシーにのみ適用されます。 コンセンサスレイヤーでは、v3トランザクションはBIP68で定義されたバージョン2トランザクションと同じように検証されます。 この新しいルールは、LNのようなコントラクトプロトコルが、 トランザクションのPinning攻撃から逃れるために必要な手数料を最小限に抑えながら、 事前コミットしたトランザクションを常に迅速に承認できるようにすることを目的としています。

  • ● Core Lightning #6785では、Bitcoin上でアンカースタイルのチャネルがデフォルトになりました。 Elements互換のサイドチェーン上のチャネルでは、非アンカーチャネルが引き続き使用されます。

  • ● Eclair #2818は、既存の未承認トランザクションが承認される可能性が非常に低いケースを検出することで、 Eclairウォレットが安全に使用できると考えるインプットの数を最大化します。 Eclairは、Bitcoin Coreのウォレットを使用して、手数料引き上げトランザクションを含む オンチェーン支払いのUTXOを管理します。ウォレットによって制御されるUTXOが、 トランザクションのインプットとして使用される場合、Bitcoin Coreのウォレットは、 そのインプットを使用して他の無関係なトランザクションを自動的に作成することはありません。 しかし、そのトランザクションの別のインプットが二重使用され、そのトランザクションが承認できなくなった場合、 Bitcoin CoreのウォレットはUTXOが別のトランザクションで再び使用されることを自動的に許可します。 残念ながら、異なるバージョンが承認され、トランザクションの親が承認不可能になった場合、 Bitcoin Coreのウォレットは現在のところ自動的にUTXOの使用を許可しません。 Eclairは、親トランザクションの二重使用を独自に検出でき、 Eclairの以前のUTXOのアンロックの試みを放棄し、 再度使用可能にするようBitcoin Coreのウォレットに指示します。

  • ● Eclair #2816により、ノードオペレーターはコミットメントトランザクションを承認するために、 アンカーアウトプットに使用する最大額を選択できるようになりました。 これまでEclairは、チャネルの金額の5%までを使用していましたが、 金額が多いチャネルにとっては高すぎる可能性があります。 Eclairの新しいデフォルトは、その手数料率の推定器が提案する最大手数料率で、 絶対的な合計額は10,000 satまでです。Eclairはまた、 まもなく期限切れになるHTLCのリスクにさらされる金額まで引き続き支払い、 10,000 satよりも高くなる可能性があります。

  • ● LND #8338は、チャネルを共同で閉鎖する新しいプロトコルの初期機能を追加しました（ ニュースレター #261およびBOLTs #1096参照）。

  • ● LDK #2856は、受信者が支払いを請求するのに十分なブロックを確保するため、 LDKのルートブラインドの実装を更新しました。 これは、BOLTs #1131のルートブラインドの仕様の更新に基づくものです。

  • ● LDK #2442では、保留中の各HTLCの詳細がChannelDetailsに含まれるようになりました。 これによりAPIの利用者は、HTLCを受け入れるか拒否するために、次に何が必要かを知ることができます。

  • ● Rust Bitcoin #2451は、HD導出パスがmで始まるという要件が削除されました。 BIP32では、文字列mはマスター秘密鍵を表す変数です。パスのみを参照する場合、 mは不要で、文脈によっては誤っている可能性があります。