今週のニュースレターでは、クラスターmempoolへの移行を容易にするために、 RBFルールを使用してv3トランザクションの置換を可能にする提案と、 一般的に外部的な手数料を必要とすることからOP_CHECKTEMPLATEVERIFYに対する反論を掲載しています。 また、Bitcoin Stack Exchangeの主な質問とその回答や、新しいリリースとリリース候補の発表および、 人気のBitcoinインフラストラクチャプロジェクトの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • ● 手数料による同類の置換: Gloria Zhaoは、 2つのトラランザクションが競合しない場合でも、mempool内のトランザクションの関連トランザクションを置換できるようにすることについて、 Delving Bitcoinに投稿しました。 2つのトランザクションは、両方が同じブロックチェーン内に存在できない場合、競合している とみなされます。 これは、通常、両方が同じインプットを使用しようとするためで、 インプットは特定のブロックチェーン内で１回のみ使用できるというルールに違反します。 RBFのルールは、新しく受信したトランザクションがmempool内のトランザクションと競合しないか比較します。 Zhaoは、競合ポリシーについて考える理想的な方法を提案しています。 2つのトランザクションがあり、受け入れられるのは1つだけである場合、最初に到着した方を選択するのではなく、 目標（実質的に無料のリレーを許可することなくマイナーの収益を最大化するなど）に最も適した方を選択すべきです。 RBFのルールは、競合に対してこれを行うことを試みており、Zhaoの投稿では、これを競合だけなく関連トランザクションにも拡張しています。

    Bitcoin Coreは、mempoolで同時に許可される関連トランザクションの数とサイズに ポリシー 制限を設けています。 この制限により、いくつかのDoS攻撃が軽減されますが、前に制限の上限に達した関連トランザクションAを受け取っているため、 トランザクションBが拒否される可能性があることを意味します。 これは、Zhaoの原則に反します。代わりに、Bitcoin Coreは、AとBのいずれか実際にその目標に最適なものを受け入れるべきです。

    v3トランザクションリレーで提案されたルールでは、 未承認のv3の親は、mempool内に１つの子トランザクションのみを持つことが許可されます。 どちらのトランザクションもmempool内に他の祖先や依存関係を持つことができないため、 既存のRBFルールをv3子トランザクションの置き換えに適用するのは簡単で、Zhaoはそれを実装しました。 先週のニュースレターに掲載したように、 アンカーアウトプットを使用する既存のLNのコミットメントトランザクションに自動的にv3ポリシーが登録される場合、 これによりどちらかの当事者がいつでもコミットメントトランザクションの手数料を引き上げることができます。

    • アリスは、手数料を支払うために子トランザクションを含むコミットメントトランザクションを送信できます。

    • アリスは、後でRBFにより既存の子トランザクションの手数料を増やすことができます。

    • ボブは、より高い手数料を支払う子トランザクションを送信することで、 同類の置換を利用してアリスの子トランザクションを排除することができます。

    • アリスは、後からより高い手数料を支払う子トランザクションを送信することで、 ボブの子に対して同類の置換を行うことができます（ボブの子トランザクションを削除します）。

    このポリシーを追加して、現在のLNアンカーに自動的に適用すると、 クラスターmempoolの実装に必要なCPFP carve-outルールを削除できるようになります。 これにより、将来的にはあらゆる種類の置換のインセンティブの互換性が向上するはずです。

    この記事を書いている時点では、フォーラム上でこのアイディアに対する反対意見はありませんでした。 注目すべき質問の１つは、これによりエフェメラルアンカーの必要性がなくなるかどうかについてでしたが、 その提案の作者（Gregory Sanders）は、「エフェメラルアンカーの作業をやめるつもりはありません。 ゼロsatoshiのアウトプットには、LN以外にも多くの重要なユースケースがあります。」と返信しました。

  • ● 外部的な手数料を要求することを根拠としたCTVへの反対: Peter Toddは、OP_CHECKTEMPLATEVERIFYの提案に適用される 外部的な手数料（ニュースレター #284参照）に対する主張を Bitcoin-Devメーリングリストに投稿しました。彼は、 「複数の当事者が単一のUTXOを共有できるようにすることを目的とした（ほとんどではないにしても）多くのCTVのユースケースでは、 考えられるすべての手数料率をカバーするのに十分なCTVのバリエーションを許容することは困難または不可能です。 CTVは通常、手数料を支払うためにアンカーアウトプットと一緒に使用されることが予想され[…] 場合によってはトランザクションスポンサーのソフトフォークを介して使用されます。[…] すべてのユーザーが手数料を支払うためにUTXOを持つ必要があるというこの要件は、 CTVを使用したUTXOの共有方式の効率を否定します。[…]唯一の現実的な代替案は、 UTXOの支払いにサードパーティを使用することです（例：LN支払いを介して）。 しかし、この点については帯域外でマイニング手数料を支払う方が効率的です。 もちろん、これはマイニングの集中化の観点から非常に望ましくないことです。」と述べています（ リンクはOptechが追加しました）。彼は、CTVを放棄し、 代わりにRBFと互換性のあるコベナンツ方式に取り組むことを推奨しています。

    John Lawは、手数料依存のタイムロックにより（ニュースレター #283参照）、 一部のコントラクトの決済を不確定期間遅延させるかもしれないが、 トランザクションの特定のバージョンを期限までに承認する必要がある場合に、 内部的な手数料を支払うCTVを安全に使用できるようになる可能性があると返信しました。

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

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

