今週のニュースレターは、サイレントペイメントアドレスに有効期限を追加することについての議論と、 サーバーレスPayjoin用のBIPドラフトの概要を掲載しています。 寄稿されたフィールドレポートでは、スクリプトレスマルチシグのためのMuSig2ベースのウォレットの実装と展開について掲載しています。 また、新しいリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● サイレントペイメントアドレスに有効期限メタデータの追加: Peter Toddは、サイレントペイメント用のアドレスにユーザーが選択した有効期限を追加する推奨事項を Bitcoin-Devメーリングリストに投稿しました。 複数の支払いを受け取るのに同じアドレスを使用するとアウトプットがリンクされる 通常のBitcoinアドレスとは異なり、サイレントペイメント用のアドレスは、 適切に使用されるたびに一意のアウトプットスクリプトが生成されます。 これにより、受信者が個別の支払い毎に異なる通常のアドレスを支払人に提供することが不可能または不便な場合に、 プライバシーが大幅に向上します。

    Peter Toddは、すべてのアドレスが期限切れになることが望ましいと指摘しています: ほとんどのユーザーは、ある時点でウォレットの使用を止めるでしょう。 通常のアドレスは一度しか使用されないことが予想されるため、有効期限切れの懸念はそれほどありませんが、 サイレントペイメントでは繰り返し使用されることが予想されるため、有効期限を含めることがより重要になります。 彼は、今から180年後までの有効期限をサポートする2バイトの有効期限か、 約45,000年後までの有効期限をサポートする3バイトの有効期限のいずれかをアドレスに含めることを提案しています。

    この提言は、メーリングリスト上で適度な議論がされましたが、この執筆時点では明確な決着はついていません。

  • ● サーバーレスPayjoin: Dan Gouldは、 サーバーレスPayjoin （ニュースレター #236参照）のBIPドラフトを Bitcoin-Devメーリングリストに投稿しました。 BIP78で定義されているPayjoin自体は、 受信者が支払人からPSBTを安全に受け取るためのサーバーを運用することを想定しています。 Gouldは、受信者がBIP21 URIを使用して、Payjoinの支払いを受け取るために使用したいリレーサーバーと 対称暗号鍵を宣言することから始まる非同期リレーモデルを提案しています。 支払人は、取引のPSBTを暗号化し、受信者の希望するリレーに送信します。 受信者はそのPSBTをダウンロードし、復号し、署名したインプットを追加して暗号化し、再びリレーに送信します。 支払人は変更されたPSBTをダウンロードし、復号し、それが正しいことを確認し、署名しBitcoinネットワークにブロードキャストします。

    返信の中で、Adam Gibsonは、BIP21 URIに暗号鍵を含めることの危険性と、 リレーが受信者と支払人のIPアドレスと、ほぼ同じ時間帯にブロードキャストされた 一連のトランザクションを関連付けることができるプライバシーに対するリスクについて警告しました。 Gouldはその後、暗号鍵に関するGibsonの懸念に対処するために提案を修正しました。

    私たちは、このプロトコルに関する継続的な議論を期待しています。

フィールドレポート: MuSig2の実装

BitGoのBrandon Blackより

最初のMuSigの論文は2018年に発表され、BitcoinにおけるMuSigの可能性は、 Taprootのソフトフォークの支持を得るためのセールスポイントの1つでした。 MuSigの研究は続き、2020年にMuSig-DNとMuSig2が発表されました。 2021年にBitcoinのmainnetでTaprootのアクティベートが近づくにつれ、 MuSig署名をBitcoinユーザーに提供することに対する興奮が高まっていました。 BitGoでは、Taprootのアクティベートと同時にMuSig Taprootウォレットをローンチしたいと考えていましたが、 仕様や、Test Vector、参照実装が不完全でした。 代わりに、BitGoは最初のTapscriptマルチシグウォレットをローンチし、 mainnet上で最初のTapscriptマルチシグトランザクションを作成しました。 それから約2年後、BIP327でMuSig2が定義され、BitGoは最初のTaprootマルチシグウォレットをローンチしました。

