今週のニュースレターでは、Bitcoin Core PR Review Clubの概要や、 新しいソフトウェアリリースおよびリリース候補のリスト、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点など、恒例のセクションを掲載しています。

ニュース

今週は重要なニュースはありませんでした。

Bitcoin Core PR Review Club

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

Reduce bandwidth during initial headers sync when a block is foundは、 Suhas DaftuarによるPRで、Initial Block Download（IBD）のピアを含む、 ピアとのブロックチェーンの同期中のノードのネットワーク帯域幅要件を削減するものです。 Bitcoinの重要な特徴の一部は、ネットワークリソースを含む完全な検証ノードを実行する際のリソース要件を最小限に抑え、 より多くのユーザーにフルノードの実行を奨励することです。同期時間の高速化はこの目標も推進します。

ブロックチェーンの同期は2つのフェーズで実行されます。まず、 ノードはピアからブロックヘッダーを受信します。このヘッダーは（おそらく）ベストチェーン（最も計算量の多いチェーン）を決定するのに十分です。 続いて、ノードはこのベストチェーンのヘッダーを使用して、対応する完全なブロックをダウンロードします。 このPRは、最初のフェーズ（ヘッダーのダウンロード）にのみ影響します。

• ノードがヘッダーの通知を優先するよう指示したにも関わらず（BIP 130）、初期のヘッダー同期中に（ほとんどの）ノードがinvでブロックの通知を受信するのはなぜですか？

  ノードがheadersメッセージを使用してピアに新しいブロックを通知しないのは、 ピアが新しいヘッダーの接続先をそれまで送信しておらず、同期ノードがheadersメッセージを送信していない場合です。 ➚

• ヘッダーの同期ピアとしてinvでブロックを通知するすべてのピアを追加することで、（初期のヘッダー同期中の）帯域幅が浪費されるのはなぜですか？

  これらのピアは、同じヘッダーのストリームの送信を始めます。 invは同じピアへのgetheadersをトリガーし、その応答のheadersは、そのブロックヘッダーの直後の範囲に対する別のgetheadersをトリガーします。 重複するヘッダーを受信しても、帯域幅を余計に消費する以外は無害です。 ➚

• どの程度の帯域幅が浪費されているか（上限/下限）の推定値は？

  上限は、(number_peers - 1) * number_blocks * 81バイトで、 下限はゼロです（ヘッダーの同期中に新しいブロックが届かない場合。同期ピアとネットワークが高速な場合、70万以上のヘッダーをすべてダウンロードするのに数分しかかかりません）。  ➚

• CNodeStateのメンバーfSyncStartedとm_headers_sync_timeoutおよびPeerManagerImpl::nSyncStartedは何のためのものですか？ invを使用してブロックを通知するピアとヘッダーの同期を始めた場合に、 nSyncStartedを増加させ、fSyncStarted = trueをセットしm_headers_sync_timeoutを更新しないのは何故ですか？

  nSyncStartedは、fSyncStartedがtrueのピアの数をカウントし、 この数はノード現在時刻に近いヘッダー（1日以内）を持つまで1より大きくなることはありません。 この（任意の）ピアが、最初のヘッダー同期ピアになります。 このピアが遅い場合、ノードはそのピアをタイムアウトさせ（m_headers_sync_timeout）、別の初期ヘッダー同期ピアを探します。 しかし、ヘッダーの同期中にあるノードがブロックを通知するinvメッセージを送信すると、 このPRがなければ、ノードはfSyncStartedフラグをセットせずに、このピアへのheadersの要求を開始します。 これは冗長なheadersメッセージの原因であり、おそらく意図したものではありませんが、 最初のヘッダー同期ピアに悪意があったり、壊れていたり、または遅い場合でもヘッダーの同期を続行できるというメリットがあります。 このPRでは、ノードは（新しいブロックを通知したピアすべてに対してではなく）1つのピアに対してのみheadersを要求します。 ➚

• PRで採用されたアプローチの代替案は、タイムアウト（固定もしくはランダム）後にヘッダー同期ピアを追加するというものでした。 この代替案に対するPRで採用されたアプローチの利点は何ですか？

  1つの利点は、invを通知するピアが応答する確率が高くなることです。もう1つは、 ブロックのinvを最初に送信できたピアは、多くの場合とても高速なピアです。 そのため、何らかの理由で最初のピアが遅い場合に、別の遅いピアを選ぶことがありません。 

リリースとリリース候補

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

• ● LDK 0.0.111は、Onionメッセージの作成、受信、リレーのサポートに加えて、 いくつかの新機能およびバグ修正を追加しています。

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

今週の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 #25614は、Bitcoin Core #24464に基づいて、 addrdb、addrman、banman、i2p、mempool、netbase、net、net_processing、 timedataおよびtorcontrolで特定の重大レベルのログを追加して追跡できるようになりました。

• ● Bitcoin Core #25768は、ウォレットが常に未承認トランザクションの子トランザクションを再ブロードキャストしないバグを修正しました。 Bitcoin Coreの組み込みウォレットは、まだ承認されていないトランザクションを定期的に再ブロードキャストしようとします。 これらのトランザクションのいくつかは、他の未承認トランザクションのアウトプットを使用している可能性があります。 Bitcoin Coreは、子トランザクションより前に未承認の親トランザクション（または、より一般的にはすべて子孫の前に未承認の祖先）を 受け取ることを期待する別のBitcoin Coreサブシステムに送信する前にトランザクションの順序をランダム化していました。 その結果、子トランザクションが親より前に受信されると、再ブロードキャストされるのではなく内部的に拒否されます。

• ● Bitcoin Core #19602は、ウォレットをネイティブでディスクリプターを使用するウォレットに変換するmigratewallet RPCを追加しました。 これは、HDウォレット以前のウォレット（BIP32が定義されたがBitcoin Coreに採用される前に作られたもの）やHDウォレットおよび秘密鍵のない監視専用ウォレットに対して動作します。 この機能を実行する前に、ドキュメントを読み、 非ディスクリプターウォレットとネイティブでディスクリプターをサポートするウォレットの間にいくつかのAPIの違いがあることに注意してください。

• ● Eclair #2406は、実験的な対話型のファンディングプロトコルの実装を構成するためのオプションを追加し、 チャネルを開設するトランザクションに承認済みのインプット（承認済みトランザクションのアウトプットをインプットとする）のみを含めるよう要求します。 これを有効にすると、チャネル開設者が低手数料率の巨大な未承認トランザクションでチャネルの開設を遅延させるのを防止します。

• ● Eclair #2190は、BOLTs #962でLNの仕様からの削除が提案されている、元の固定長のOnionデータフォーマットのサポートを削除しました。 アップグレードされた可変長のフォーマットは、3年以上前に仕様に追加され、 ネットワークのスキャン結果では17,000以上の公開ノードのうち、5つを除くすべてのノードでサポートされていることが示されています。 また、Core Lightningも今年初めにサポートを終了しています（ニュースレター #193参照）。

• ● Rust Bitcoin #1196は、以前追加されたLockTime型（ニュースレター #211参照）を absolute::LockTimeに変更し、BIP68およびBIP112を使用するロックタイムを表現する新しいrelative::LockTimeを追加しました。