今週のニュースレターでは、マイニングプールの難易度コントローラーが処理の遅いマイナーを取り残してしまう問題の分析と、 Utreexoの初期ブロックダウンロードに対する改善提案や、使用不可能なTaproot内部鍵を指定するためのBIPドラフトのリンクを掲載しています。 また、サービスやクライアントソフトウェアの最近の更新、新しいリリースとリリース候補の発表、 人気のあるBitcoin基盤ソフトウェアの注目すべき更新など恒例のセクションも含まれています。

ニュース

  • ● 処理速度の低下したマイナーを取り残すVardiffコントローラー: Eric Priceは、マイニングプールが速度の落ちたマイナーに対してどのように難易度を調整するかについての分析を Delving Bitcoinに投稿しました。プールは各マイナーにシェア難易度を割り当てます。 これはネットワークの難易度より低いターゲットで、ブロックヘッダー候補がシェアとして提出されるために満たすべきものです。 可変難易度（vardiff）コントローラーと呼ばれるソフトウェアが、プール内またはマイナーとプールの間のプロキシとして動作し、 マイナーのシェアの到着速度に基づいてその難易度を増減させ、安定したレートを目指します。処理速度が低下したマイナーは、 以前の速度向けに設定された難易度のままになるため、生成するシェアが少なくなります。 シェアが到着したときにのみ更新するコントローラーは、この速度低下に気づけない可能性があります。

    Priceは、コントローラーのパラメータを調整してもこの問題は解決できないと主張しています。 コントローラーは到着しないシェアからレートを推定できないためです。 シェアが到着したときにのみ再計算するコントローラーは、難易度を無期限に高すぎる状態に保ってしまう可能性があります。 彼の修正案は、マイナーからのシェアがないまま一定の間隔が経過するたびに難易度を下げるタイマー機能です。 Stratum v2のリファレンス実装はすでにこれを行っていますが、長期間接続を維持しているマイナーに対する回復が遅いという課題があります。 一方、Ckpoolはシェアの到着時にのみ再計算します。彼は、 マイナーのシェアの一部を破棄するシェーピングプロキシをリリースし、 運営者が自分のプールが難易度を適切に下げるかどうかをテストできるようにしました。

    Anthony Townsは、Stratum v2およびDATUMのデプロイメントで使用されるローカルプロキシ またはゲートウェイでこの問題を処理することを提案しました。 たとえばシェアなしで30秒経過した後に接続の難易度を半減させるといった方法です。Priceもこれに同意し、 別のスレッドで、マイナーごとの制御は各マイナーのシェアを直接確認できる 最後のホップに置かれなければならないと主張しました。

  • ● Utreexoの初期ブロックダウンロードの改善: Davidson Souzaは、 初期ブロックダウンロード（IBD）中のUtreexoのパフォーマンスを改善する方法についてDelving Bitcoinに投稿しました。 Utreexoは、UTXOセットを完全なマークルツリーのフォレスト（集合体）として表現する動的アキュムレータで、 ノードはツリーのルートのみを保存すればよい仕組みです。 各トランザクションの検証に包含証明を添付する必要があるため帯域幅は増加するものの、 その代わりに検証ノードのストレージ要件を削減することを目的としています。 各包含証明のサイズは関連するブロックと同程度であるため、合計のデータ要件は約1.3TBになります。 最近使用されたUTXOを広範にキャッシュしても、明示的な削除のための証明データは約200GBに達します。 この提案はIBD中に削除証明を必要としないようにすることで、証明のオーバーヘッドをほぼゼロにします。

    現在BIPs #1923で議論されているBIP181によると、Utreexoにはツリーへのアウトプットの追加と削除の両方を行うmodify操作があります。 前者は破棄と移動のサイクルを活用する複数ステップのプロセスに従い、後者はツリーのノードを削除し、 その兄弟ノードを親があった位置に移動することで動作します。Souzaと他の開発者は、 追加操作に暗黙的な削除を含めるように変更することを提案しました。あるUTXOが使用済みであることを事前に知っていれば、 それをツリーに追加するのを避け、削除操作と同様にルートを直接ツリーの上方に押し上げるだけで済むからです。

    重要なポイントのひとつは、どのUTXOがすでに使用済みかをどのように知るかです。 Souzaの提案はSwiftSyncのhintsfileを活用します。 これはまさに使用済みアウトプットを追跡することを目的としたファイルで、 提供されたファイルが正しいかどうかを確認するためのハッシュの集約値も保持しています。つまり、 この暗黙的な削除操作はIBD中にのみ利用可能で、それ以降はUtreexoクライアントは通常の追加および削除操作に戻ることになります。 assumevalid版のSwiftSync実装は現在Floresta #1115で開発中で、非assumevalid版も活発に開発されています。

  • ● 使用不可能な内部鍵のための新しいBIPドラフト: NTLは、 Taprootのキーパスを使用不可能にする方法を規定する新しいBIPドラフトの提案について Bitcoin-Devメーリングリストに投稿しました。この新しい仕様は、Salvatore Ingala、Pieter Wuille、 Josie Bakerおよび他の開発者の間でDelving Bitcoin上で行われた以前の議論（ニュースレター #283参照）と、 Andrew TothがBIPs #1746で専用のBIPを定義しようとした以前の試み（ニュースレター #338参照）に基づいています。

    この提案はすでにドラフトとして利用可能で、 既知の署名鍵が存在しない内部鍵のプレースホルダーとして_を規定しています。また、 内部鍵はBIP341のNothing Up My Sleeve（NUMS）ポイント（離散対数が不明なポイント）と、 正規化されたポリシーのタグ付きハッシュであるチェーンコードを用いて、 合成的なBIP32拡張公開鍵から導出されなければならないと規定しており、 これにより異なる実装が独立して同じアドレスを再現できるようになります。

    著者によると、新しい提案は3つの指針に従っています。この特定の問題に直接影響する場合を除いて他のBIPへの準拠を強制しないこと、 新しい暗号技術や構造を提案せず、すでに利用可能なもののみを使用すること、そしてスクリプトのセマンティックな正規化を主張しないことです。

