今週のニュースレターでは、FROSTスクリプトレス閾値署名スキーム用の分散鍵生成プロトコルと、 クラスターリニアライゼーションの包括的な紹介のリンクを掲載しています。また、 クライアントやサービスおよび人気のBitcoinインフラストラクチャプロジェクトの最近の変更など 恒例のセクションも含まれています。

ニュース

  • ● FROST用の分散鍵生成プロトコル: Tim RuffingとJonas Nickは、 BitcoinのSchnorr署名と互換性のある FROSTスタイルのスクリプトレスな閾値署名で使用する鍵を 安全に生成するためのプロトコルであるChillDKGの参照実装を含むBIPドラフトを Bitcoin-Devメーリングリストに投稿しました。

    スクリプトレスな閾値署名は、n個の鍵を生成し、そのうちの任意のt個を使用して有効な署名を作成することができます。 たとえば、2-of-3のスキームでは、3個の鍵が作成され、そのうちの2つを使用して有効な署名を生成することができます。 スクリプトレスであるため、このスキームは、Bitcoinに組み込まれているスクリプト化された閾値署名演算（OP_CHECKMULTISIGの使用など）とは異なり、 コンセンサスやブロックチェーンの外部の演算に完全に依存します。

    通常のBitcoinの秘密鍵の生成と同様に、スクリプトレスな閾値署名の鍵を生成する各ユーザーは、 巨大なランダムな数値を生成し、その数値を他の人に開示してはいけません。 ただ、各ユーザーは、その数値の導出シェアを他のユーザーに配布し、 その鍵が利用できない場合に、閾値分の数のユーザーが署名を作成できるようにする必要があります。 各ユーザーは、他のすべてのユーザーから受け取った情報が正しく生成されたことを検証する必要があります。 これらの手順を実行するための鍵生成プロトコルはいくつか存在しますが、 鍵を生成するユーザーが、個々のユーザーペア間で暗号化および認証され、 かつ各ユーザーから他の全ユーザーへの検閲不能な認証済みブロードキャストも可能な通信チャネルにアクセスできることを前提としています。 ChillDKGプロトコルは、FROSTのよく知られた鍵生成アルゴリズムと、追加の最新の暗号プリミティブおよび単純なアルゴリズムを組み合わせて、 必要な安全で認証された、検閲されていないことが証明可能な通信を提供します。

    参加者間の暗号化と認証は、楕円曲線ディフィー・ヘルマン（ECDH）鍵交換から始まります。 検閲されていないことの証明は、各参加者がベースの鍵を使用して、 セッションの開始からスクリプトレスな閾値公開鍵が生成される（セッションの終了）までの記録に署名することで得られます。 閾値公開鍵を正しいものとして受け入れる前に、各参加者は他のすべての参加者の署名済みセッション記録を検証します。

    目標は、FROSTベースのスクリプトレスな閾値署名の鍵を生成する必要があるすべてのケースで使用できる、 完全に汎用化されたプロトコルを提供することです。さらに、このプロトコルは、 バックアップをシンプルに保つのに役立ちます。ユーザーに必要なのは、秘密のシードと、 セキュリティ上重要ではない（ただしプライバシーには影響がある）リカバリーデータのみです。 フォローアップのメッセージで、Jonas Nickは、 シードから導出した鍵でリカバリーデータを暗号化するようプロトコルを拡張することを検討していると述べました。 これにより、ユーザーが秘密にしておく必要があるデータはシードのみになります。

  • ● クラスターリニアライゼーションの導入: Pieter Wuilleは、 クラスターmempoolの基礎となる クラスターリニアライゼーションの主要部分のすべての詳細な説明をDelving Bitcoinに投稿しました。 以前のOptechのニュースレターでは、重要なコンセプトが開発され公開されるにつれてこのテーマを紹介しようとしましたが、 この概要はとても包括的です。基本的なコンセプトから実装されている特定のアルゴリズムまで、読者に順を追って説明しています。 最後に、クラスターmempoolの一部を実装しているいくつかのBitcoin Coreのプルリクエストのリンクが掲載されています。

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

