今週のニュースレターでは、UtreexoのBIPドラフトの発表と、 最小トランザクションリレー手数料率の引き下げに関する継続議論、 mempoolポリシーの相違による問題を軽減するためにノードがブロックテンプレートを共有できるようにする提案を掲載しています。 また、Bitcoin Core PR Review Clubミーティングの概要や、新しいリリースとリリース候補の発表、 人気のBitcoinインフラストラクチャプロジェクトの注目すべき更新など恒例のセクションも含まれています。 さらに、先週のニュースレターの訂正と読者へのお勧めも掲載しています。

ニュース

  • ● UtreexoのBIPドラフトの提案: Calvin Kimは、Tadge DryjaおよびDavidson Souzaと共同で作成した Utreexo検証モデルに関する3つのBIPドラフトをBitcoin-Devメーリングリストに投稿しました。 最初のBIPは、Utreexoアキュムレーターの構造を規定しています。 このアキュムレーターにより、ノードはわずか数KBで、完全なUTXOセットへのコミットメントを簡単に更新、保存できます。 2つめのBIPは、従来の使用済みトランザクションアウトプット（STXO、初期のBitcoin Coreとlibbitcoinで使用）や 未使用トランザクションアウトプット（UTXO：現在のBitcoin Coreで使用）ではなく、 アキュムレーターを使用してフルノードが新しいブロックとトランザクションを検証する方法を規定しています。 3つめのBIPは、Utreexoの検証に必要な追加データの転送を可能にするBitcoinのP2Pプロトコルの変更を規定しています。

    著者たちは概念的なレビューを求めており、今後の進展に基づいてBIPドラフトを更新する予定です。

  • ● 最小リレー手数料率の引き下げに関する議論の続き: Gloria Zhaoは、デフォルトの最小リレー手数料率を 90％引き下げて0.1 sat/vbyteにするという案についてDelving Bitcoinに投稿しました。 彼女は、このアイディアのコンセプトと、他のソフトウェアに与える影響についての議論を促しました。 Bitcoin Core固有の懸念事項については、プリリクエストのリンクを示しました。

  • ● mempoolポリシーの相違による問題を軽減するためのピアのブロックテンプレートの共有: Anthony Townsは、フルノードピアがコンパクトブロックリレー エンコーディングを使って、次のブロック用の現在のテンプレートを定期的に相互に送信する提案を Delving Bitcoinに投稿しました。受信側のピアは、 テンプレート内の不足しているトランザクションを要求でき、それらをローカルのmempoolに追加するか、 キャッシュに格納することができます。これによりmempoolポリシーが異なるピア同士でも、 ポリシーの違いにかかわらずトランザクションを共有できるようになります。 これは以前提案された弱ブロックを使用する方法（ニュースレター #299参照）の代替になります。 Townsは、概念実証の実装も公開しました。

Bitcoin Core PR Review Club

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

Add exportwatchonlywallet RPC to export a watchonly version of a walletは、achow101によるPRで、 監視専用ウォレットの作成に必要な手作業が削減されます。この変更以前は、 importdescriptors RPC呼び出しを入力またはスクリプト化したり、 アドレスラベルをコピーしたりする必要がありました。

公開ディスクリプターに加えて、エクスポートされるものには以下が含まれます:

  • 必要に応じて導出されたxpubを含むキャッシュ（例：強化導出される導出パスの場合）
  • アドレス帳のエントリー、ウォレットフラグ、ユーザーラベル
  • 過去のすべてのウォレットトランザクション（再スキャンは不要）