サービスとクライアントソフトウェアの更新

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

  • ● BitBoxAppがSparkベースのライトニング支払いを追加: BitBoxは、Breez SDKとSparkのステートチェーン上に構築された、 モバイル版BitBoxApp 4.52.0のパブリックベータ版ホットウォレットを発表しました。

  • ● Covenants.diyスクリプトエディタ: covenants.diyは、コベナンツスクリプトを構築し、 その実行をブラウザ内でステップ実行するためのエディタです。OP_CTV、 OP_CSFS、OP_CAT、 ANYPREVOUT、OP_TEMPLATEHASH、OP_INTERNALKEY、OP_PAIRCOMMIT、 OP_TXHASHなどの機能をサポートしており、テストネットワークでの使用を想定しています。

  • ● EntropyLabオフライン鍵計算ツール: EntropyLabは、エアギャップ環境での使用向けの自己完結型HTMLファイルで、 ユーザーが提供したエントロピーや既存の鍵素材を、BIP39シード、拡張鍵、 ディスクリプター、アドレス、BIP85子エントロピー、 BIP352のサイレントペイメントアドレスなどに変換します。

リリースとリリース候補

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

  • ● Eclair 0.14.3は、このLNノード実装のセキュリティリリースで、 悪意のあるピアによって悪用可能な脆弱性を修正しており、アップグレードを強く推奨します。 チャネルの閉鎖、スプライシング、オンザフライファンディングに関する問題を修正しています。 また、以下の注目すべき変更で説明されているとおり、ファンディング手数料率に設定可能な上限を追加し、 トランポリンノードが支払いの成功率を高めるためにより低い手数料を保持できるようにしています。

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

