今週のニュースレターでは、utreexoをサポートするフルノードのベータリリースの発表と、 BIP119 OP_CHECKTEMPLATEVERIFYへの2つの拡張案を掲載しています。 また、新しいリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● utreexodのベータリリース: Calvin Kimは、utreexoをサポートするフルノード utreexodのベータリリースの発表をBitcoin-Devメーリングリストに投稿しました。 utreexoを使用すると、ノードはUTXOセット全体を保存するのではなく、 UTXOセットの状態への小さなコミットメントを保存できるようになります。 たとえば、最小のコミットメントは32バイトで、現在のフルセットは約12GBであるため、 コミットメントは約10億分の1になります。帯域幅を削減するため、utreexoは追加のコミットメントを保存し、 ディスク領域の使用量を増やす可能性がありますが、それでもchainstateは従来のフルノードの約100万分の1のオーダーで小さく保たれます。 古いブロックのプルーニングも行うutreexoノードは、小さな一定量のディスク領域で実行することができます。 一方プルーニングされた通常のフルノードでさえ、chainstateがデバイスのストレージ容量を超えて拡大する可能性があります。

    Kimが投稿したリリースノートでは、このノードがBDKベースのウォレットに加えて、 Electrumパーソナルサーバーのサポートを通じて他の多くのウォレットと互換性があることが示されています。 このノードは、utreexoプルーフのリレーを可能にするP2Pネットワークの拡張機能を備えたトランザクションリレーをサポートします。 通常のutreexoノードとブリッジノードの両方がサポートされています。 通常のutreexoノードは、ディスク領域を節約するためにutreexoコミットメントを使用します。 ブリッジノードは、完全なUTXOステートといくつかの追加データを保存し、 まだutreexoをサポートしていないノードやウォレットで作成されたブロックやトランザクションにutreexoプルーフを添付できます。

    utreexoは、コンセンサスの変更を必要とせず、utreexoノードは非utreexoノードに干渉することはなく 通常のutreexoノードは、他の通常のutreexoノードやブリッジutreexoノードとのみピアになります。

    Kimの発表の中にはいくつかの警告が含まれています。「コードとプロトコルはピアレビューされていません[…] 互換性のない変更が入る可能性があります[…]utreexodはbtcdをベースにしており、そこにコンセンサスの非互換性が存在する可能性はあります。」

  • ● より小さなハッシュと任意のデータコミットメントのためのBIP119の拡張: Jeremy Rubinは、提案中のOP_CHECKTEMPLATEVERIFY (OP_CTV)を 2つの追加機能で拡張するBIPの提案をBitcoin-Devメーリングリストに投稿しました:

    • ● HASH160ハッシュのサポート: P2PKH、P2SH、P2WPKHアドレスに使用されるハッシュダイジェストです。 基本のBIP119の提案で使用される32バイトのハッシュダイジェストと比較すると、これは20バイトです。 単純なマルチパーティプロトコルでは、20バイトのハッシュに対する衝突攻撃は、 約280の総当り演算で実行でき、これは非常にやる気のある攻撃者の手の届く範囲です。 このため、最新のBitcoinのopcodeは、通常32バイトのハッシュダイジェストを使用しています。 しかし、20バイトのハッシュを使用するシングルパーティプロトコルや 適切に設計されたマルチパーティプロトコルのセキュリティは、 約2160未満の総当り演算で侵害される可能性が低くなるよう強化でき、 それらのプロトコルではダイジェスト毎に12バイト節約できます。 これが役に立つ可能性があるケースの1つは、 eltooプロトコル（ニュースレター #284参照）です。

    • ● 追加コミットメントのサポート: OP_CTVは、提供されたハッシュダイジェストと同じ値にハッシュされる インプットとアウトプットを含むトランザクション内で実行される場合にのみ成功します。 これらのアウトプットの1つは、LNのチャネルステートをバックアップからリカバリーするために必要なデータなど、 スクリプトの作成者がブロックチェーンに公開したいデータにコミットするOP_RETURNアウトプットである可能性があります。 しかし、witnessフィールドにデータを置く方がコストは大幅に安くなります。 OP_CTVの提案された更新形式を使用すると、スクリプトの作成者は、 インプットとアウトプットがハッシュされる際に、witnessスタックから追加のデータを含めるよう要求できるようになります。 そのデータはスクリプトの作成者によって提供されたハッシュダイジェストに対してチェックされます。 これにより、ブロックweightを最小限に抑えてデータがブロックチェーンに公開されることが保証されます。

    この提案は、この記事の執筆時点ではメーリングリストでまだ議論されていません。