MuSig2を使用する理由

スクリプトマルチシグとの比較

MuSigには、スクリプトマルチシグと比べて2つの主な利点があります。 1つは、最も明白な利点で、トランザクションサイズとマイナー手数料の削減です。 オンチェーンの署名は、64-73バイト（16-18.25仮想バイト（vb））で、 MuSigは2つ（またはそれ以上の）署名を1つにまとめることができます。 BitGoの2-of-3の場合、MuSigのキーパスのインプットのコストは57.5vBですが、 ネイティブSegwitのインプットのコストは104.5vB、深さ1のTapscriptのコストは107.5vBです。 MuSigの2つめの利点は、プライバシーの向上です。 MuSigのキーパスで協力的に保持されているアウトプットの場合、 第三者のブロックチェーンの観察者が、その協力的な支払いと単一署名のTaprootの支払いを区別することはできません。

当然ながら、MuSig2には欠点もあります。2つの重要な欠点は、 ナンスに関連するものです。 素のECDSA（楕円曲線デジタル署名アルゴリズム）やSchnorr署名とは異なり、 MuSig2の署名者は一貫して決定論的なナンスを使用することができません。 このため、高品質のナンスを保証したり、ナンスの再利用を確実に防止することがより困難になります。 MuSig2では、ほとんどの場合、2ラウンドの通信が必要です。 最初にナンスを交換し、次に署名します。場合によっては、最初のラウンドを事前に計算できますが、 これは慎重に行わなければなりません。

他のMPCプロトコルとの比較

MPC（マルチパーティ計算）署名プロトコルは、前述の手数料とプライバシーの利点から人気が高まっています。 MuSigはシンプルなマルチシグ（n-of-n）プロトコルであり、これはSchnorr署名の線型性によって実現されています。 MuSig2は30分のプレゼンテーションで説明でき、完全な参照実装はPythonで461行のコードです。 FROSTのような閾値署名（t-of-n）プロトコルはかなり複雑で、 ECDSAベースの2者間のマルチシグでさえPaillier暗号やその他の技術に依存しています。

スクリプトの選択

Taproot以前でさえ、マルチシグ（t-of-n）ウォレット用の特定のスクリプトを選択することは困難でした。 複数の支払いパスを持つTaprootは、さらに問題を複雑にし、MuSigはさらに多くの選択肢を重ねています。 BitGoのTaproot Musig2ウォレットの設計に取り組む際に考慮したいいくつかの点を紹介します:

  • 辞書順のソートではなく、鍵の順序を固定します。各署名鍵には、特定の役割が鍵とともに保存されているため、 毎回同じ順番でこれらの鍵を使用することは簡単で予測可能です。
  • 私たちのMuSigのキーパスには、最も一般的な署名の充足数“user”/“bitgo”のみが含まれています。 ”backup”の署名鍵をキーパスに含めると、その鍵の使用頻度が大幅に低下します。
  • “user”と“bitgo”の署名ペアはTaptreeには含めません。これは2つめのTaprootスクリプトタイプであり、 1つめは3つのTapscript設計であるため、スクリプト署名が必要なユーザーは１つめのタイプを使用できます。
  • Tapscriptの場合、MuSigの鍵を使用しません。当社のウォレットには、”backup”鍵が含まれていますが、 これは当社の管理外のソフトウェアではアクセスや署名が困難である可能性があるため、 “backup”鍵に対してMuSigで署名できることを期待するのは現実的ではありません。
  • Tapscriptの場合、OP_CHECKSIGADDよりもOP_CHECKSIG / OP_CHECKSIGVERIFYスクリプトを選択します。 トランザクションを構築する際に、どの鍵が署名するかは分かっており、2-of-2の深さ1のスクリプトは、 2-of-3の深さ0のスクリプトよりもわずかに安価です。