最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、Lightning BLIPs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • ● Bitcoin Core #35445は、h形式の強化導出マーカーを使用するminiscript式を含む 既存のディスクリプターウォレットが、 バージョン31.0へのアップグレード後に読み込めなくなる互換性バグを修正します。 以前の変更である#31734は、 内部ディスクリプター識別子を計算する際のBitcoin Coreによる強化導出パスの表現方法を変更しており、 新しいソフトウェアが既存のウォレットを誤って破損していると報告する原因となっていました。保存された識別子は、 再計算して検証する値としてではなく、関連するウォレットレコード間のリンクとして扱われるようになりました。 importdescriptorsおよびcreatewalletdescriptor RPCは、 ディスクリプタがすでに存在するかどうかを確認する際に、正規化されたディスクリプター文字列を比較するようになりました。

  • ● Bitcoin Core #36076は、PSBTを結合する際にcombinepsbtが インプットの要求された署名ハッシュ（sighash）タイプを破棄してしまう可能性があるバグを修正します。 最初のPSBTにPSBT_IN_SIGHASH_TYPEが含まれていない場合、別のPSBTからの署名がそのフィールドなしでコピーされ、 ALL|ANYONECANPAYのようなデフォルト以外のsighashタイプを使用する有効な署名がファイナライズ時に拒否される可能性がありました。 最初のPSBTにこのフィールドがない場合はコピーされるようになり、引数の順序に関係なくファイナライズできるようになりました。

  • ● Bitcoin Core #36150は、プルーニングを新しいコンパクトブロックフィルターインデックス（-blockfilterindex） またはUTXOセット統計インデックス（-coinstatsindex）（ニュースレター #198参照）と一緒に有効にすると、 インデックスが同期できなくなる可能性があるバグを修正します。 プルーニングされていないノードが両方の設定を有効にして再起動された場合、 新しいインデックスがどのブロックが必要かを判断する前にブロックファイルがプルーニングされる可能性がありました。 現在は、インデックスは最初のブロックを処理する前であっても、高さ0にプルーニングロックを設定します。

  • ● Bitcoin Core #36174は、置き換え後のHTTPサーバー（ニュースレター #411参照）に 送信側のバックプレッシャーを追加し、ニュースレター #422で説明された受信側の保護を補完します。 これまでは、クライアントがレスポンスを読み取らずに多数のリクエストを送信でき、 キューに入ったレスポンスデータが際限なく増大する可能性がありました。現在は、 サーバーは接続の送信バッファが32 MiBを超えるとその接続のさらなるリクエストの処理を一時停止し、 クライアントがレスポンスを消化すると再開します。以前の修正は、受信リクエストが処理できる速度よりも速く蓄積するのを防ぐものでした。

  • ● Bitcoin Core #34743は、IBD中にブロックダウンロードを停滞させた手動選択ピアの処理方法を変更します（ニュースレター #237参照）。 これまでは、ピアがブロックの配信に失敗し、それなしではダウンロードが進行できない場合、 ノードはそのピアを切断していました。現在は、-addnode、-connect、またはaddnode RPCを使用して選択されたピアについては、ノードはそれらの未処理のブロックを他のピアからリクエストできるようにし、 停滞しているピアへの新しいブロックリクエストを2分間一時停止します。手動ピアは引き続き、 個別のブロックダウンロードおよびヘッダー同期のタイムアウトの対象となります。

  • ● Bitcoin Core #36081は、getmininginfo RPCのレスポンスにbestblockhashフィールドを追加します。 既存のnextオブジェクト（ニュースレター #339参照）と合わせて、 マイニングソフトウェアは現在の先端のハッシュと次のブロックの難易度ターゲットを単一のRPC呼び出しで取得できるようになります。 これまでは、別々のRPC呼び出しでハッシュとマイニング情報を取得すると、先端の変更と競合し、異なる先端を参照する値が生成される可能性がありました。

  • ● Bitcoin Core #35975は、同じトランザクションの2つの改変バージョンに対してbumpfeeを呼び出した際に発生していた ウォレットのクラッシュを修正します。これまでは、一方のバージョンの手数料を引き上げても、 もう一方が置き換え済みとして直ちにマークされませんでした。その後もう一方のバージョンの手数料を引き上げようとすると、 アサーションエラーが発生してノードがクラッシュする可能性がありました。現在は、どちらのバージョンの手数料を引き上げても、 そのすべての改変版が置き換え済みとしてマークされます。すでに置き換えられたバージョンをバンプしようとするとエラーになります。 このPRはまた、コメントと置換に関するメタデータが、 手数料引き上げの置き換えを含む改変されたトランザクションにコピーされ、 ウォレットの再読み込み後も保持されることを保証します。

  • ● BIPs #2241は、ニュースレター #417で以前議論された、 最近のステイルチェーンチップのオプトインリレーを規定するBIP332を追加します。staletipメッセージには、 既知のフォークポイントのブロックハッシュ、ステイルブランチのヘッダーおよび 送信者がステイルチップのブロックデータを提供する意思があるかどうかを示すフラグが含まれます。 ピアはBIP434を使用してサポートをネゴシエートします。 これはニュースレター #410で説明されているとおり、Bitcoin Coreに実装されています。 推奨されるリソース制限には、アナウンスあたり20ヘッダーと1,000ブロックの新しさのウィンドウが含まれます。

  • ● BIPs #2258は、BIP93 codex32を更新し、 チェックサムの長さ制限をチェックする際にプレフィックスの寄与分を含めるようにします。これまでは、 これらのチェックはデータ部分のみをカウントしていたため、 一部の文字列がチェックサムの明示されたエラー検出保証でカバーされる長さを超えることが許容されていました。 仕様とリファレンス実装は現在、完全な展開後の長さを使用してチェックサムを選択および検証します。さらに、 このPRはマスターシードのエンコーディングを16、20、24、28、32、または64バイトのシードに制限し、 誤って挿入または削除された文字を訂正する際の曖昧さを軽減します。 これらのサイズの既存のエンコーディングは変更されませんが、 以前は許可されていた他のサイズのエンコーディングはもはや仕様に適合しません。

  • ● Eclair #3380は、キャッシュされたHTTP Basic認証の資格情報を利用したクロスサイトリクエストフォージェリを防ぐため、 WebSocket接続を含め、Originヘッダーを含むAPIリクエストを拒否します。 ブラウザベースのフロントエンドは、Eclairを直接呼び出す代わりに、独自のバックエンドを使用する必要があります。 curlやeclair-cliなどのコマンドラインクライアントは、このヘッダーを設定しない限り影響を受けません。

  • ● Eclair #3376は、チャネルの閉鎖、スプライシング、 オンザフライファンディングに関するいくつかの問題を修正します。 Eclairが手数料を支払う場合、閉鎖手数料のネゴシエーションは、設定された最大閉鎖手数料率を超え、 かつローカルの手数料範囲外にあるピアの提案を拒否するようになりました。これまでは、 ネゴシエーションのフォールバックがローカルのチャネル残高を枯渇させかねない過大な手数料を受け入れる可能性がありました。 未完了のスプライシング中に強制閉鎖する場合、スプライシングの公開に必要なピアの署名が欠けているときは、 Eclairはファンディングトランザクションが完全に署名されている最新のコミットメントを使用するようになりました。 ピアがスプライシングをブロードキャストし、それが先に承認された場合、 Eclairは代わりに新しいファンディングアウトプットを使用するコミットメントで閉鎖します。さらに、 このPRはブラインドパス経由の支払いに対してオンザフライファンディングを実行する前に、 リレー手数料とCLTV expiry deltaをチェックし、 資金の損失につながる可能性のある安全でない転送を防ぎます。このPRは、 新しいon-chain-fees.max-funding-feerate設定（デフォルトは50 sat/vB）を追加し、 チャネル開設とスプライシングのための自動推定される手数料率に上限を設けます。

  • ● Eclair #3372は、トランポリンノードとして動作するEclairノードがより低い手数料を保持できるようにし、 送信者の手数料予算のより多くを下流のルーティングに利用できるようにします。 ルーティングヒントまたはブラインドパスを含む支払いについては、 新しいrelay.fees.min-local-trampoline設定でEclairが保持する最小手数料を定義します。 運営者はこの最小値を標準的な送信チャネル手数料よりも低く設定することで、 受信者のLSP（Lightning Service Provider）が課すものを含む下流の合計手数料が予算を超えてしまう場合でも、 支払いが成功するのを助けることができます。これらのヒントがない支払いは、引き続き通常のローカルチャネルコストを含みます。 さらに、このPRはrelay.fees.min-trampolineで要求されるデフォルトの最小合計手数料予算を、 1 satに転送額の0.01%を加えた値から、2 satsに0.04%を加えた値に引き上げます。

  • ● LND #11163は、外部ソフトウェアが転送を承認または拒否できる フォワードインターセプター（ニュースレター #104参照）を使用している際の、 再送されたHTLCの処理を修正します。ピアの再接続やノードの再起動後、 LNDはすでに転送済みの受信HTLCを再処理することがあります。これまでは、LNDはこれを新しいインターセプションとして扱い、 送信HTLCがまだアクティブであるにもかかわらず、たとえば有効期限が近すぎるなどの理由で拒否する可能性がありました。 現在は、LNDは既存の転送レコードをチェックし、再送されたHTLCが元の支払いの解決まで継続できるようにします。 インターセプターの判断をまだ待っている支払いについては、 LNDは代わりに元の自動失敗期限（ニュースレター #224参照）のままHTLCを保留し、 再送時の2回目の有効期限チェックを回避します。

  • ● BDK #2246および#2263は、 アウトプットの未確定なトランザクション祖先をチェックすることで、 ウォレット残高の分類（ニュースレター #213参照）を改善します。これまでは、 未承認の受信支払いを使用した際のお釣りは、承認待ちの受信トランザクションに依存しているにもかかわらず、 信頼できるものと見なされる可能性がありました。BDKは現在、 その信頼できないステータスを子孫トランザクションに引き継ぎます。新しいclassify_outpoints APIはアウトプットごとの分類を公開し、更新されたbalance APIはアプリケーションがどのトランザクションを信頼できないとするか、 いつトランザクションが確定したと見なすかを個別に定義できるようにします。2つめのPRは、 6承認を要求するなどの確定ルールをアプリケーションが定義するのを助けるために、 ChainPosition::confirmations_lower_boundを追加します。これは承認したブロックを含む保守的な承認数を返し、 未承認のトランザクションや提供された先端より上の承認高さについてはゼロを返します。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 16:30 UTCに Riverside.fmで毎週配信されているBitcoin Optech Recapにご参加ください。 この議論は録画もされ、ポッドキャストページからご覧いただけます。