今週のニュースレターは、エフェメラル・アンカーの実装に加えて、Bitcoin Core PR Review Clubミーティングの概要や、 新しいリリースおよびリリース候補の発表、人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● エフェメラル・アンカーの実装: Greg Sandersは、 エフェメラル・アンカー（ニュースレター #223参照）に関する彼のアイディアを実装したことを Bitcoin-Devメーリングリストに投稿しました。 アンカー・アウトプットは、Bitcoin CoreのCPFP carve outsによって利用可能になった 既存の技術で、LNのコントラクトに参加する両参加者がCPFPによりそのコントラクトに関連する トランザクションの手数料を引き上げられることを保証するためにLNプロトコルで使用されています。 アンカー・アウトプットにはいくつか欠点があります。根本的なものもあれば（ニュースレター #224参照）、 対処可能なものもあります。

    エフェメラル・アンカーは、v3トランザクションリレーの提案に基づいており、 v3トランザクションはOP_TRUEスクリプトへのゼロ値の支払いのアウトプットを含めることができます。 これにより、ネットワーク上の誰でも使用可能なUTXOを持っていれば、CPFPでそのトランザクションの手数料を引き上げることができます。 手数料を引き上げる子トランザクションは、それ自体が他の使用可能なUTXOによってRBFによる手数料の引き上げが可能です。 v3トランザクションの他のリレーポリシーと組み合わせることで、時間的な制約のあるコントラクトプロトコルのトランザクションに対する トランザクションPinning攻撃に関してポリシーベースの懸念が解消されることが期待されます。

    さらに、誰でもエフェメラル・アウトプットを含むトランザクションの手数料を引き上げられるため、 2人以上が参加するコントラクトプロトコルで利用可能です。 既存のBitcoin Coreのcarve outルールは、参加者が2人の場合のみ機能し、 これを増やすためのこれまでの試みでは参加者の任意の上限を必要としました。

    Sandersのエフェメラル・アンカーの実装により、 提案者によって以前実装された他のv3トランザクションリレー動作と共に、このアイディアのテストができるようになりました。

Bitcoin Core PR Review Club

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

Bump unconfirmed ancestor transactions to target feerateは、 Xekyo (Murch)とglozowによるPRで、未承認のUTXOをインプットとして選択した場合のウォレットの手数料計算の精度を向上させるものです。 このPRがない場合、インプットとして使用されるいくつかの未承認トランザクションの手数料率が、 構築されるトランザクションの手数料率より低い場合、低すぎる手数料が設定されてしまいます。 このPRでは、このような低手数料のソーストランザクションを 新しいトランザクションのターゲットと同じ手数料率に「促進させる」ために十分な手数料を追加することでこの問題を解決します。

このPRがなくても、コイン選択プロセスは、低手数料率の未承認トランザクションの使用を避けようとする点にご注意ください。 このPRは、これ(低すぎる手数料が設定されてしまう問題)を避けることができない場合に有用です。

こうした先祖のトランザクションを考慮して手数料を調整することは、ブロックに含めるトランザクションを選択することと似ていることが判明したため、 このPRではMiniMinerというクラスを追加しています。

このPRは、2週間にわたってレビューされました。

  • このPRはどんな問題を解決しますか？

    ウォレットの手数料の試算では、ターゲットより低い手数料率を持つすべての未承認の先祖に対して必要な手数料を考慮していません。 ➚

  • トランザクションの「クラスター」とは何で構成されたものですか？

    そのトランザクション自体とそのトランザクションと接続されたすべてのトランザクションで構成されています。 これには、そのトランザクションのすべての先祖と子孫や、 兄弟や従兄弟、つまり指定されたトランザクションの先祖や子孫ではない親の子も含まれます。 ➚

  • このPRは実際のマイナーのアルゴリズムといくつか重複するMiniMinerを導入しています。 リファクタリングによって、この2つ実装を統合したほうが良いのでしょうか？

    mempool全体に対してではなく、クラスターに対してのみ計算をする必要があり、 またBlockAssemblerが行っているようなチェックを適用する必要はありません。 mempoolをロックせずにこの計算を行うことも提案されました。 また、ブロックテンプレートを構築するのではなく、手数料の引き上げを追跡するようBlockAssemblerを変更する必要があり、 リファクタリングに必要な量は、書き直しに等しいものでした。 ➚

  • なぜMiniMinerはすべてのクラスターを必要とするのですか？トランザクションの先祖のセットの和ではできないのでしょうか？

    先祖の一部の手数料は、すでに他の子孫によって支払われている可能性があり、さらに手数料を引き上げる必要はないかもしれなせん。 そのため、これらの子孫も計算に含める必要があります。 ➚

  • トランザクションXが独立したトランザクションYよりも高い先祖の手数料率を持っている場合、 マイナーがXよりYを優先する（つまりXよりYをマイニングする）可能性はありますか？

    はい。Yの低手数料率の先祖の一部に高手数料率の子孫がある場合、Yはその先祖のために手数料を支払う必要はありません。 Yの先祖のセットは、そのトランザクションを除外するよう更新され、Yの先祖の手数料率を増加させる効果があります。 ➚

  • CalculateBumpFees()は手数料を過大評価したり過小評価したり、またはその両方、どちらでもないことがありますか？ またそれはどれくらいですか？

    先祖が重複するアウトプットが2つ選択された場合、それぞれが独立して先祖の手数料を引き上げるため（共通の先祖を考慮することなく）過大評価されます。 参加者は、引き上げ手数料を過小評価することはできないと結論づけました。 ➚

  • MiniMinerには、ウォレットが支払いに関心を持つ可能性のあるUTXO（OutPoint）のリストが与えられます。 与えられたOutPointの取りうる5つの状態は何ですか？

    (1) 承認済みで未使用、(2) 承認済みだがmempool内の既存のトランザクションによって既に使用されている、 (3) 未承認（mempool内）で未使用、(4) 未承認だがmempool内の既存のトランザクションによって既に使用されている、 (5) 未知のOutPointである可能性があります。 ➚

  • 「Bump unconfirmed parent txs to target feerate」のコミットではどんなアプローチが取られていますか？

    このコミットは、このPRの主な動作変更です。MiniMinerを使用して、各UTXOの引き上げ手数料を計算し （それぞれの先祖をターゲットの手数料率に引き上げるために必要な手数料）、 その実効値を差し引きします。その後はこれまでと同様にコインを選択します。 ➚

  • このPRでは、重複する先祖を持つ未承認UTXOの使用をどう処理しますか？

    コイン選択の後、各コイン選択の結果についてMiniMinerアルゴリズムを実行し、 正確な引き上げ手数料を得ます。先祖を共有しているため過剰な引き上げをしている場合、 お釣り用のアウトプットがある場合はそのお釣りに追加し、ない場合はお釣り用のアウトプットを追加して手数料を削減します。 ➚