リリースとリリース候補

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

  • ● HWI 2.4.0は、複数の異なるハードウェア署名デバイスへの共通のインターフェースを提供する このパッケージの次期バージョンのリリースです。この新しいリリースでは、 Trezor Safe 3のサポートが追加され、いくつかの小規模な改善が含まれています。

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

今週の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 #29291では、OP_CHECKSEQUENCEVERIFY opcodeを実行するトランザクションの バージョン番号が負であると思われる場合に失敗するテストが追加されています。 このテストが、代替のコンセンサス実装で実行されていれば、 先週のニュースレターで言及したコンセンサス障害のバグは発見できたでしょう。

  • ● Eclair #2811、#2813、#2814は、 トランポリンペイメントで最終的な受信者に対して ブラインドパスを使用する機能を追加しました。 トランポリンルーティング自体は、通常のOnion暗号化したノードIDを引き続き使用します。 つまり、各トランポリンノードは次のトランポリンノードのIDを学習します。 ただし、ブラインドパスが使用されている場合、最後のトランポリンノードは、 ブラインドパス内の最初の転送ノードのノードIDのみを学習します。 最終的な受信者のノードIDは学習されません。

    以前は、強力なトランポリンプライバシーは、複数のトランポリン転送者の使用に依存していたため、 どの転送者も自分が最後の転送者であることを確信できませんでした。 このアプローチの欠点は、より長いパスが使用されるため、転送が失敗する確率が高まり、 成功のためにより多くの転送手数料を支払う必要があることです。 現在は、単一のトランポリンノードを介した支払いの転送でも、 そのノードが最終的な受信者を学習するのを防止できます。

  • ● LND #8167は、LNDチャネルが、まだ1つ以上の支払い（HTLC）の保留があるチャネルの協調クローズを可能にします。 BOLT2の仕様では、この場合の適切な手順は、一方がshutdownメッセージを送信し、 それ以降新しいHTLCが受け入れられなくなると記載されています。すべての保留中のHTLCがオフチェーンで解決された後、 両者は交渉して協調クローズトランザクションに署名します。以前は、 LNDがshutdownメッセージを受信すると、チャネルが強制的に閉じられ、 決済のために追加のオンチェーントランザクションと手数料が必要でした。

  • ● LND #7733は、ウォッチタワーのサポートを更新し、 現在LNDによって実験的にサポートされているSimple Taproot Channelの バックアップと正しいシャットダウンを強制できるようになりました。

  • ● LND #8275は、BOLTs #1092で定義されているように、 ピアが特定の普遍的にデプロイされた機能（ニュースレター #259参照）をサポートすることを要求するようになりました。

  • ● Rust Bitcoin #2366は、Transactionオブジェクトの.txidプロパティを廃止し、 代わりに.compute_txidという名前のプロパティを提供するようになりました。 .txidプロパティが呼ばれるたびに、トランザクションのtxidが計算され、 これは十分なCPUを消費するため、大きなトランザクションや多数の小さなトランザクションで関数を実行している人にとっては問題になります。 このプロパティの新しい名前は、下流のプログラマーがその潜在的なコストを認識するのに役立つと期待されています。 .wtxidプロパティと.ntxidプロパティ（それぞれBIP141とBIP140に基づく）も同様に、 .compute_wtxidと.compute_ntxidにリネームされています。

  • ● HWI #716は、Trezor Safe 3ハードウェア署名デバイスのサポートを追加しました。

  • ● BDK #1172は、ウォレット用にブロック単位のAPIを追加しました。 ウォレットに影響するトランザクションが含まれていると思われる一連のブロックにアクセスできるユーザーは、 それらのブロックを反復処理して、ブロック内のトランザクションに基づいてウォレットを更新できます。 これは、チェーン上のすべてのブロックを反復するために簡単に使用できます。 あるいは、ソフトウェアはある種のフィルタリング方法（コンパクトブロックフィルターなど）を使用して、 ウォレットに影響するトランザクションを持つ可能性のあるブロックのみを見つけて、 ブロックのサブセットを反復処理することも可能です。

  • ● BINANAs #3は、BIPやBOLT、BLIP、SLIP、LNPBPおよびDLCの仕様など、 Bitcoinに関連する仕様リポジトリのリストを定義したBIN24-5を追加しました。 他の関連プロジェクトの仕様リポジトリもいくつかリストアップされています。