今週のニュースレターでは、Taprootの準備方法、最新のリリースとリリース候補の要約、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など、 恒例のセクションを掲載しています。

ニュース

今週は重要なニュースはありません。

Taprootの準備 #7: マルチシグ

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

この記事を書く前に受信した1,000ブロックでは、全トランザクションインプットの11%がマルチシグopcodeを含んでいました。 このようなトランザクションを作成するユーザーやサービスの多くが、 マルチシグopcodeからScriptlessなマルチシグに切り替えると、 Taprootの最大かつ最も直接的な2つのメリットが得られます。

1つめの大きなメリットは、トランザクションサイズの削減です。 Scriptベースのマルチシグは、必要とされる鍵や署名が増えるとサイズも増加しますが、 Scriptlessなマルチシグは一定の小さなサイズです。 最小の効果的なマルチシグポリシー（1-of-2）は、数千の署名者が関与する可能性のあるマルチシグポリシーよりも多くのスペースを必要とします。 サイズの削減は、マルチシグユーザーにとっては直接的な手数料削減になり、 すべてのユーザーにとっては、より少ないブロックスペースで同じ量の承認済みトランザクションが受け入れられるため、 間接的な手数料削減につながります。

2つめの大きなメリットは、プライバシーの向上です。 マルチシグの使用は、ブロックチェーン上に明確に記録され、 観察者はそれをもとに個々のユーザーのウォレットの履歴や現在の残高を推測することができます。 例えば、ブロック692,039を見ると、マルチシグの使用とシングルシグの使用を区別できるだけでなく、 マルチシグのセットのサイズや閾値の違いも識別できます。

比較すると、ブロックチェーンのデータのみを調べている第三者は、使用者がマルチシグを使用していることを知ることができません。 keypathの使用でマルチシグが使用されている場合、シングルシグの使用と区別できません。 上記のブロックの全てのシングルシグとマルチシグがP2TRのkeypathの使用に切り替えられた場合、 Scriptで区別できるのは一部の風変わりな使用のみです（そして、それらでさえ、ベストケースではkeypathによる使用が可能です）。

マルチシグの使用

Bitcoin用に設計された3つのSchnorrベースのマルチシグスキームがあり、 いずれもMuSigファミリーのメンバーです:

• MuSig (MuSig1と呼ばれる)は、実装は簡単ですが、署名プロセスで3ラウンドの通信を必要とします。

• MuSig2は、これも実装が簡単です。 MuSig2は、1ラウンドの通信を省き、もう1ラウンドを鍵交換と組み合わせることができます。 これにより、現在使われているScriptベースのマルチシグと同様の署名プロセスを使用することができます。 ただ、追加のデータを保存したり、 署名を行うソフトウェアやハードウェアが騙されて署名セッションの一部を繰り返してしまわないように細心の注意を払う必要があります。 これらのトレードオフについては、来週のTaprootの準備のコラムで詳しく説明します。

• MuSig-DN (Deterministic Nonce)は、実装が非常に複雑です。 参加者間の通信を鍵交換と組み合わせることはできませんが、 反復セッション攻撃に対して脆弱ではないというメリットがあります。

すべての署名者は使用するプロトコルに同意しなければならないため、 多くの実装が同じプロトコルを選択するというネットワーク効果が発生する可能性があります。 MuSigの提案の著者は、比較的シンプルで実用性の高いMuSig2の選択を提案しています。

libsecp256k1-zkpプロジェクトにはMuSig2のサポートを追加するためのPRが公開され、 活発な開発が行われています。 ほとんどのソフトウェアの基本的なマルチシグのワークフローは以下のようになると考えています:

1. 各参加者のウォレットは、BIP32のxpubを生成し、 それをoutput script descriptorやその他の方法で他の参加者全員と共有します （現在、マルチシグで一般的に行われている方法と同じです）。

2. いずれのウォレットも、特定のBIP32の深さの公開鍵と、 マルチシグ・アソシエーションの他のすべてのウォレットの同じ深さの公開鍵を組み合わせることで、 集約公開鍵を生成することができます。この集約公開鍵を使ってP2TR支払いを受け取ることができます。

3. ウォレットの1つが資金を使用したい場合、Scriptベースのマルチシグと同様、 PSBTベースのワークフローを使用しますが、 ここでは署名者間の2ラウンドの通信が必要となります。最初のラウンドでは、 提案者は未署名のトランザクションを作成し、ランダムに生成されたnonceのペアを含めます。 このnonceは、別の署名に再び使用される可能性があるような、完全に決定論的な方法で生成されないことが絶対的に不可欠です。 提案者は、nonceを含むPSBTを他のウォレットに送信します。

4. 他のウォレットはPSBTを受け取ると、自分のランダムなnonceのペアを付けた更新されたPSBTを、 他のウォレットまたはウォレットに代わりトラストレスに動作するコーディネーターに送信します。