リリースとリリース候補

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

  • ● BTCPay Server 1.7.1は、最も広く利用されているセルフホスト型のBitcoinのペイメントプロセッサソフトウェアの最新リリースです。

  • ● Core Lightning 22.11は、CLNの次期メジャーバージョンです。 また、新しいバージョン番号方式1を使用した最初のリリースでもあります。 いくつかの新しい機能と、新しいプラグインマネージャー、複数のバグ修正が含まれています。

  • ● LND 0.15.5-betaは、LNDのメンテナンスリリースです。 リリースノートによると、マイナーなバグ修正のみが含まれています。

  • ● BDK 0.25.0は、ウォレット構築用のこのライブラリの新しいリリースです。

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

今週の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 #19762は、RPC（および、拡張によりbitcoin-cli）インターフェースを更新し、 名前付き引数と位置ベースの引数を一緒に使用できるようになりました。この変更により、 すべてのパラメーターに名前を付けることなく、名前付きパラメーターを使用するのが便利になります。 PRの説明では、このアプローチにより利便性の向上を示す例と、 bitcoin-cliを頻繁に使用するユーザー向けの便利なシェルエイリアスを提供しています。

  • ● Core Lightning #5722は、GRPCインターフェースプラグインの使用方法のドキュメントを追加しました。

  • ● Eclair #2513は、Bitcoin Coreウォレットの使用方法を更新し、常にP2WPKHにお釣りを送信するようになりました。 これはBitcoin Core #23789の結果で（ニュースレター #181参照）、 新しいアウトプットタイプ（Taprootなど）の採用者のプライバシーの懸念に対処するためのものです。 これまでは、ウォレットのデフォルトアドレスタイプをTaprootに設定したユーザーは、 誰かに支払いをする際にTaprootのお釣り用アウトプットも作成していました。 Taprootを使用しない人に支払う場合、第三者がどれが支払いのアウトプット（非Taprootアウトプット）で どれがお釣りのアウトプット（Taprootアウトプット）なのか簡単に判別することができました。 Bitcoin Coreの変更後は、支払いに使用されたアウトプットと同じタイプがお釣り用のアウトプットとして使用するのがデフォルトになります。 例えば、ネイティブSegwitアウトプットへの支払いでは、ネイティブSegwitのお釣り用アウトプットが作られます。

    しかし、LNプロトコルは特定のアウトプットタイプを使用します。例えば、 P2PKHアウトプットはLNチャネルを開くのに使用することはできません。 この理由から、Bitcoin CoreのEclairユーザーは、LNと互換性のないタイプのお釣り用アウトプットを生成しないようにする必要があります。

  • ● Rust Bitcoin #1415は、RustのBitcoinのコードのいくつかの特性を証明するために、 Kani Rust Verifierを使用するようになりました。これはFuzzingのような、 コードに対して実行される他の継続的インテグレーションテストを補完するものです。

  • ● BTCPay Server #4238は BTCPayのGreenfield APIに、元のBitPayにインスパイアされたAPIとは異なる、インボイスの払い戻しエンドポイントを追加しました。

脚注

  1. 以前のニュースレターでは、Core Lightningはセマンティックバージョンを使用しており、 新しいバージョンでもその方式を継続的に使用するとしていました。 Rusty Russellは、CLNがその方式に完全に準拠できない理由を説明しました。 以前の誤りについて指摘してくれたMatt Whitlockに感謝します。 ↩