リリースとリリース候補

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

  • ● LDK v0.0.123は、LN対応アプリケーションを構築するためのこの人気のライブラリのリリースです。 トリムされるHTLCの設定の更新や、オファーのサポートの改善、 その他の多くの改善が含まれています。

  • ● LND v0.18.0-beta.rc2は、この人気のLNノードの次期メジャーバージョンのリリース候補です。

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

今週の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 #29845は、複数のget*info RPCを更新し、 warningsフィールドを文字列から文字列の配列に変更し、1つだけではなく、複数の警告を返せるようにします。

  • ● Core Lightning #7111では、libpluginユーティリティを通じてプラグインで check RPCコマンドを利用できるようになりました。また、設定オプションが受け入れられるか検証する check setconfigを有効にすることで使用法も拡張され、既存のcheck keysendは、 hsmdがトランザクションを承認するかどうかを検証するようになりました。 初期化前メッセージに事前設定されたHSM開発フラグが追加されました。 checkコマンドの詳細については、ニュースレター#25および#47もご覧ください。

  • ● Libsecp256k1 #1518は、公開鍵のセットを辞書順にソートするsecp256k1_pubkey_sort関数を追加しました。 これは、MuSig2やサイレントペイメント、 複数の鍵を必要とする他の多くのプロトコルで役立ちます。

  • ● Rust Bitcoin #2707は、Taprootの一部として導入されたタグ付きハッシュ用のAPIを更新し、 デフォルトで内部バイト順でダイジェストを維持するようになりました。 これまでは、APIはハッシュの表示バイト順を維持していましたが、 これは#[hash_newtype(backward)]のようなコードで取得できるようになります。 歴史的な理由から、txidとブロックの識別子のハッシュダイジェストは、 トランザクションやブロックの内で、あるバイト順（内部バイト順）で表示されますが、 ユーザーインターフェースでは逆順（表示バイト順）で表示および呼び出されます。 このPRは、さまざまな状況で異なるバイト順を持つハッシュがさらに増えることを防ごうとするものです。

  • ● BIPs #1389は、「ディスクリプターウォレットのウォレットポリシー」を定義するBIP388を追加しました。 これは、多くのウォレットがコードとユーザーインターフェースの両方でサポートしやすい アウトプットスクリプトディスクリプターのテンプレート化されたセットです。 特に、リソースや画面のスペースが制限されたハードウェアウォレット上でディスクリプターを実装するのは困難な場合があります。 BIP388のウォレットポリシーにより、これにオプトインしたソフトウェアやハードウェアは、 ディスクリプターの使用方法についての仮定を簡素化することができます。 これによりディスクリプターの範囲が最小限に抑えられ、必要なコードの量とユーザーが検証する必要のある詳細の数を削減します。 ディスクリプターの全機能を必要とするソフトウェアは、BIP388とは独立してディスクリプターを引き続き使用できます。 詳細については、ニュースレター #200をご覧ください。

  • ● BIPs #1567は、Tapscript内でスクリプト化されたマルチシグ機能を提供する 新しいディスクリプターmulti_a()とsortedmultia_a()を追加するBIP387を追加しました。 BIPの例より、multi_a(k,KEY_1,KEY_2,...,KEY_n)というディスクリプターの断片は、 KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD OP_k OP_NUMEQUALというスクリプトを生成します。ニュースレター#191および、 #227、#273もご覧ください。

  • ● BIPs #1525は、ソフトフォークで有効化された場合に Tapscriptで使用できるOP_CAT opcodeを提案するBIP347を追加しました。 ニュースレター#274および#275、#293もご覧ください。

ニュースレター発行日の変更

今後数週間のうちに、Optechは試験的に発行日を変更します。 ニュースレターの受け取りが数日早くなったり遅れたりしても驚かないでください。 短期間の実験期間中、メールのニュースレターには、ニュースレターを読んだ人の数を確認するためのトラッカーが含まれます。 ニュースレターを読む前に、外部リソースの読み込みを無効にすることで、このトラッキングを防ぐことができます。 さらにプライバシーを守りたい場合は、一時的なTor接続を介してRSS feedを購読することをお勧めします。 ご不便をかけて申し訳ありません。