エクスポートされたウォレットデータベースは、restorewallet RPCを使ってインポートできます。

  • なぜ既存のIsRange()/IsSingleType()情報では、ディスクリプターが監視専用側で 展開可能かどうかを判断できないのですか？ a) 強化導出用のwpkh(xpub/0h/*)パスと b) pkh(pubkey)ディスクリプターについて、CanSelfExpand()のロジックを説明してください。

    IsRange()とIsSingleType()は、強化導出のチェックをしないため不十分でした。 強化導出には監視専用ウォレットでは利用できない秘密鍵が必要になります。 CanSelfExpand()は強化導出パスを再帰的に検索するために追加されました。 強化導出パスが見つかった場合はfalseを返し、監視専用ウォレットがアドレスを導出するには 事前に設定されたキャッシュをエクスポートする必要があることを示します。 pkh(pubkey)ディスクリプターは範囲指定されておらず、導出もないため、 常に自己展開可能です ➚

  • ExportWatchOnlyWalletは、!desc->CanSelfExpand()の場合のみディスクリプターキャッシュをコピーします。 そのキャッシュには具体的に何が格納されていますか？キャッシュが不完全だと、 監視専用ウォレットのアドレス導出にどのような影響がありますか？

    キャッシュには、強化導出パスを持つディスクリプター用のCExtPubKeyオブジェクトが格納されており、 これらは支払い用のウォレットで事前に導出されています。 キャッシュが不完全な場合、監視専用ウォレットは必要な秘密鍵を持たないため、 不足しているアドレスを導出できません。これにより、それらのアドレスに送信されたトランザクションを認識できず、 残高が正しく表示されなくなります。 ➚

  • エクスポーターはcreate_flags = GetWalletFlags() | WALLET_FLAG_DISABLE_PRIVATE_KEYSを設定します。 なぜすべてクリアして新しく始めるのではなく、元のフラグ（例：AVOID_REUSE）を保持するのが重要なのですか？

    フラグを保持することで、支払い用のウォレットと監視専用ウォレット間の動作の一貫性が確保されます。 たとえば、AVOID_REUSEフラグは、どのコインが支払いに利用可能と見なされるかに影響します。 これを保持しないと、監視専用ウォレットがメインとウォレットとは異なる利用可能残高を報告し、 ユーザーに混乱を招くことになります。 ➚

  • なぜエクスポーターは新しいウォレットをブロック0から開始させるのではなく、 ソースウォレットからロケーターを読み取って新しいウォレットにそのまま書き込むのですか？

    ブロックロケーターをコピーすることで、新しい監視専用ウォレットが ブロックチェーンの新しいトランザクションのスキャンを開始する場所を伝え、 完全な再スキャンの必要性を回避します。 ➚

  • マルチシグディスクリプターwsh(multi(2,xpub1,xpub2))を考えてみましょう。 1人の共同署名者が監視専用ウォレットをエクスポートして第三者と共有した場合、 単にディスクリプター文字列を提供する場合と比べて、その第三者はどのような新しい情報を得ますか？

    監視専用ウォレットのデータには、アドレス帳、ウォレットフラグ、 コイン管理ラベルなどの追加のメタデータが含まれています。強化導出ウォレットの場合、 第三者は監視専用ウォレットのエクスポートを通じてのみ、過去および将来のトランザクションに関する情報を取得でききます。 ➚

  • wallet_exported_watchonly.pyでは、なぜテストはオンライン/オフラインのペアで 支払い可能性をチェックする前に、wallet.keypoolrefill(100)を呼び出すのですか？

    keypoolrefill(100)呼び出しは、オフライン（支払い）ウォレットに 強化ディスクリプター用に100個の鍵を事前に導出させ、キャッシュに入力します。 このキャッシュはその後のエクスポートに含まれ、 オンラインの監視専用ウォレットがそれら100個のアドレスを生成できるようになります。 また、オフラインウォレットが署名するPSBTを受信した際に、これらのアドレスを認識できるようになります。 ➚

Optechのお勧め

Bitcoin++ Insiderは、読者から資金提供を受けてBitcoinの技術的なトピックに関するニュースの配信を始めました。 無料の週刊ニュースレター「Last Week in Bitcoin」と 「This Week in Bitcoin Core」は、Optechのニュースレターの定期購読者にとって特に興味深い内容となるでしょう。

リリースとリリース候補

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

  • ● LND v0.19.3-beta.rc1は、この人気のLNノード実装のメンテナンスバージョンのリリース候補で、 「重要なバグ修正」が含まれています。最も注目すべきは、「オプションの移行で[…] ノードのディスクおよびメモリ要件が大幅に削減される」ことです。

  • ● BTCPay Server 2.2.0は、このセルフホスト型ペイメントソリューションのリリースです。 ウォレットポリシーとminiscriptのサポートが追加され、 トランザクション手数料の管理と監視に対する追加サポートが提供され、 その他いくつかの新しい改善とバグ修正も含まれています。

  • ● Bitcoin Core 29.1rc1は、主要なフルノードソフトウェアのメンテナンスバージョンのリリース候補です。

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

最近の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 #32941は、制限を超えた際のOrphanageの自動トリミングを有効にして TxOrphanageのオーバーホール（ニュースレター #364参照）を完了します。 maxorphantxのユーザーに対して、それが廃止されたことを通知する警告も追加します。 このPRは、機会的な1P1C（one-parent-one-child）パッケージリレーを確実なものにします。

  • ● Bitcoin Core #31385は、submitpackage RPCの package-not-child-with-unconfirmed-parentsルールを緩和し、 1P1Cパッケージリレーの使用法を改善します。 パッケージは、ノードのmempoolに既に存在する親を含める必要がなくなりました。

  • ● Bitcoin Core #31244は、BIP390で定義されているMuSig2 ディスクリプターのパースを実装します。 これは、MuSig2集約鍵を持つTaprootアドレスからの受け取りとインプットの使用の際に必要です。

  • ● Bitcoin Core #30635では、helpコマンドの応答に waitfornewblock、waitforblock、waitforblockheight RPCが表示されるようになり、 これらが一般ユーザー向けであることが示されます。またこのPRでは、 waitfornewblock RPCにオプションのcurrent_tip引数が追加され、 現在のチェーンの先端のブロックハッシュを指定することで、競合状態を軽減します。

  • ● Bitcoin Core #28944は、send RPCコマンドおよびsendall RPCコマンドで送信されるトランザクションに、まだ指定されていない場合は、 ランダムな先頭相対ロックタイムを追加することで、 手数料スナイピング防止保護を追加します。

  • ● Eclair #3133は、HTLCエンドースメントの ローカルピアレピュテーションシステム（ニュースレター #363参照）を拡張し、 着信ピアと同様に発信ピアのレビュテーションもスコアリングします。 EclairはHTLCを転送する際に両方向で良いレピュテーションを考慮するようになりましたが、 まだペナルティは実装していません。発信ピアのスコアリングは、 チャネルジャミング攻撃の特定の種類である シンク攻撃（ニュースレター #322参照）を防ぐために必要です。

  • ● LND #10097は、ピアが一度に多くのリクエストを送信した際のデッドロックのリスクを排除するために、 バックログゴシップリクエスト（GossipTimestampRange）用の 非同期なピア毎のキューを導入します。ピアが前のリクエストが完了する前にリクエストを送信した場合、 追加のメッセージは自動的に破棄されます。すべてのピアにわたる同時ワーカー数を制限するために 新しくgossip.filter-concurrency設定（デフォルト5）が追加されます。このPRはまた、 すべてのゴシップレート制限設定の動作を説明するドキュメントも追加しています。

  • ● LND #9625は、ペイメントハッシュを提供することで、ユーザーがキャンセルされた BOLT11インボイス（ニュースレター #33参照）を削除できる deletecanceledinvoice RPCコマンド（および同等のlncli）を追加します。

  • ● Rust Bitcoin #4730は、脆弱なバージョンのBitcoin Core（0.12.1未満）を実行しているピアに、 彼らのアラートシステムが安全でないことを通知する最終アラートメッセージ用の Alert型ラッパーを追加します。satoshiは重要なネットワークイベントをユーザーに通知するために アラートシステムを導入しましたが、最終アラートメッセージを除いて、 バージョン0.12.1で廃止されました。

  • ● BLIPs #55は、モバイルクライアントがLSPからプッシュ通知を受信するために エンドポイント経由でウェブフックに登録する方法を定義するBLIP55を追加します。 このプロトコルは、クライアントが非同期支払いを受信した際に通知を受け取るのに便利で、 最近LDKに実装されました（ニュースレター #365参照）。

訂正

先週のニュースレターで、BIP360 pay to quantum-resistant hash の更新版について、Tim Ruffingが論文で安全性を示した変更を 「まさにこの変更が行われています」と誤って説明していました。 BIP360が実際に行っているのは、SHA256ベースのマークルルート（プラスkeypathの代替）への楕円曲線コミットメントを マークルルートへのSHA256コミットメントに直接置き換えることです。Ruffingの論文が示したのは、 現在使用されているTaprootは、Tapscript言語に量子耐性署名スキームが追加され、 keypath支払いが無効化されれば安全であるということでした。 一方、BIP360は、ウォレットにTaprootの（些細な）変種へのアップグレードを要求し、 その変種からkeypathメカニズムを削除し、そのTapleafで使用されるスクリプト言語に量子耐性署名スキームの追加するものです。 Ruffingの論文はBIP360で提案されたtaprootの変種には適用されませんが、 この変種の安全性（コミットメントとして見た場合）は、マークルツリーの安全性から直接導かれます。

誤りについてお詫び申し上げます。また、私たちのミスについて指摘くださったTim Ruffingに感謝します。