最終的な構造は以下のようになります:

BitGo's MuSig taproot structure

（決定論的およびランダムな）ナンス

楕円曲線デジタル署名は、ナンス（一度だけ使用される数値）として知られる一時的な秘密の値を使用して生成されます。 公開ナンス（公開鍵と秘密鍵のようにシークレットナンスに対応する公開ナンス）を署名で共有することで、 検証者に有効期間の長い秘密鍵を明らかにすることなく、署名式の正当性を検証することができます。 有効期間の長い秘密鍵を保護するために、同じ（または関連する）秘密鍵とメッセージでナンスを再利用してはなりません。 単一署名の場合、ナンスの再利用を防ぐ最も一般的に推奨される方法は、RFC6979決定論的ナンス生成です。 一様にランダムな値でも、使用後すぐに破棄すれば安全に使用できます。これらの手法はいずれも、 マルチシグプロトコルに直接適用することはできません。

MuSigで決定論的ナンスを安全に使用するには、MuSig-DNのような手法を使用して、 すべての参加者が決定論的ナンスを正しく生成していることを証明する必要があります。 この証明がないと、不正な署名者は同じメッセージに対して2つの署名セッションを開始し、 異なるナンスを提供することができます。決定論的にナンスを生成する別の署名者は、 異なる有効なメッセージに対して同じナンスを使って2つの部分署名を生成します。 これにより、その秘密鍵が不正な署名者に明らかになります。

MuSig2の仕様の開発中、Dawidと私は、最後にナンスを提供する署名者は、 決定論的にナンスを生成できることに気づきました。 これについてJonas Nickと議論し、彼は正式にそれを仕様に取り込みました。 BitGoのMuSig2実装では、この決定論的署名モードは私たちのHSM（ハードウェアセキュリティモジュール）で使用され、 ステートレスにMuSig2署名を実行できるようにしています。

ランダムなナンスを複数ラウンドの署名プロトコルで使用する場合、 署名者はシークレットナンスがラウンド間でどのように保存されるかを考慮する必要があります。 単一署名の場合、シークレットナンスは作成と同じ署名実行中に削除できます。 攻撃者がナンス作成直後に他の署名者がナンスを提供する前に署名者のクローンを作成できる場合、 署名者は騙されて同じナンスで異なる有効なメッセージに対して複数の署名を生成する可能性があります。 このため、署名者は内部状態にどのようにアクセスでき、いつシークレットナンスが削除されるかを慎重に考える必要があります。 BitGoユーザーがBitGo SDKを使用してMuSig2で署名する場合、 シークレットナンスはMuSig-JSライブラリ内に保持され、署名のためのアクセス時に削除されます。

仕様化のプロセス

BitGoでMuSig2を実装した経験から、Bitcoin分野に携わる企業や個人は、 実装を予定している（または望んでいる）仕様の開発を時間をかけてレビューし、貢献する必要があることがわかります。 私たちが最初にMuSig2の仕様をレビューし、それを私たちの署名システムに統合する最善の方法を検討し始めたとき、 私たちのHSMにステートフル署名を導入するためのさまざまな困難な方法を検討しました。

幸いなことに、私が課題をDawidに説明したところ、彼は決定論的ナンスを使用する方法があると確信し、 最終的には、1人の署名者は決定論的であるという大まかなアイデアに落ち着きました。 その後、私がそのアイディアをJonasに提案し、実現しようとしている具体的なユースケースを説明したところ、 彼はその価値を認め、仕様に正式に取り入れたのです。

これで他のMuSig2実装者も、署名者の1人が状態を管理しないことで得られる柔軟性を活用できるようになりました。 仕様策定中にドラフト仕様をレビュー（および実装）することで、私たちは仕様に貢献し、 仕様が正式にBIP327として公開された直後にMuSig2署名をローンチする準備ができました。

MuSigとPSBT

