今週のニュースレターでは、Bitcoin Coreや他のノードにおける デフォルトの最小トランザクションリレー手数料率の引き下げに関する議論を掲載しています。 また、Bitcoin Core PR Review Clubの概要や、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など、恒例のセクションも含まれています。

ニュース

  • ● デフォルトの最小トランザクションリレー手数料の引き下げ: Bitcoin Coreは、1 vbyteあたり少なくとも1 satoshi（1 sat/vbyte）の手数料を 支払う個々の未承認トランザクションのみをリレーします。 ノードのmempoolが少なくとも1 sat/vbyte支払うトランザクションでいっぱいになった場合、 より高い手数料を支払う必要があります。手数料率の低いトランザクションであっても、 マイナーによって引き続きブロックに含められ、そのブロックはリレーされます。 他のノードソフトウェアも同様のポリシーを実装しています。

    デフォルトの最小手数料率を引き下げることは、これまでも議論されてきましたが（ニュースレター #3参照）、 Bitcoin Coreにはマージされませんでした。 このトピックは、この数週間で再度議論されるようになりました:

    • ● 個別の変更の有効性: 個別のノードオペレーターがポリシーを変更することがどれほど有効か、 何人かの人々によって議論されました。

    • ● 過去の失敗: デフォルトの手数料率を引き下げようとした過去の試みは、 手数料率を下げることで、いくつかの小さなサービス拒否（DoS）攻撃のコストも削減されるという理由で阻まれたことが言及されました。

    • ● 代替のリレー基準: 特定のデフォルトの基準（デフォルト最小手数料率など）に違反するトランザクションは、 代わりにDoS攻撃のコストがかかるような別の基準を満たすことが提案されました。 たとえば、リレーするトランザクションが適度な量のハッシュキャッシュ形式のProof of Workにコミットするなど。

    この議論は、この記事を書いている時点では明確な結論に至ってはいません。

Bitcoin Core PR Review Club

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

Decouple validation cache initialization from ArgsManagerは、 Carl DongによるPRで、署名とスクリプトキャッシュの初期化からノードの設定ロジックを切り離すもので、 libbitcoinkernelプロジェクトの一部です。

  • ArgsManagerは何をするものですか？なぜ、src/nodeではなくsrc/kernelにあるのですか？

    ArgsManagerは、設定オプション（bitcoin.confやコマンドライン引数）を処理するためのグローバルなデータ構造です。 コンセンサスエンジンには、パラメーター化可能な値（すなわちキャッシュサイズ）が含まれる場合がありますが、 ノードはコンセンサスを維持するためにこのデータ構造を必要とはしません。 むしろ、Bitcoin Core特有の機能として、これらの設定オプションを処理するコードはsrc/nodeに含まれます。 ➚

  • Validationキャッシュとは何ですか？なぜ、src/nodeではなくsrc/kernelにあるのですか？

    新しいブロックが到着した際、検証の中で最も計算量が多いのは、トランザクションのスクリプト（つまり署名）の検証です。 mempoolを保持するノードは、通常これらのトランザクションを既に確認し検証しているため、 ブロックの検証パフォーマンスは、（成功した）スクリプトと署名の検証をキャッシュすることで大幅に向上します。 これらのキャッシュは、コンセンサス・クリティカルなブロック検証コードで必要とされるため、 論理的にはコンセンサスエンジンの一部です。したがって、これらのキャッシュはsrc/kernelにあります。 ➚

  • コンセンサスルールでないものがコンセンサス・クリティカルであるというのはどういう意味ですか？ src/consensusにはすべてのコンセンサス・クリティカルなコードが含まれていますか？

    参加者は、署名検証はコンセンサスルールを強制し、キャッシュ化はそうでないことに同意しました。 しかし、キャッシュするコードに無効な署名を保存してしまうバグがある場合、 そのノードはコンセンサスルールを強制していないことになります。 そのため、署名のキャッシュはコンセンサス・クリティカルとみなされます。 コンセンサスのコードは、まだsrc/kernelやsrc/consensusにはありません。 コンセンサスルールやコンセンサス・クリティカルなコードの多くは、validation.cppにあります。 ➚

  • ある値が存在する背景を理解するための「コードの考古学」ではどんなツールを使っていますか？

    参加者は、git blameやgit log、プルリクエストページに入力するコミットハッシュ、 ファイル表示時のGithubのBlameボタンやGithubの検索バーなど、いくつかのコマンドやツールを挙げました。 ➚

  • このPRでは、signature_cache_bytesとscript_execution_cache_bytesの型をint64_tからsize_tに変更しています。 int64_tとuint64_t、size_tの違いは何で、なぜこれらの値にsize_tを使用するのですか？

    int64_t型とuint64_t型はすべてのプラットフォームおよびコンパイラで64-bit（それぞれ符号付きと符号なし）です。 size_t型は、符号なし整数で、メモリ上のあらゆるオブジェクトの長さ（バイト）を保持できることが保証されており、 そのサイズはシステムに依存します。そのため、size_tは、キャッシュサイズをバイト数として保持するこららの変数に適しています。 ➚

リリースとリリース候補

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

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

今週の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 #25610では、RPCと-walletrbfをデフォルトでRBFにオプトインします。 ニュースレター #208で言及したアップデートに続いて、 ノードオペレーターがノードのトランザクションの置換の振る舞いをデフォルトのオプトインRBF（BIP125）からフルRBFに切り替えられるようにするものです。 デフォルトでのRPCオプトインは、2017年にBitcoin Core #9527で提案され、 主な反対意見は当時の目新しさ、トランザクションをバンブできないこと、GUIにRBFを無効にする機能がないことでした。 これらはその後すべて対処されています。

  • ● Bitcoin Core #24584では、 単一のアウトプットタイプで構成されるインプットのセットを優先してコイン選択するよう修正されました。 これは、混合タイプのインプットのセットが、前のトランザクションのお釣り用のアウトプットを明らかにするシナリオに対処するためのものです。 これは受信者のアウトプットとお釣りのタイプを常に合わせるという、 関連するプライバシーの改善に続くものです（ニュースレター #181参照）。

  • ● Core Lightning #5071は、bookkeeperプラグインを追加しました。 このプラグインは、手数料に使われた金額を追跡する機能を含む、プラグインを実行しているノードによるビットコインの移動記録を提供します。 マージされたPRには、いくつかの新しいRPCコマンドが含まれています。

  • ● BDK #645は、署名するTaprootの支払いパスを指定する方法を追加しました。 以前、BDKは可能であればkeypath支払いに署名し、さらに鍵を持っているscriptpathのリーフにも署名していました。

  • ● BOLTs #911は、LNノードがそのIPアドレスを解決するDNSのホスト名を通知する機能を追加しました。 このアイディアに関する以前の議論は、ニュースレター #167で言及されています。