今週のニュースレターでは、提案中のクラスターmempoolに関するいくつかの議論と、 warnetを使用して実行されたテスト結果を掲載しています。 また、Bitcoin Core PR Review Clubミーティングの要約や、 新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • クラスターmempoolの議論: クラスターmempoolに取り組んでいる Bitcoin Core開発者は、Delving Bitcoinフォーラムでワーキンググループ(WG)を開始しました。 クラスターmempoolは、トランザクションの必要な順序を尊重しながら、mempool上の操作をはるかに容易にするための提案です。 Bitcoinトランザクションを有効に順序付けするには、親を子よりも前のブロックに配置するか、 同じブロックで前に配置することで、親トランザクションを子トランザクションよりも先に承認する必要があります。 クラスターmempoolの設計では、1つ以上の関連トランザクションの クラスター が、 手数料率でソートされたチャンクに分割されるように設計されています。 どのチャンクも、それより前の(より手数料率が高い)未承認のチャンクがすべて同じブロックに含まれている限り、 ブロックの最大weightまで、ブロックに含めることができます。

    すべてのトランザクションがクラスターに関連付けられ、クラスターがチャンクに分割されると、 ブロックに含めるトランザクションを選択するのは簡単です。ブロックがいっぱいになるまで、 最も手数料率の高いチャンクを選択し、次はその次に高いチャンクを選択します。 このアルゴリズムを使用すると、mempool内の最も手数料率の低いチャンクが、 ブロックに含まれるチャンクから最も遠いチャンクであることは明白です。 そのため、mempoolがいっぱいになり、一部のトランザクションを排除する必要がある場合には、 逆のアルゴリズムを適用できます。ローカルmempoolが意図した最大サイズを下回るまで、 最も低い手数料率のチャンクを排除し、その次に低いチャンクを排除するということを繰り返します。

    WGのアーカイブは誰でも閲覧できるようになりましたが、投稿できるのは招待されたメンバーのみです。 これまで議論された注目すべきトピックには以下のようなものがあります:

    • クラスターmempoolの定義と理論では、クラスターmempoolの設計で使用される用語を定義しています。 またこの設計の有用な特性の一部を示す少数の定理についても記述しています。 このスレッドの1つの投稿(この記事の執筆時点)は、WGによる他の議論を理解するのにとても役立ちますが、 投稿者(Pieter Wuille)はまだ「非常に不完全」であると警告しています

    • 比較不可能なリニアライザーションのマージでは、 同じトランザクションのセットに対して2つの異なるチャンクのセット(チャンキング)をマージする方法、 特に 比較不可能 なチャンキングについて検討しています。 異なるチャンクのリスト(チャンキング)を比較することで、マイナーにとってどちらがより良いか判断できます。 チャンキングを比較できるのは、その1つが任意のvbyte(チャンクのサイズに応じて異なる)内で 常に同じかそれ以上の手数料を蓄積する場合です。たとえば、

      Comparable chunkings

      チャンキングの一方があるvbyte数内でより多くの手数料を蓄積し、 もう一方のチャンキングがよりvbyte数が多く手数料の蓄積も多い場合は、チャンキングは比較できません。たとえば、

      Incomparable chunkings

      先程のリンクのスレッドの定理の1つでは、「グラフで比較できない2つのチャンキングがある場合、 その両方よりも厳密に優れた別のチャンキングが存在しなければならない」と述べられています。 つまり、2つの異なる比較不可能なチャンキングをマージする効果的な方法は、 マイナーの収益性を向上させる強力なツールになり得るということです。 たとえば、既にmempoolに存在する他のトランザクションに関連する新しいトランザクションを受信した場合、 そのクラスターを更新する必要があり、これはチャンキングも更新する必要があることを意味します。 この更新を行うには、次の2つの異なる方法を両方実行できます:

      1. 更新されたクラスターの新しいチャンキングは最初から計算されます。 大規模なクラスターの場合、最適なチャンキングを見つけるのは計算上、非現実的である可能性があるため、 新しいチャンキングは古いチャンキングほど最適ではない可能性があります。

      2. 以前のクラスターの以前のチャンキングは、新しいトランザクションを有効な場所(子の前に親)に挿入することで更新されます。 これには、変更されていないチャンク内の既存の最適化が保持されるという利点がありますが、 トランザクションを最適でない場所に配置する可能性があるという欠点があります。

      2つの異なるタイプの更新が行われた後、比較するとどちらか一方の方が厳密に優れていることが判明する場合があり、 その場合はそれを使用できます。しかし、更新が比較不可能な場合は、同等以上の結果が得られることが保証されているマージ方法を代わりに使用し、 より良い場合は新しいチャンキングを使用し、最適に近い場合は古いチャンキングを保持することで、 両方のアプローチの最も優れた側面を取る3つめのチャンキングを生成できます。

    • クラスター後のパッケージRBFでは、 Replace by Feeで現在使用されているルールの代替案について議論しています。 1つ以上のトランザクションの有効な置換を受信すると、それが影響するすべてのクラスターの一時的なバージョンが作成され、 更新されたチャンキングが導出されます。これは、現在mempoolにある元のクラスター(置換を含まない)のチャンキングと比較できます。 置換によるチャンキングがvbyte数に対して常に元と同じかそれ以上の手数料を獲得し、 mempool内の総手数料額がリレー手数料を支払うのに十分な量だけ増加する場合、それをmempoolに含めるべきです。

      このエビデンスに基づいた評価は、トランザクションを置き換えるべきかどうかを決定するために Bitcoin Coreで現在使用されているいくつかのヒューリスティックを置き換えることができ、 置換のために提案中のパッケージリレーを含む、いくつかの領域でRBFルールを改善する可能性があります。 他のいくつかのスレッドでもこのトピックについて議論しています。

  • warnetでのテスト: Matthew Zipkinは、warnetを使用して実行したいくつかのシミュレーション結果を Delving Bitcoinに投稿しました。warnetは、(通常はテストネットワーク上で) 定義された接続セットを持つ多数のBitcoinノードを起動するプログラムです。 Zipkinの結果は、ピア管理のコードに対するいくつかの変更案が(独立して、または一緒に)マージされた場合に使用されるであろう 余分なメモリを示しています。彼はまた、他の変更案のテストや提案された攻撃の影響を定量化するためにシミュレーションを使用することが楽しみだと述べています。