PSBT (Partially Signed Bitcoin Transaction)形式は、 参加者（たとえば、単純な場合はコーディネーターと署名者）間で トランザクションに署名するために必要なすべての情報を伝達することを意図しています。 署名に必要な情報が多いほど、この形式の価値は高まります。 私たちは、MuSig2署名を容易にするために既存のAPI形式にフィールドを追加して拡張する場合と、 PSBTに変換する場合のコストと利点を検討しました。 私たちは、トランザクションデータのやりとりにPSBT形式を採用することに決め、それは大きな成功になりました。 まだ広く知られていませんが、BitGoウォレット（MuSig2を使用するものを除く、次の段落を参照）は、 PSBTをサポートするハードウェア署名デバイスと統合できるようになりました。

MuSig2署名で使用するPSBTフィールドはまだ公開されていません。私たちの実装では、 Sanketによって共有されたドラフトをベースにした独自フィールドを使用しています。 これは、PSBT形式のあまり語られない利点の1つです。カスタムトランザクションの構築や、 署名プロトコルに必要な追加データを、同じバイナリデータ形式で含めることができます。 グローバル、インプット毎、アウトプット毎の各セクションで既に定義されています。 PSBTの仕様では、未署名のトランザクションを、スクリプトや署名および、 最終的に完全なトランザクションを形成するために必要なその他のデータから分離しています。 この分離により、署名プロセス中により効率的な通信が可能になります。たとえば、 私たちのHSMは、ナンスまたは署名のみを含む最小限のPSBTを返し、 それを署名前のPSBTに簡単に組み込むことができます。

謝辞

BlockstreamのJonas NickとSanket Kanjalkar、FediのDawid Ciężarkiewicz、 そしてSaravanan ManiとDavid Kaplan、BitGoのチームの残りのメンバーに感謝します。

リリースとリリース候補

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

  • ● Core Lightning 23.08rc2は、この人気の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の注目すべき変更点。

  • ● Bitcoin Core #27213は、Bitcoin Coreがより多様なネットワーク上のピアとの接続を作成、 維持するのを支援し、状況によってはエクリプス攻撃のリスクを低減します。 エクリプス攻撃は、ノードが1つの誠実なピアにも接続することができず、 ネットワークの他の部分とは異なるブロックのセットを与えることができる不誠実なピアとの接続が残った場合に発生します。 このような攻撃は、ネットワークの他の部分が同意していないにもかかわらず、 特定のトランザクションが承認されたとノードを納得させるために使用することができ、 ノードオペレーターを騙して、決して使用できないビットコインを受け入れるよう仕向ける可能性があります。 接続の多様性を高めることは、小規模ネットワーク上のピアがメインネットワークから分離され、 最新のブロックを受信できなくなるという偶発的なネットワーク分割を防ぐのにも役立ちます。

    マージされたPRは、到達可能な各ネットワーク上の少なくとも1つのピアへの接続を開こうとし、 ネットワーク上の唯一のピアが自動的に排除されるのを防ぎます。

  • ● Bitcoin Core #28008は、BIP324で定義されている v2トランスポートプロトコルの実装に使用される予定の暗号化と復号化ルーチンを追加しました。 PRから引用すると、以下の暗号とクラスが追加されています:

    • “RFC8439セクション2.8のChaCha20Poly1305 AEAD”

    • “BIP324で定義されている[Forward Secrecy] FSChaCha20ストリーム暗号、ChaCha20の鍵の再生成ラッパー”

    • “BIP324で定義されているFSChaCha20Poly1305 AEAD、ChaCha20Poly1305の鍵の再生成ラッパー”

    • “BIP324パケットエンコーディング用の鍵合意、鍵導出、ストリーム暗号およびAEADをカプセル化するBIP324Cipherクラス”

  • ● LDK #2308は、LDKもしくは互換性のある実装を使用する受信者が支払いから抽出できるカスタムTLV（Tag-Length-Value）レコードを 支払いに含めることができるようにしました。これにより、カスタムデータやメタデータを支払いと共に簡単に送信できます。