5. すべてのウォレットがnonceのペアを持つと、それらを単一のnonceに結合します。 コーディネーターがこれを行うこともできます。 その後、ウォレットはそれぞれのバージョンのPSBTを部分署名で更新し、 そのPSBTを他のウォレットまたはコーディネーターに送信します。 その後、部分署名を組み合わせて最終署名を作成し、トランザクションをブロードキャストします。

閾値署名

マルチシグスキームのMuSigファミリーはn-of-nの署名のみを提供します。 集約公開鍵に鍵を提供するすべての参加者は、最終的な署名にも部分署名を提供する必要があります。 これは、2-of-2のLNのファンディング・アウトプットなど、 現在のScriptベースのマルチシグの一部の用途を直接置き換えるものとしては完璧に動作しますが、 多くの取引所で使用されている2-of-3のマルチシグなど他の一般的なポリシーとは異なります。

複数の開発者が、 このマルチシグと同じ効率およびプライバシーの利点をk-of-nのシナリオにもたらす閾値署名スキームに取り組んでいますが、 それらのスキームが利用可能になるまで使用できる簡単なトリックがあります。

閾値署名は多くの場合、どの参加者が署名する可能性が最も高いかが事前に分かっています。 例えば、2-of-3のケースでは、通常はアリスとボブが共同で署名し、 キャロルはメンバーのいずれかが不在の場合にのみ署名することが分かっているかもしれません。 このようケースでは、メインとなる鍵はTaprootのkeypathによる使用（例：アリスとボブとの間）にマルチシグを使用することができ、 追加の条件（アリスとキャロル、もしくはボブとキャロル）は、 Tapscriptのツリー内の別々のブランチでOP_CHECKSIG opcodeを使ったマルチシグを使用することができます。

通常のケースでは、上記はシングルシグまたはマルチシグのトランザクションと全く同じ効率とプライバシーを持っています。 特異なケースでも、使用は期待どおりに機能し、 マルチシグのパラメーターをオンチェーンで公開するよりも効率的でプライバシーが保たれます。

最小限の手数料と最大限のプライバシーを望むユーザーは、 最終的に純粋な閾値署名スキームに切り替えるかもしれませんが、 上記のスキームは、（参加者のすべての公開鍵を知っている場合）監査人に対して、 どの対応する秘密鍵が署名に使われたかをオンチェーンで証明することができるため、引き続き使用される可能性もあります。

編集: 上記のMuSig2に関する文章の一部を更新し、nonceを事前共有する際には特別な注意が必要であることを明確にしました。 そのため、MuSig2を使用するほとんどの通常のウォレットは、必要な時点で新しいランダムなnonceを生成することが期待されます。 IRCの #secp256k1 ルームのメンバーが懸念を共有してくれたことに感謝します。

リリースとリリース候補

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

• ● C-Lightning 0.10.1rc2は、 いくつかの新機能やバグ修正、（デュアル・ファンディングやOfferを含む） 開発中のプロトコルのいくつかの更新を含むアップグレードのリリース候補です。

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

今週のBitcoin Core、 C-Lightning、Eclair、LND、 Rust-Lightning、libsecp256k1、 Hardware Wallet Interface (HWI)、 Rust Bitcoin、BTCPay Server、 Bitcoin Improvement Proposals（BIP）、および Lightning BOLTsの注目すべき変更点。

• ● Bitcoin Core #22006では、Bitcoin Core #19866で追加されたUser-Space、 Statically Defined Tracing (USDT) および最初の３つのトレースポイントのビルドサポートおよびマクロのドキュメントが追加されました。 eBPFトレースを有効にしてBitcoin Coreをビルドしたユーザーは、 提供されているサンプルスクリプトや独自のトレーススクリプトを記述してトレースポイントにフックし、 新しいブロックが接続され際や、インバウンドのP2Pメッセージを受信した際、 アウトバウンドのP2Pメッセージが送信された際にノードの観測性を高めることができます。 このドキュメントには、使用例や新しいトレースポイントを追加するためのガイドラインも含まれています。

• ● Eclair #1893では、未公開のチャネルや公開されているチャネル、 トランポリンリレーの最小値について、 それぞれ別の手数料率を設定できるようになりました。 また、このPRでは、未公開のチャネル(0.01%)と公開されているチャネル(0.02%)とで、 異なるデフォルト手数料率が設定されています。

• ● Rust-Lightning #967では、send_spontaneous_payment関数呼び出しによる keysend形式のSpontaneous paymentをサポートしました。 この変更により、我々がカバーする4つのLN実装すべてがkeysendをサポートすることになります。

  著者は、BLIP (Bitcoin Lightning Improvement Proposals)として、 keysend支払いに関して対応するドキュメント（まだマージされていません）も提出しています。 これはLN BOLTの仕様の一部に属さない機能やベストプラクティスをドキュメント化するために提案された方法です。