Bitcoin Core PR Review Club

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

Testing Bitcoin Core 26.0 Release Candidatesは、 特定のPRをレビューするのではなく、グループテストの取り組みでした。

Bitcoin Coreの各メジャーリリースの前には、 コミュニティによる広範囲なテストが不可欠であると考えられています。 このため、リリース候補のテストガイドをボランティアが作成しています。 これにより、できるだけ多くの人が、リリースの新機能や変更点を個別に確認したり、 これらの機能や変更をテストするためのさまざまなセットアップ手順を再発明したりすることなく、 生産的にテストできるようになります。

予期しない動作に遭遇した際、それが実際のバグによるものか、それともテスターの間違いによるものなのかが不明瞭なことが多いため、 テストが難しくなります。実際のバグではないものを開発者に報告することは時間の無駄です。 これらの問題を軽減し、テスト作業を促進するために、特定のリリース候補(ここでは26.0rc2)に対して Review Clubミーティングが開催されます。

26.0のリリース候補のテストガイドは、Max Edwardsによって書かれ、 彼はまたStéphan (stickies-v)の協力を得てReview Clubミーティングを主催しました。

参加者は、26.0のリリースノートを読むことで、テストのアイディアを得ることが奨励されました。

このReview Clubのセッションでは、 getprioritisedtransactions以前のReview Clubミーティングでも取り上げられましたが、 そのRPCの名前はReview Clubミーティングが開催された後で変更されました)と importmempoolという2つのRPCを取り上げました。 リリースノートの新しいRPCセクションに、これらのRPCやその他追加されたRPCについて記述されています。 ミーティングでは、V2トランスポート(BIP324)についても取り上げられ、 TapMiniscriptについても取り上げる予定でしたが、 このトピックについては時間的な制限から議論されませんでした。

  • どのOSを使用していますか?

    WSL(Windows subsystem for Linux)上でUbuntu 22.04、macOs 13.4 (M1チップ)。 

  • getprioritisedtransactionsのテスト結果はどうでしたか?

    参加者は期待どおりに動作したと報告しましたが、 prioritisetransactionの効果が複合的に作用することに気づいた参加者もいました。 つまり、同じトランザクションで2回実行すると、手数料が2倍になります。 fee引数がトランザクションの既存の優先順位に追加されるため、これは期待される動作です。 

  • importmempoolのテスト結果はどうでしたか?

    ある参加者は、「Can only import the mempool after the block download and sync is done」 というエラーが発生したものの、2分待った後、RPCは成功しました。別の参加者は、完了までに時間がかかると指摘しました。 

  • インポート中にCLIプロセスを中断し(bitcoindを停止せずに)、CLIプロセスを再開するとどうなりますか?

    これは何も問題がないようでした。2つめのインポートリクエストは期待どおりに完了しました。 CLIコマンドが中断された後もインポートプロセスは続行され、 2つめのリクエストによって2つのインポートスレッドが同時に実行されて互いに競合することはなかったようです。 

  • V2トランスポートを実行した結果はどうでしたか?

    参加者は、既知のV2対応ノードに接続できませんでした。 接続要求を受け付けていないようです。すべてのインバウンドスロットが使用されている可能性が示唆されました。 このため、ミーティング中にはP2Pのテストはできませんでした。 

リリースとリリース候補

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

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

今週のBitcoin CoreCore LightningEclairLDKLNDlibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBDKBitcoin Improvement Proposals(BIP)Lightning BOLTsおよび Bitcoin Inquisitionの注目すべき変更点。

  • Bitcoin Core #28848は、トランザクションが失敗した場合に役立つようにsubmitpackage RPCを更新しました。 最初の失敗でJSONRPCErrorを投げるのではなく、可能な限り各トランザクションの結果を返すようになりました。

  • LDK #2540は、LDKの最近のブラインドパスの作業(ニュースレター#257#266参照)に基づき、ブラインドパスのイントロノードとして転送をサポートするもので、 LDKのBOLT12オファーの実装に必要な課題の一部です。