この毎月の特集では、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 InquisitionおよびBINANAsの注目すべき変更点。

  • ● Bitcoin Core #26596では、レガシーウォレットをディスクリプターウォレットに移行するために 新しい読み取り専用のレガシーデータベースを使用します。この変更によって、レガシーウォレットや 従来のBerkeleyDatabaseが廃止されることはありません。 移行のためにレガシーウォレットをロードするのに必要な必須データと関数のみを含む新しいLegacyDataSPKMクラスが作成されました。 BerkeleyRODatabaseの導入については、ニュースレター#305をご覧ください。

  • ● Core Lightning #7455は、short_channel_id（SCID）とnode_idの両方による転送を実装することで、 connectdのOnionメッセージの処理を強化しました（LDKに対する同様の変更については、 ニュースレター #307をご覧ください）。 Onionメッセージは、常に有効になり、受信メッセージは1秒あたり4件に制限されます。

  • ● Eclair #2878では、ルートブラインド機能とチャネル静止機能がオプションになりました。 これは、これらの機能が完全に実装され、BOLT仕様の一部となったためです（ニュースレター#245および#309参照）。 Eclairノードは、これらの機能のサポートをピアに通知しますが、 トランポリンルーティングを使用しないブラインドペイメントを転送しないため、 route_blindingはデフォルトでは無効になっています。

  • ● Rust Bitcoin #2646では、スクリプトおよびwitnessの構造に対する新しいインスペクターがいくつか導入されました。 P2SHの使用に関するBIP16のルールへの準拠を確認するredeem_scriptや、 BIP341ルールへの準拠を確認するためのtaproot_control_blockおよびtaproot_annex、 P2WSHのwitness scriptがBIP141ルールに準拠していることを確認するためのwitness_scriptなどです。 ニュースレター#309をご覧ください。

  • ● BDK #1489では、SPV（Simplified Payment Verification）に対してマークルプルーフを使用するようbdk_electrumが更新されました。 トランザクションと共にマークルプルーフとブロックヘッダーを取得し、 アンカーを挿入する前にトランザクションが承認済みのブロック内にあることを検証し、 full_scanから再編成の処理を削除します。このPRではまた、 以前の型に代わる新しいアンカー型としてConfirmationBlockTimeが導入されています。

  • ● BIPs #1599では、JoinMarketスタイルのCoinjoinのマーケットマッチングで使用するFidelity bondに使用されるタイムロックされたアドレスを作成する HDウォレットの導出スキームのためのBIP46を追加しました。Fidelity bondは、ビットコインをタイムロックすることで メイカーが意図的に資金の時間的価値を犠牲にしていることを証明するレピュテーションシステムを作成し、プロトコルのシビル耐性を向上させます。

  • ● BOLTs #1173は、失敗のOnionメッセージ内のchannel_updateフィールドをオプションにしました。 ノードは、HTLC送信者の識別を防止するために、現在の支払い以外ではこのフィールドを無視するようになりました。 この変更は、古いゴシップデータを持つノードが必要に応じて更新の恩恵を受けられるようにしつつ、 古いチャネルパラメーターによる支払いの遅延を抑制することを目的としています。

  • ● BLIPs #25は、エンコードされたOnionの値よりも低い金額を支払うHTLCの転送を許可する方法を定義するBLIP25を追加しました。 たとえば、アリスはボブにライトニングインボイスを提供しますが、ペイメントチャネルを持っていないため、 ボブが支払う際、（アリスのLSPである）キャロルがその場でチャネルを作成します。 JITチャネルを作成する最初のオンチェーン手数料のコストをカバーするのに、 キャロルがアリスから手数料を取れるようにするためにこのプロトコルが使用され、 アリスにはOnionの値よりも少ない金額を支払うHTLCが転送されます。LDKでのこの実装に関する以前の議論については、 ニュースレター #257をご覧ください。