ブロック709,632でのTaprootのアクティベーションの準備に関する発行済みの週刊シリーズのすべてのコピー。

  1. bech32m送信のサポート
  2. Taprootはシングルシグでも価値があるか?
  3. Taproot descriptor
  4. P2WPKHからシングルシグのP2TRへ
  5. なぜ待つ必要があるのか?
  6. Taprootを使って学ぶ
  7. マルチシグの概要
    1. マルチシグの使用
    2. 閾値署名
  8. マルチシグのnonce
  9. 署名アダプター
    1. アダプターの魔法
    2. マルチシグアダプター
  10. PTLC
    1. HTLCのプライバシーの問題
    2. PTLCソリューション
  11. LNとTaproot
    1. LN上のPTLC
    2. P2TRチャネル
    3. タイムフレーム
  12. VaultとTaproot
  13. バックアップとセキュリティのスキーム

bech32m送信のサポート

ニュースレター #154に掲載

11月に予定されているブロック709,632から、 BitcoinユーザーはTaprootアドレスへの支払いを安全に受け取ることができるようになります。 Taprootに対するユーザーの熱意と、ウォレット開発者がTaprootのサポートを実装する必要がある5ヶ月を考えると、 Optechは、ユーザーができるだけ早くTaprootアドレスを生成できるようにする人気ウォレットがいくつか出てくると予想しています。

つまり、ユーザーが提供したアドレスにビットコインを送金するウォレットやサービスは、 ブロック709,632までにTaprootアドレスに送信できるようにする必要があり、 そうしないとユーザーを混乱させ失望させるリスクがあります。 Pay to TapRoot (P2TR)アドレスは、BIP350で定義されているbech32mを使用すます。 これはsegwitのv0 P2WPKHおよびP2WSHアドレスに使用されているBIP173のbech32アルゴリズムと少し異なります。 bech32mは、チェックサム関数でbech32の0x01に代わって、0x2bc830a3を使用します。

この1つの定数を変更することで、bech32mのチェックサムを検証できますが、 既存のP2WPKHおよびP2WSHアドレスについては、元の定数を使用する必要があります。 コードはチェックサムを検証せずにアドレスをデコードし、 v0 segwit (bech32)を使用しているか、v1+ segwit (bech32m)を使用しているかを判断し、 適切なチェックサムを検証する必要があります。 例として、C、C++、JS、Pythonのbech32参照実装を更新したPRを参照ください。 コードが既に参照ライブラリを使用している場合は、リポジトリから最新のコードに更新することができますが、 APIの一部がわずかに変更されていることに注意してください。 BIP350と参照実装は、すべてのbech32m実装が使用すべきtest vectorを提供しています。

Taprootアドレスへの支払いの受け取りは、ブロック709,632まで安全ではありませんが、 支払いの送信によって送信者に問題が発生することはありません。 Bitcoin Coreは、(2019年11月にリリースされた)バージョン0.19以降、 Taprootへの支払いアウトプットを持つトランザクションのリレーや、マイニングをサポートしています。 Optechは、ウォレットやサービスの開発者に対して、Taprootがアクティベートされるまで待つことなく、 今すぐにbech32mのTaprootアドレスへの支払いのサポートを実装することを推奨しています。

Taprootはシングルシグでも価値があるか?

ニュースレター #155に掲載

OptechのTransaction size calculatorを使用すると、 さまざまななタイプのシングルシグ・トランザクションのサイズを比較できます。 予想どおり、P2WPKHのインプットとアウトプットを使用したトランザクションは、 P2PKHのインプットとアウトプットを使用したトランザクションよりもはるかに小さいですが、 意外なことに、P2TRのトランザクションは同等のP2WPKHのトランザクションよりもわずかに大きくなります。

  P2PKH (legacy) P2WPKH (segwit v0) P2TR (taproot/segwit v1)
Output 34 31 43
Input 148 68 57.5
2-in, 2-out tx 374 208.5 211.5

そのため、シングルシグのウォレットがブロック709,632 に備えてTaprootの送信を実装するのは逆効果のように思えるかもしれません。 しかし、よく見てみると、ウォレットのユーザーにとってもネットワーク全体にとっても、 シングルシグにP2TRを使用するのは多くのメリットがあります。

  • 使用料が安い: シングルシグのP2TR UTXOを使用する際のインプットレベルのコストは、 P2WPKH UTXOを使用する際のコストよりも約15%低くなります。 上の表のような単純な分析では、使用者が支払いを要求されているアドレスを選択できないという詳細が隠されています。 つまり、あなたがP2WPKHのままで他のユーザーがP2TRにアップグレードした場合、 あなたの2-in-2-outトランザクションの実際の典型的なサイズは、232.5 vbyteになりますが、 すべてP2TRのトランザクションは211.5 vbyteのままです。

  • プライバシー: アーリーアダプターが新しいスクリプトフォーマットに変更すると一部のプライバシーが失われますが、 Taprootに切り替えたユーザーはすぐにプライバシーが強化されます。 あなたのトランザクションは、新しいLNチャネルや、より効率的なDLC、 安全なマルチシグ、さまざまな賢いウォレットバックアップリカバリー方式、 その他の100の先駆的な開発に取り組んでいる人たちと見分けがつかなくなります。

    P2TRをシングルシグに使用することで、既存のユーザーのプライバシーに影響を与えることなく、 ウォレットをマルチシグやTapscript、LNサポート、またはその他の機能に後でアップグレードすることも可能です。 UTXOがソフトウェアの旧バージョンと新バージョンのどちらで受信されたかは問題になりません。 どちらのUTXOもオンチェーンでは同じように見えます。

  • ハードウェア署名デバイスの利便性の向上: 手数料の過払い攻撃が再発見されてから、 いくつかのハードウェア署名デバイスは、トランザクションで使用される各UTXOに、 そのUTXOを生成したトランザクション全体の重要な部分のコピーを含むメタデータが提供されない限り、 トランザクションへの署名を拒否します。 これにより、ハードウェア署名者が実行しなければならない最悪のケースの処理が大幅に増え、 特に限られたサイズのQRコードを主な通信媒体として使用するハードウェア署名者にとっては問題になります。 Taprootは、手数料の過払い攻撃の原因となる脆弱性を排除し、ハードウェア署名者のパフォーマンスを大幅に向上させます。

  • より予測可能な手数料率: P2PKHおよびP2WPKH UTXOのECDSA署名は、サイズが異なる場合があります(ニュースレター #3参照)。 ウォレットは署名を作成する前にトランザクションの手数料率を選択する必要があるため、 ほとんどのウォレットは、最悪のケースの署名サイズを想定し、 それより小さな署名が生成された場合に手数料率が若干オーバーするのを許容します。 P2TRでは、署名の正確なサイズが事前に分かるため、ウォレットは正確な手数料率を確実に選択することができます。

  • フルノードの支援: Bitcoinシステムの全体的なセキュリティは、かなりの割合のBitcoinユーザーが自身のノードで 承認済みの各トランザクションを検証することに依存しています。 これにはあなたのウォレットが作成するトランザクションの検証も含まれます。 TaprootのSchnorr署名は、効率的なバッチ検証が可能で、 前のブロックをキャッチアップする過程で署名を検証する際にノードが費やす必要のあるCPUサイクル数を約1/2に削減します。 このリストの他のすべてのポイントを拒否したとしても、 フルノードを実行する人々の利益のためにTaprootを使用する準備をご検討ください。

Taproot descriptor

ニュースレター #156に掲載

Output script descriptorは、 ウォレットがアドレスを作成し、そのアドレスに支払われるアウトプットを効率的にスキャンし、 後でそのアドレスから支払うために必要な情報を保存するための汎用的な方法を提供します。 さらに、descriptorは、適度にコンパクトで基本的なチェックサムを含んでいるため、 アドレスの情報をバックアップしたり、異なるウォレット間でコピーしたり、 複数の署名を提供するために協力するウォレット間で共有したりするのに便利です。

descriptorは、現在いくつかのプロジェクトでしか使われていませんが、 descriptorと関連するMiniscriptプロジェクトは、 異なるウォレットやツール間のインターオペラビリティを大幅に向上させる可能性があります。 これは、より多くのユーザーがTaprootの利点を活用して、 マルチシグによるセキュリティとバックアップの使用条件によるリカバリーを向上させるにつれて、 ますます重要になるでしょう。

その前に、Taprootで動作するようにdescriptorを更新する必要があります。 それが最近マージされたBitcoin Core #22051のプルリクエストの主題でした。 単一のdescriptorテンプレートで、P2TRのkeypathによる使用と、 scriptpathによる使用の両方を使用するために必要なすべての情報を提供できるように設計されています。 単純なシングルシグの場合は、以下の記述で十分です:

tr(<key>)

同じ構文をマルチシグや閾値署名にも使用することができます。 例えば、アリスとボブ、キャロルはMuSigを使って鍵を集約し、 tr(<combined_key>)に支払います。

直感的には、tr(<key>)で指定されたkeyはアドレスにエンコードされる鍵にはなりません。 tr() descriptorは、BIP341の安全上の推奨事項に従い、 使用不可能なスクリプトツリーにコミットする内部鍵を使用しています。 これにより、簡易的な鍵集約方式のユーザーに対する攻撃がなくなります (MuSigやMuSig2などのより高度な方式は影響を受けません)。

scriptpathによる使用については、バイナリツリーの内容を指定できる新しい構文が追加されました。 例えば、{ {B,C} , {D,E} }は次のようなツリーを指定します:

Internal key
    / \
   /   \
  / \ / \
  B C D E

ツリーは、前述したdescriptorテンプレートのオプションの2つめのパラメーターとして指定できます。 例えば、アリスがkeypathを介して使用できるようにしたいが、 ボブ、キャロル、ダン、エドモンドが彼女の監査証跡を生成するscriptpathを介して使用できるようにしたい場合 (ただし、サードパーティのチェーン監視用のためのものではない)、アリスは次のdescriptorを使用できます:

tr( <a_key> , { {pk(<b_key>),pk(<c_key>)} , {pk(<d_key>),pk(<e_key>)} )

上記の機能は、Taproot用のdescriptorを使用するために必要なことですが、 PR #22051では、descriptorが期待されるポリシーを完全に記述するために追加できるものがまだいくつか欠けていると指摘しています:

  • keypathの無効化: ユーザーによっては、scriptpathによる使用を強制するために、 keypathの使用を防止したい場合があります。これは現在、 tr()の最初のパラメーターに使用不可能な鍵を使用することで可能ですが、 ウォレットがこの設定をdescriptor自体に保存し、 プライバシーを保護した使用不可能なkeypathを計算させることができると良いでしょう。

  • Tapscriptのマルチシグ: レガシーおよびv0 segwitでは、 multi()およびsortedmulti()descriptorがOP_CHECKMULTISIGopcodeをサポートしています。 Taprootではバッチ検証を可能にするため、スクリプトベースのマルチシグはTapscriptでは少し違った方法で処理されるため、 tr() descriptorでは現在必要なマルチシグopcodeをraw()スクリプトで指定する必要があります。 Tapscript用にmulti()およびsortedmulti()の更新版があると良いでしょう。

  • MuSigベースのマルチシグ: この記事の前半で、 アリスとボブ、キャロルがtr() descriptorを使用するために手動で鍵を集約する説明をしました。 tr(musig(<a_key>, <b_key>, <c_key>))のように指定して、元の鍵情報をすべて保持し、 それを使って協力して署名する際に使用するPSBTフィールドに入力できるようにする関数があると理想的です。

  • タイムロック、ハッシュロック、ポイントロック: LNやDLCCoinswapおよびその他の多くのプロトコルで使用されるこれらの強力な構造は、 今のところraw()関数でしか記述できません。これらのサポートをdescriptorに直接追加することは可能ですが、 代わりにdescriptorの兄弟プロジェクトであるMiniscriptを介してサポートが追加されることになるかもしれません。 Bitcoin CoreへのMiniscriptの統合はまだ進行中のプロジェクトですが、 PSBTやdescriptorのようなツールが既にそうであるように、 その革新性が他のウォレットにも広がることを期待しています。

ウォレットは、Taprootを使い始めるためにdescriptorを実装する必要はありませんが、 実装したウォレットは、後でより高度なTaprootの機能を使用するためのより良い基盤を得ることができます。

P2WPKHからシングルシグのP2TRへ

ニュースレター #157に掲載

既にv0 segwit P2WPKHアウトプットの受け取りと使用をサポートしているウォレットにとって、 シングルシグ用のv1 segwit P2TRへのアップグレードは簡単です。 主な手順は次のとおりです:

  • 新しいBIP32鍵導出パスの使用: BIP32 階層的決定性 (HD)コードを変更する必要はなく、 ユーザーはシードを変更する必要もありません。1 ただし、P2TR公開鍵用の新しい導出パス(BIP86で定義されているような)を使用することを強く推奨します。 そうしないと、ECDSAとSchnorr署名 の両方で同じ鍵を使用した場合に発生する攻撃を受ける可能性があります。

  • ハッシュによる公開鍵の調整: シングルシグでは技術的には必須ではありませんが、 特にすべての鍵がランダムに選択されたBIP32シードから導出されている場合、 BIP341では鍵を使用不可能なscripthashツリーにコミットすることを推奨しています。 これは公開鍵とその鍵のハッシュの曲線の点を加算する楕円曲線の加算操作を使用するという簡単なものです。 この推奨事項に従うことのメリットは、後でスクリプトレスなマルチシグのサポートや、 tr() descriptorのサポートを追加する場合に、同じコードを使用できることです。

  • アドレスの作成と監視: bech32mを使ってアドレスを作成します。 支払いは、scriptPubKey OP_1 <tweaked_pubkey>に送られます。 P2WPKHなどのv0 segwitアドレスのスキャンに使用する方法を使って、 スクリプトに支払いをするトランザクションをスキャンできます。

  • 使用トランザクションの作成: Taprootのすべての非witnessフィールドは、 P2WPKHと同じため、トランザクションのシリアライゼーションの変更について心配する必要はありません。

  • 署名メッセージの作成: これは使用トランザクションのデータに対するコミットメントです。 データのほとんどは、P2WPKHトランザクションに署名するのと同じものですが、 フィールドの順番が変更され、いくつかの追加項目が署名されています。 これを実装するのは、さまざまなデータをハッシュしシリアライズするだけなので、 コードを書くのは簡単です。

  • 署名メッセージのハッシュに署名: Schnorr署名を作成するには、さまざまなな方法があります。 最善の方法は、「独自の暗号を使う」のではなく、信頼できる十分レビューされたライブラリの関数を使用することです。 ただ、何らかの理由によりそれができない場合は、 BIP340は、ECDSA署名を作成するためのプリミティブが利用可能であれば、 簡単に実装できるアルゴリズムを提供します。署名ができたら、 インプットのwitnessデータに入れ、使用トランザクションを送信します。

ブロック709,632でTaprootがアクティベートされる前でも、 testnetやパブリックなデフォルトsignet、 Bitcoin Coreのプライベートなregtestモードを使ってコードをテストできます。 オープンソースのウォレットにTaprootのサポートを追加する場合、 他の開発者があなたのコードから学べるように、 Bitcoin Wikiのtaproot usesページや bech32m adoptionページにその実装のPRへのリンクを追加することをお勧めします。

なぜ待つ必要があるのか?

ニュースレター #158に掲載

これまでの連載では、ウォレットやサービスの開発者に対してTaprootがアクティベートされた時に備えて、 Taprootのアップグレードを今から実装するよう呼びかけてきました。 しかし、サービスやユーザーが損失を被る可能性があるため、 ブロック709,632より前にP2TR用のアドレスを生成しないよう警告しました。

事前にアドレスを生成しない理由は、P2TRスタイルのアウトプットへの支払いは、 ブロック709,632より前では誰でも使用できるためです。 お金は完全に安全ではなくなります。 しかし、そのブロックになると何千ものフルノードがBIP341およびBIP342 (そして関連するBIP340)のルールの適用を開始します。

ブロックチェーンの再編成がないことが保証されているのであれば、 最後のTaproot前のブロック(ブロック709,631)が確認できた時点でP2TRアドレスの生成を始めても安全でしょう。 しかし、ブロックチェーンの再編成については懸念すべき理由があります。 偶然の再編成だけでなく、初期のP2TR支払いからお金を奪うために意図的に作られる再編成もあるためです。

P2TRの支払いを最初に受け取ろうとする大勢の人々を想像してみてください。 ブロック709,631が確認できるとすぐに彼らは単純にいくらかのお金を送信します。2 これらの支払いは、ブロック709,632では安全ですが、 ブロック709,631に代わるブロックを作成したマイナーによって盗まれる可能性があります。 P2TRアウトプットへ送られるお金の価値が十分に大きければ、 1つのブロックではなく2つのブロックをマイニングしようとする方が簡単に利益を得られる可能性があります (詳細はトピックフィー・スナイピングを参照)。

この理由から、再編成のリスクが効果的に解消されたと思われるまでは、 ソフトウェアやサービスでP2TR用のアドレスを生成することはお勧めしません。 アクティベーションから144ブロック(約1日)待つことは、 あなたやあなたのユーザーがTaprootの利点を利用するのを大幅に遅らせることなく、 リスクを最小限に抑えることができる、適度に保守的なマージンだと考えています。

まとめると:

  • 709,631: P2TRスタイルのアウトプットに送信されたお金を誰でも使うことができる最後のブロック
  • 709,632: P2TRアウトプットがBIP341BIP342のルールを満たす場合にのみ使用できる最初のブロック
  • 709,776: ウォレットがユーザーにP2TRアウトプット用のbech32m受信アドレスを提供し始めるのに適したブロック

上記はいずれも、できるだけ早くbech32mアドレスへの支払いを可能にするという、 このシリーズの最初のパートで提供されたアドバイスを変更するものではありません。 安全だと思う前にP2TR用のアドレスを要求した場合、それは彼らのリスクです。

Taprootを使って学ぶ

ニュースレター #159に掲載

約2年前、James ChiangとElichai Turkelは、 開発者にTaproot技術をトレーニングするためのOptechワークショップシリーズ用に Jupyter Notebookのオープンソースリポジトリを作成しました。 サンフランシスコ、ニューヨーク市、ロンドンで開催されたワークショップは好評でしたが、 渡航制限により、その後の対面のワークショップはできませんでした。

Jupyter Notebookの公開以来、Taprootにはいくつかの変更が加えられました。 しかし、TaprootのサポートもBitcoin Coreにマージされたため、 NotebookもBitcoin Coreのカスタムブランチへの依存関係を削除できるようになりました。 開発者のElle Moutonは、これらの変更にあわせてNotebook更新し、 Taprootのアルゴリズムやデータタイプを使ったハンズオンを素早く構築するための優れた方法を再び提供してくれました。

Notebookは、4つのセクションに分かれています:

  • セクション 0には、環境のセットアップに役立つNotebookが含まれており、 楕円曲線暗号の基本をカバーし、BIP 340341および342全体で使用されているタグ付きハッシュについて学べます。

  • セクション 1では、Schnorr署名の作成について説明しています。 これをマスターしたら、MuSigプロトコルを使ってマルチシグを作成する方法を学びます。

  • セクション 2では、Taprootのあらゆる側面を体験できます。 segwit v0トランザクションの原理を確認するところから始まり、 segwit v1 (taproot)トランザクションの作成、送信を行います。 セクション 1の知識を応用して、MuSigを使ったTaprootアウトプットを作成、使用します。 鍵の調整という概念が導入され、Taprootで公開鍵を使ってデータにコミットできることを学びます。 コミットメントが作成できるようになったので、Tapscriptについて、 従来のsegwit v0 scriptとの違いや、Tapscriptのツリーにコミットする方法を学びます。 最後に短いNotebookで最適なスクリプトツリーを作成するためのハフマンエンコーディングを紹介します。

  • セクション 3では、アウトプットが使われない期間が長くなるほど、 必要になる署名が変わるTaprootアウトプットを作成するオプションの演習を用意しています。 これにより、通常の状況下ではアウトプットを効率的に使用できるだけでなく、 問題が発生した場合には堅牢なバックアップが提供されます。

Notebookには、比較的簡単ですが提示された資料を実際に学習することを保証するプログラミング演習が多数含まれています。 凄いコーダーではないこのコラムの著者は6時間でNotebookを完了させることができ、 もっと早くこのNotebookで学ぶ時間を取っていればよかったと後悔しました。

マルチシグの概要

ニュースレター #160に掲載

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

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

Plot showing the savings for multisignatures compared to multisig

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

Illustration of the lack of witness fungibility in current blocks

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

Illustration of how fungibile witnesses could be ideally

マルチシグの使用

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 ルームのメンバーが懸念を共有してくれたことに感謝します。

マルチシグのnonce

ニュースレター #161に掲載

先週のコラムでは、マルチシグについて書き、 MuSig2を使った例を紹介しました。 私たちの説明は技術的には正しいと思われますが、MuSig2に貢献した何人かの暗号技術者は、 私たちが提案した使い方は危険だと心配していました。 私たちは、当面の懸念に対応するため説明を更新し、 その後、この問題をより徹底的に調査しました。 この記事では、マルチシグを安全に実装するための最大の課題であると思われるnonceの再利用の回避について説明します。

Bitcoinで署名を検証するには、署名と署名されたメッセージ(トランザクションなど)、 公開鍵、公開nonceを公開されている方程式に入力します。 この方程式が成立するのは、自分の秘密鍵とnonceの秘密情報を知っている場合だけです。 したがって、成立した方程式を確認した人は、そのメッセージと公開鍵に対する署名が有効であると考えます。

署名とメッセージを方程式に含める動機は明らかです。公開鍵は秘密鍵の代用です。 公開nonceは何のためのものでしょうか?これがなければ、方程式内の秘密鍵以外の値はすべて分かっているため、 基本的な代数を使って未知の1つの値を解くことができます。しかし代数学では、 2つの未知の値を解くことはできません。そのためnonceの秘密の情報は、あなたの秘密鍵を隠す役割をします。 また、公開鍵が署名式の中で秘密鍵の代用となっているように、nonceの公開情報は秘密情報の代用となっています。

ここでいうnonceとは、一度使っただけの数値ではなく一度しか使ってはならない数値のことです。 同じnonceを異なる2つの署名で再利用すると、2つの署名式を組み合わせてnonceを打ち消し、 唯一の残った未知の値であるあなたの秘密鍵を再び誰かが解くことができます。 BIP32標準の導出(非強化導出)を使用している場合、ほとんどのマルチシグウォレットがそうであるように、 1つの秘密鍵が明らかになると、同じBIP32パス内(おそらく他のパスも同様)にある他のすべての秘密鍵も明らかになります。 つまり、100個の異なるアドレスでビットコインを受け取ったマルチシグウォレットは、 署名者がnonceを1つでも再利用すると、それらのアドレスの全てが危険にさらされることになります。

シングルシグのウォレットや、スクリプトベースのマルチシグを使用しているウォレットは、 nonceの再利用を避けるために、nonceを署名しようとしているメッセージに依存させるという 簡単なトリックを使用できます。メッセージに変更があると、nonceも変わるため、nonceが再利用されることはありません。

マルチシグにはこのトリックは使えません。すべての共同署名者は、部分署名だけでなく、 部分公開nonceも提供する必要があります。部分公開nonceは結合されて、集約公開nonceとなり、 署名するメッセージに含まれます。

つまり、トランザクションが同じでも、同じ部分nonceを2回以上使用することは安全ではありません。 2回めの署名の際に、あなたの共同署名者が部分nonceを変更した(集約nonceを変更した)場合、 2回めの部分署名は異なるメッセージに対するものになります。 そうなるとあなたの秘密鍵が明らかになります。 すべての参加者が自分のnonceの秘密を、他のすべての参加者の部分公開nonceに依存させるのは循環的で不可能であるため、 マルチシグでnonceの再利用を避けるための簡単なトリックはありません。

一見すると、これは大きな問題ではないように思えます。 署名者はなにかに署名するたびに、新しいランダムなnonceを生成すればよいのです。 これは思ったより正しく理解するのが難しいものです。少なくとも2012年以降、 ランダムなnonce生成に依存するウォレットでビットコインを失うバグが発見されています。

しかし、たとえウォレットが高品質なランダムnonceを生成したとしても、 各nonceは最大で1回しか使用されないようにしなければなりません。 先週のコラムの原文では、MuSig2と互換性のあるコールドウォレットやハードシェア署名デバイスについて掲載していましたが、 これらのデバイスは最初の実行時に大量のnonceを作成します。 ウォレットやデバイスは、これらのnonceを2つ以上の部分署名で使用されないようにする必要があります。 nonceが使用されるたびにカウンターをインクリメントするだけの簡単なことのように聞こえますが、 外部からの悪意ある介入による影響はもちろんのこと、 ソフトウェアやハードウェアが偶発的に故障する可能性があることを考えると、本当に難しいことです。

ウォレットがnonceの再利用のリスクを減らす最も簡単な方法は、nonceをできるだけ短期間保存することでしょう。 先週の例では、nonceを数ヶ月から数年にわたって保存することを提案しましたが、 これは何か問題が発生する可能性が高いだけでなく、 バックアップや復元、予期せぬ状態になる可能性のある永続的なストレージにnonceを記録する必要があります。 MuSig2を使用する別の方法としては、PSBTを受信したときなど、 必要に応じてnonceを作成する方法です。nonceは必要な短時間だけ揮発性のメモリに保持しておき、 ソフトウェアのクラッシュや電源の喪失など予期せぬ事態が起こった場合には、 自動的に破壊される(再利用できなくなる)ようにしておくことができます。

しかし、この問題に取り組んでいる暗号技術者は、オリジナルのMuSigプロトコル(MuSig1)やMuSig2において、 nonceの再利用を防ぐための確実な方法がないことを非常に懸念しているようです。 MuSig-DN (deterministic nonce)は解決策を提供していますが、 複雑で時間がかかります(アルファ版の実装では、2.9 GHzのIntel i7でnonceの証明を作成するのに約1秒かかり、 それよりもはるかに性能の低い16 MHzのハードウェア署名デイバイスでどれだけ時間がかかるかは不明です)。

マルチシグ署名を実装する方へのアドバイスとしては、時間やリソースに大きな投資をする前に、 IRCの#secp256k1ルームやBitcoinの暗号技術者が集まる他の場所に立ち寄って、 計画を説明することを検討してください。

署名アダプター

ニュースレター #162に掲載

ある人が、その人の好きな数字を当てることができたら、特定の慈善団体に1,000 BTCを寄付すると申し出たとします。 寄付者がこれを実行する簡単な方法は、1,000 BTCを支払う未署名のトランザクションを作成し、 好きな数字を復号鍵として、そのトランザクションの署名を暗号化したコピーを公開する方法です。

理論的には、数字を推測した人は、署名を復号し、トランザクションをブロードキャストして慈善団体へ支払いができます。 しかし、寄付者がAESのような標準的な暗号化方式を使用している場合、 第三者が復号する前に署名がそのトランザクションに対して有効なものであることを簡単に知る方法はありません。 数字の推測に注力したい人は、寄付者がトロールではなく誠実であることを信頼しなければなりません。

この問題をもう少し拡張してみましょう。第三者であるアリスとボブは、署名が公開されるかどうかを賭けたいとします。 彼らは署名者に署名のハッシュを尋ね、それをHTLC関数内のハッシュとして使用することができますが、 これもまた寄付者が正直に行動することを信頼する必要があります。 最終的に署名が公開されたとしても、寄付者は誤ったハッシュをアリスとボブに与えることで、そのコントラクトを妨害することができます。

アダプターの魔法

署名アダプター(Signature adaptor)は、 アダプター署名(Adaptor signature)one-time verifiably encrypted signatureとも呼ばれ、 これらの問題を解決するもので、Bitcoin上に構築されたプロダクションシステムで現在実際に直面している多くの問題を解決します。 Bitcoinの既存のECDSA署名方式でも使用可能ですが、 BIP340で実装されているTaproot用のSchnorr署名と組み合わせることで、 アダプターを非公開でコストをかけずに使用することができます。 上の例が、アダプターを使うとどう変わるか見てみましょう。

先程と同様に、寄付者は1,000 BTCのトランザクションを用意します。 ほぼ通常の方法で署名しますが、1つの違いは、基本的に2つのnonceを生成する点です: 永久に秘密にしておく真のランダムnonceと、 もう1つは最初は秘密にしておくけど他の人が発見しても安全な好きな数字です。 寄付者は、これら2つの値を加算し1つのnonceであるかのようにして完全に有効な署名を作成します。

BIP340の署名コミットメントでは、nonceを2つの形式で使用します: 通常署名者のみが知っている数値表現(スカラーと呼ばれる)と、 検証を可能にするために公開される楕円曲線上のです。

寄付者は、有効な署名コミットメント部を取り出し、隠されたスカラーを減算します。 これにより、署名は不完全(つまり無効)なものになりますが、 寄付者は(無効な)署名コミットメントと、完全なnonceの(有効な)点と、 隠された数字の(有効な)点を共有することができます。 これらの3つの情報を合わせて署名アダプターとします。

BIP340の署名検証アルゴリズムを少し変形し、 隠されたスカラーが(現在は無効な)署名コミットメントに単純に加算された場合、 署名アダプターが有効な署名を提供することを誰もが検証することができます。 これは隠された数字が何であるかを知らなくても検証できます。 要するに、ユーザーはトラストレスに隠されたスカラー値について推測することができるようになり、 正しい推測値により署名を取得しトランザクションを送信することができるという安心感が得られます。

寄付者の署名アダプターを受け取った他の人たちと同様に、アリスとボブは、 隠された数字の楕円曲線上の点のコピーを持っています。 また、他の人と同様、彼らは実際のスカラーを知りません。しかし、思い起こすと、 寄付者が有効な署名を無効な署名に変えるために行ったことは、 隠された数字の点に署名でコミットしながら、隠された数字を署名コミットメントから減算しただけでした。 アリスは、自分が知らないスカラーにコミットせず自分が知っている楕円曲線上の点にコミットすることで、 同じように簡単に(無効な)署名を作ることができます。 アリスは自分のnonceのペアを作り、(無効な)署名を作る際は秘密の形式を使用し、 寄付者の署名アダプターの楕円曲線の点とnonceの公開形式の集約にコミットします。 これにより、ボブに支払いをするトランザクションの署名アダプターが生成されます。 ボブがスカラーを知っていれば、アダプターを有効な署名に変換してトランザクションを送信し、 賭けに勝つことができます。

しかし、ボブはどうやって数字を知るのでしょうか? 数字を推測した誰かがプレスリリースをするのを待つのでしょうか?いいえ。 寄付者が公開した署名アダプターは、寄付者の実際の署名からスカラーを引いたものであることをもう一度思い出してください。 隠された数字が発見され、誰かが1,000 BTCのトランザクションを送信した場合、 彼らは元の(有効な)署名コミットメントを公開しなければなりません。 ボブは、(有効な)署名コミットメントを取得し、 そこから元の署名アダプターの(無効な)署名コミットメントを減算しスカラーを入手します。 続いて、そのスカラーを使ってアリスのアダプターを有効な署名に変換します。

マルチシグアダプター

前節では、個々のユーザーが署名の作成方法を変更して署名アダプターを生成する方法を示しました。 マルチシグの参加者が同じトリックを使うことも可能です。 署名アダプターを使用する多くの場合、2人のユーザーの協力が必要となるため、これはとても便利です。

例えば、アリスとボブが上のような賭けをする場合、 二人はまず両者のマルチシグでのみ使用可能なスクリプトに資金をデポジットするところから始めるでしょう。 次にアリスは、署名アダプター形式の部分署名を生成できます。 ボブが隠された数字を知った場合、ボブがアリスのアダプターを有効なアリスの部分署名に変換し、 次にボブ自身の部分署名を提供して資金を使用できる完全な署名を作成することができます。

これにより、署名アダプターは一般的なマルチシグと同様の利点を持つことになります。 つまり、単一の署名のように見え、使用するスペースは同じで、手数料を最小限に抑え、 プライバシーとファンジビリティを最大限に高めることができます。

来週のTaprootの準備では、署名アダプターが使用されることが予想される主な方法の1つを紹介します。 Point Time Locked Contracts (PTLC)は、LNやcoinswap、 その他の多くのプロトコルで広く使われているHash Time Lock Contracts (HTLC)をアップグレードしたものです。

PTLC

ニュースレター #163に掲載

先週のコラムでは署名アダプターSchnorr署名をサポートするTaprootのアクティベーションにより、 アダプターを非公開で効率的に使用することが簡単になることを紹介しました。 署名アダプターをBitcoinで使用する方法はいくつかありますが、最もすぐに役立つものの1つは、 長年使用されてきた歴史あるHash Time Locked Contracts (HTLC)に代わる Point Time Locked Contracts (PTLC)です。 これにはいくつかの利点がありますが、同時にいくつかの課題もあります。 両方を理解するために、まず現在使用されているHTLCの簡単な例から説明します。 以下の例では、オフチェーンのLN支払い、オンチェーンのcoinswap、 Lightning Loopのようなオンチェーン/オフチェーンのハイブリッドシステムが考えられます。 この柔軟性により、HTLCは広く利用されています。

アリスは、アリスもキャロルも信頼をしないボブを経由して支払いをルーティングすることで、キャロルに支払いをしたいと考えています。 キャロルはランダムなプリイメージを作成し、SHA256アルゴリズムでハッシュします。 キャロルはそのハッシュをアリスに渡し、プリイメージは秘密にしておきます。 アリスは、ボブへの支払いを開始し、ボブは自身の公開鍵に対する署名とプリイメージを使って支払いを受け取れます。 または、アリスは10ブロック経過したら自分の公開鍵に対する署名を使ってトランザクションを自分自身に戻すことで払い戻しをすることが可能です。 このポリシーをMinsc言語で定義すると以下のようになります:

(pk($bob) && sha256($preimage)) || (pk($alice) && older(10))

ボブは、参加者が更新され払い戻しのタイムアウトが小さくなるものの基本的に同じScriptを使って、 キャロルに同じ金額(おそらく手数料を差し引いた金額)の支払いを開始することができます。

(pk($carol) && sha256($preimage)) || (pk($bob) && older(5))

これでキャロルは、プリイメージを使って5ブロック以内にボブからの支払いを受け取ることができ、 これによりプリイメージが明らかになり、ボブは同じく5ブロック以内にアリスからの支払いを受け取ることができます。

HTLCのプライバシーの問題

上記のScriptがオンチェーンで公開された場合、同じハッシュとプリイメージが再利用されていることで、 AがBを経由してCに支払ったことが一目瞭然になります。 これは同じチェーンおよびクロスチェーンのcoinswapにとって重要な問題となります。 あまり明白ではありませんが、これはLNのようなオフチェーンのルーティングプロトコルにとっても問題です。 ある人が経路上の複数のホップを管理している長いルーティング経路を想像すると、 同じハッシュとプリイメージが再利用されていることを確認し、 一部のノードがルーティングノードであることを判断し、残りのノードが送信者か受信者のどちらかである確率を高めることができます。 これはLNの現在のプライバシー上の弱点であるリンク可能性問題の1つです。

Illustration of HTLC linkability problem

マルチパス支払いは、LNのリンク可能性問題の他の側面(支払い額のリンク可能性など)を部分的に軽減しますが、 監視ルーティングノードにハッシュを相関させる機会を与えることで、ハッシュのリンク可能性問題を悪化させる可能性があります。

現在のHTLCのもう1つの問題は、オンチェーンにする必要のあるScriptが通常の支払いのScriptとは明らかに異なることです。 これにより監視者は使用パターンを特定しやすくなり、おそらく個々のユーザーに特有の情報を効果的に推測することができます。

PTLCソリューション

これまでのMinscスタイルのScriptでは、事前に選択した特定の値(プリイメージ)が渡された場合にのみtrueを返す関数がありました。 署名アダプターも同様で、関数に公開された値(スカラー)が渡された場合のみ、有効な署名に変換することができます。 とりあえずマルチシグを無視すると、先程のHTLC Scriptは以下のPTLCに変換することができます:

(pk($bob) && pk($alice_adaptor)) || (pk($alice) && older(10))
(pk($carol) && pk($bob_adaptor)) || (pk($bob) && older(5))

つまり、キャロルはアリスに隠されたスカラーに対するECポイントを渡し、 アリスはそのECポイントと自身が選択した公開鍵を一緒に使用して、ボブに渡す署名アダプターを作成します。 ボブは、自身が選択した公開鍵と同じポイントを使用してキャロルに渡す署名アダプターを作成できます。 キャロルは、ボブのアダプターを有効な署名に変換することでスカラーを公開し、ボブのコインを受け取ります。 ボブは有効な署名からスカラーを復元し、アリスのアダプターを自分の有効な署名に変換し、アリスのコインを受け取ります。

これにより、誰もがブロックチェーンを確認しても個別の公開鍵に対する有効な署名の束があるだけなので、 オンチェーン監視に対するリンク可能性問題が解決されます。 第三者は、アダプターが使用されたことや、そのアダプターがどのスカラーに基づいているかを知ることはできません。

しかし、上記の手順では、ルーティングに参加している監視ノードが支払いをリンクするのを防ぐことはできません。 すべての支払いが同じスカラーに基づいている場合、すべての支払いはハッシュロックとプリイメージを使用した場合と同様リンクされます。 これは、各ルーティングノードが独自のスカラーを選択し、支払いがそのノードを通過する際に対応するポイントを削除することで解決できます。 それでは例を修正してみましょう:

前と同様に、キャロルはアリスに彼女のスカラーに対応するポイントを与えますが、 今回はアリスはボブにもポイントを要求します。アリスは、 キャロルのポイントとボブのポイントの両方を集約したものを使ってボブに渡すアダプターを構築します。 ボブは自分のポイントを知っているので、アリスから受け取ったアダプターからその点を引くことができます。 その結果得られた点(ボブはこれがアリスがキャロルから最初に受け取った点であることを知らない)を使って、 ボブはキャロルに渡すアダプターを構築します。キャロルはその最終的なポイントのスカラーを知っているので、 ボブのアダプターを有効な署名に変換します。前述のように、ボブはキャロルの署名からスカラーを復元し、 それと自分のスカラーを使ってアリスのアダプターを有効な署名に変換します。

この経路の2つのホップ(アリス→ボブとボブ→キャロル)では、2つの異なるECポイントとスカラーが使用されており、 リンク可能性を排除します。これをHTLCで検討した時より長い経路に拡張し、これによりプライバシーがどう改善されるか確認できます:

Illustration of PTLC lack of linkability problem

先週述べたように、Schnorr署名を使うとマルチシグのアダプター署名を簡単に構成することができます。 一般的なPTLCの場合、これによりオンチェーンScriptを以下のように削減することができます:

pk($bob_with_alice_adaptor) || (pk($alice) && older(10))
pk($carol_with_bob_adaptor) || (pk($bob)   && older(5) )

Taprootでは、左の分岐がkeypathになり、右の分岐がtapleafになります。 支払いのルーティングが成功すると、ボブとキャロルは相手の協力を得ること無く、 それぞれのパートをオンチェーンで決済することができます。 これにより、このルーティングされた支払いは、シングルシグの支払い、通常のマルチシグの支払い、 協調的に解決されたコントラクトと区別がつきません。また、ブロックスペースの使用を最小限に抑えることができます。 払い戻し条件の1つを実行する場合でも、それはかなり効率的でかなりプライベートなものです—pk(x) && older(n)は、 デグレード・マルチシグHODLの強制、 その他のさまざまなScriptと区別がつきません。

来週のコラムでは、私たちのお気に入りのLN開発者の1人によるゲスト投稿で、 LNがkeypathによる使用やマルチシグ、PTLCおよびTaprootで可能になるその他の機能を採用するために必要な変更点について説明します。

LNとTaproot

ニュースレター #164に掲載

LNプロトコル開発者ZmnSCPxjの寄稿

この投稿では、TaprootがLNで可能にする2つのプライバシー機能について説明します:

  • LN上のPTLC
  • P2TRチャネル

LN上のPTLC

PTLCは多くの機能を可能にしますが、 LNにとっての主な機能は、経路をランダム化することなく支払いを非相関化する機能です。3 シングルパスやマルチパスの経路に沿ったすべてのノードに、 転送される各PTLCを調整するために使用されるスカラーを与えることができ、 個々の転送が各LN支払い用の一意な識別子を漏らすことのない支払いの非相関化を可能にします。

PTLCはプライバシーの万能薬ではありません。 監視ノードが特定のタイムロックと量を持つ転送を発見し、 その直後に2つめの監視ノードがより小さなタイムロックと僅かに少ない量を持つ転送を発見した場合、 たとえ監視ノードが一意に識別可能なハッシュを介してそれらを相関させることができなくなったとしても、 これらの転送が同じ支払いのパスに属する可能性は非常に高いです。しかし、得るものはあります:

  • 分析の不確実性が増します。監視者が扱うことのできる確率が低くなり、情報の価値ははるかに低くなります。
  • マルチパス支払いでは、より多くの非相関化が行われます。 個別のパスには、それぞれタイムロックや量に強い相関関係はないでしょうし、 LNが成功すれば、タイミングの相関関係も信頼できないほど十分な支払いがあるでしょう。
  • HTLCと比較してコストは増加しません (マルチシグの効率化により、わずかにコストが減少する可能性もあります)。

原則として、Taproot前のチャネルは、チャネルを閉じて再度開くことなく、 PTLCをサポートするようアップグレードすることができます。 既存のチャネルは、既存の非Taprootのファンディング・アウトプットを PTLCを含むTaprootアウトプットへ送信するオフチェーントランザクションを作成することで、PTLCをホストすることができます。 つまり、LN上でPTLCのサポートを追加しても、 各ノードとそのチャネルピアがソフトウェアをアップグレードする以上のコストがユーザーにかかることはないということです。

しかし、PTLCを実際に使用するためには、送信者から受信者までのすべての転送ノードがPTLCをサポートする必要があります。 つまり、十分な数のノードがアップグレードするまで、PTLCのサポートはほとんど使われない可能性があります。 すべてのノードが同じプロトコルを使用する必要はありませんが(複数のPTLCプロトコルが存在する可能性があります)、 すべてのノードが何らかのPTLCプロトコルをサポートする必要があります。 複数のPTLCプロトコルをサポートすることになると、メンテナンスの負担が増えるため、 そのようなプロトコルが多くならないことを願っています(理想的には1つだけ)。

P2TRチャネル

ベースレイヤーとLNレイヤー間の非相関化を改善するための1つのソリューションは、 LN上でその存在がゴシップされないチャネルである非公開チャネルでした。

残念ながら、すべてのLNチャネルは2人の署名者の協力を必要とし、現在のTaproot前のBitcoinでは、 すべての2-of-2のScriptがオープンにコーディングされています。 LNは2-of-2マルチシグの最も一般的なユーザーであるため、ブロックチェーンエクスプローラであれば、 これが閉じられたLNチャネルであることを示すことができます。 そこから資金を辿ることができ、それが別のP2WSHアウトプットに向かっていれば、 それは別の非公開チャネルである可能性が高くなります。 このように、非公開チャネルであっても、ある程度の誤検出はあるものの、閉じるとオンチェーンで特定することができます。

Taprootは、Schnorr署名を使用することで、 n-of-nを1-of-1と全く同じように見せることができます。 少し工夫すれば、k-of-nでも1-of-1(およびn-of-n)と同じように見えます。 そして、LNチャネルがP2TR UTXO、つまりP2TRチャネルを使うことで、 非公開チャネルのオンチェーンプライバシーを向上させることができます。4

この(かなり小さな)プライバシーの向上は、公開チャネルにも役立ちます。 公開チャネルは、公開されている間だけゴシップされるので、 公開チャネルを探そうとしても、過去のチャネルについて知ることはできません。 監視者がすべての公開チャネルを確認したい場合、そのデータをすべて自身で保持しなければならず、 アーカイブノードに頼ることはできません。

さらに、Taprootのkeypathによる使用は、LNの既存のP2WSHの使用に比べて38.5 vbyte (40%)小さくなります。 残念ながら、既存のTaproot前のチャネルをP2TRチャネルにアップグレードすることはできません。 既存のチャネルは、既存のP2WSH 2-of-2スキームを使用しており、 P2TRチャネルに切り替えるにはチャネルを閉じなければなりません。

理論的には、実際のファンディング・トランザクションのアウトポイントは、 チャネルを使用する2つのノードにのみ関係します。 ネットワーク上の他のノードは、2つのノード間のチャネルのセキュリティには関心がありません。 しかし、公開チャネルはLNのゴシップネットワーク上で共有されます。 ノードがゴシップされた公開チャネルを受信すると、ノードは自身の信頼できるBitcoinフルノードを参照し、 ファンディングのアウトポイントが存在するか、さらに重要なことに正しいアドレスを持っているかを確認します。 アドレスを確認することで、チャネルゴシップの仕組みをスパムするのが困難になります。 チャネルゴシップを送信するためには、実際にブロックチェーン上に資金が必要です。 したがって、実際には、P2TRチャネルであってもある程度のリモート互換性が必要です。 そうでなければ、送信者はこれらのチャネルが存在することを検証できないため、 これらのチャネルを無視してルーティングを行います。

タイムフレーム

分散型FOSSプロジェクトで機能のタイムフレームを作るには、過去の機能とそれにかかった時間を調べ、 それらの機能を実際に展開するのにかかる時間を基準にするのが、最良の方法だと思います。5

最近の新機能の中で、LNを介したPTLCとスコープが似ていると思うのはデュアル・ファンディングです。 Lisa NeigutがBOLTs #524でデュアル・ファンディングの最初の提案をし、 その約2年6ヶ月後にmainnetで最初のデュアル・ファンディングチャネル開設されました。 デュアル・ファンディングに必要なのは、直接のピアとの互換性だけです。 LN上のPTLCは、受信者を含む選択した経路上のルーティングノードとの互換性を必要とします。 そのため、この機能には追加の複雑さを理由に+50%の時間補正をするのが妥当だと考えており、 具体的なPTLCプロトコルが提案されてから、3年9ヶ月を目安にしています。

P2TRチャネルについては、これは2つの直接のピア間のみの話で、利点も少ないことに注意してください。 そのため優先度は低くなると思います。ほとんどの開発者がPTLC-over-LNを優先すると仮定すると、 P2TRチャネルは、基礎となるSIGHASH_ANYPREVOUTや、 Decker-Russell-Osuntokun(“Eltoo“)を実装する他の方法が利用可能になる頃には、 作業が開始されると予想されます。

VaultとTaproot

ニュースレター #165に掲載

Revault開発者Antoine Poinsotの寄稿

BitcoinのVaultは、コントラクトの一種で、 ユーザーが自分のウォレットのお金を使用するのに、2つの連続したトランザクションを必要とします。 このようなプロトコルは数多く提案されているため(シングルもしくはマルチパーティ、Covenantあり、なし)、 それらの共通する点にフォーカスします。

1つのオンチェーントランザクションで複数の支払いを実行するバッチ支払いとは対照的に、 Vaultは1つの支払いを実行するために複数のトランザクションを使用します。 最初のトランザクションであるUnvaultは、以下のいずれかに支払いをします:

  1. 相対的なタイムロックの後で公開鍵のセットに、もしくは
  2. タイムロックのない単一の公開鍵に

最初の支払いのパスは、メインケースで、ホットキーの使用が予想されます。2つめの支払いのパスでは、 トランザクションのキャンセル(クローバック、リカバリー、再Vault化トランザクションと呼ばれることもあります)を可能にします。

このように、BitcoinのVaultは、ほとんどのコントラクトがすべての参加者が署名に協力するハッピーパス( そしてタイムロックが含まれる紛争解決パス)を持っているTaprootの洞察とは対照的で、むしろ逆です。 支払いトランザクションは、相対的なタイムロック6により妨げられているため、 taprootのscriptpathを使用しなければなりませんが、キャンセルトランザクションは理論的にはkeypathを使用できます。

マルチパーティのVaultは、実際には既に多くの対話を必要としているため、 理論的にはMusig2のようなBIP340によって可能になったマルチシグ閾値署名スキームの恩恵を受けることができます。 しかし、これらのスキームには、新たな安全性の課題があります。 Vaultのプロトコルは、コールドストレージに使用することを目的としているため、 設計上の選択はより保守的で、Vaultはおそらくこれらの新しい技術を使用する最後の場になるでしょう。

Taprootに切り替えることで、Vaultはマークルブランチと(特にマルチパーティの場合)より短いBIP340署名の使用により、 若干のプライバシーと効率性の向上の恩恵を受けることにになるでしょう。 例えば、6個の「コールド」キーと3個の「アクティブ」キーを持つ(閾値を2とした)マルチパーティのセットアップにおける Unvaultのアウトプットスクリプトは、深さ2のリーフを持つTaprootで表現できます:

  • <X> CSV DROP <active key 1> CHECKSIG <active key 2> CHECKSIGADD 2 EQUAL
  • <X> CSV DROP <active key 2> CHECKSIG <active key 3> CHECKSIGADD 2 EQUAL
  • <X> CSV DROP <active key 3> CHECKSIG <active key 1> CHECKSIGADD 2 EQUAL
  • <cold key 1> CHECKSIG <cold key 2> CHECKSIGADD <cold key 3> CHECKSIGADD <cold key 4> CHECKSIGADD <cold key 5> CHECKSIGADD <cold key 6> CHECKSIGADD 6 EQUAL

Taprootでは、アウトプットを使用するために使用するリーフのみを明かすため、 トランザクションweightは、P2WSHスクリプトの場合よりもかなり小さくなります:

IF
  6 <cold key 1> <cold key 2> <cold key 3> <cold key 4> <cold key 5> <cold key 6> 6 CHECKMULTISIG
ELSE
  <X> CSV DROP
  2 <active key 1> <active key 2> <active key 3> 3 CHECKMULTISIG
ENDIF

失効ブランチは、支払いが成功した場合には隠すことができますが(そしてマルチシグの閾値を使用する場合、 その存在と参加者の数を難読化できます)、Vaultの使用パターンはオンチェーンで簡単に識別できるため、 プライバシーの向上は最小限となります。

最後に、Vaultプロトコルは、ほとんどの事前署名されたトランザクションプロトコルと同様に、 BIP118SIGHASH_ANYPREVOUTのようなTaprootを基に提案されたBitcoinのアップグレードから大きな恩恵を受けるでしょう。 さらなる注意とプロトコルの調整が必要ですが、ANYPREVOUTANYPREVOUTANYSCRIPTは、再バインド可能なキャンセル署名を可能にします。 これにより、対話を大幅に減らすことができ、0(1)の署名の保存が可能になります。 これは、DoS攻撃の対象を大幅に削減することができるため、Revaultプロトコル緊急署名にとって特に興味深いものになります。 アウトプットにANYPREVOUTANYSCRIPT署名を含めることにより、 このコインを使用するトランザクションがアウトプットを作成する方法を制限するCovenantを効果的に作成します。 さらにカスタマイズ可能な将来の署名ハッシュにより、より柔軟な制限が可能になります。

バックアップとセキュリティのスキーム

ニュースレター #166に掲載

先週のコラムでは、Antoine Poinsotが、 Vaultスタイルのコインバックアップやセキュリティスキームを、 Taprootによって、よりプライベートで手数料を効率化する方法を説明しました。 今週のコラムでは、Taprootに変更することで改善される他のいくつかのバックアップやセキュリティスキームについて見ていきます。

  • シンプルな2-of-3: 先週述べたようにマルチシグとscriptpathによる支払いを組み合わせて、 2-of-3の支払いポリシーを簡単に作ることができます。通常ケースはシングルシグの支払いと同じくらい効率的なオンチェーンで、 現在のP2SHやP2WSHのマルチシグよりもはるかにプライベートなものです。 例外ケースでも、かなり効率的でプライベートです。このように、Taprootは、 単一署名者のウォレットから複数の署名者のポリシーにセキュリティをアップグレードするのに適しています。

    今後の閾値署名の技術により、 2-of-3や他のk-of-nのケースがさらに改善されることを期待しています。

  • マルチシグのデグレード: Optech Taproot Workshopの演習問題の1つでは、 3つの鍵ではいつでも支払いが可能、もしくは3日後に元の鍵の内2つで支払いが可能、 10日後であれば元の鍵の内1つで支払いが可能なTaprootのScriptを作成する実験をすることができます。 (この実験では、バックアップの鍵も使用しますが、それは次のポイントで別途取り上げます。) このように、時間パラメーターと鍵の設定を調整することで、柔軟かつ強力なバックアップを構築することができます。

    例えば、普段はノートパソコンや携帯電話、ハードウェア署名デバイスを組み合わせて支払いをできるとします。 そのうちの1つが使えなくなった場合、1ヶ月待てば残りの2つのデバイスを使って支払いができます。 2つのデバイスが使えなくなった場合は、6ヶ月後に1つのデバイスだけで支払いができます。

    3つのデバイスをすべて使用する通常のケースでは、あなたのオンチェーンScriptは最大限に効率的でプライベートなものになります。 その他のケースでは、少し効率は低下しますが、それでもかなりプライベートである可能性があります (あなたのScriptとそのツリーの深さは、他の多くのコントラクトで使用されているScriptと深さと似ています)。

  • バックアップのためのソーシャルリカバリーとセキュリティ: 上記の例は、 デバイスの1つが攻撃者に盗まれた場合の保護に優れていますが、2つのデバイスが盗まれた場合はどうなるでしょう? また、ウォレットを頻繁に使用する場合、デバイスを失った後に再び支払いを開始できるようになるまで本当に1ヶ月待ちたいと思いますか?

    Taprootを使うと、バックアップにソーシャル要素を簡単かつ安価、プライベートに追加できます。 前の例のScriptに加えて、2つのデバイスに加えて友人または家族からの署名があればビットコインをすぐに使用できるようにすることもできます。 または、鍵の1つと信頼できる5人の署名があればすぐに使用できます。 (これと同様の非ソーシャルバージョンは、安全な場所に保管してある追加のデバイスやシードフレーズを使用するだけです。)

  • 相続のための時間的および社会的閾値の組み合わせ: 上記の技術を組み合わせることで、 あなたが突然死亡したりだめになってしまった場合に、誰かまたは複数人の人があなたの資金を回収できるようにすることができます。 例えば、ビットコインを6ヶ月動かさなかった場合、 あなたの弁護士と最も信頼できる5人の親族のうち任意の3人にコインの使用を許可することができます。 普段からビットコインを6ヶ月ごとに移動させていれば、この相続の準備は、 あなたが生きている限りオンチェーンコストがかからず、外部からは完全に非公開になります。 あなたの死後、弁護士や家族があなたのウォレットの拡張公開鍵(xpub)を知ることができる確実な方法を用意しておけば、 トランザクションを弁護士や家族に秘密にしたままにすることも可能です。

    なお相続人があなたのビットコインを使用できるようにすることは、 そのビットコインを合法的に使用できることを意味するわけではないことに注意してください。 ビットコインの相続を計画されている方は、Pamela Morgan著 Cryptoasset Inheritance Planning物理的な書籍およびDRM付き電子書籍、 またはDRMフリーの電子書籍)をお読みになり、 その情報をもとに、地元の相続計画の専門家に詳細を相談されることをお勧めします。

  • 侵害の検出: Taprootの発明以前に提案されたアイディアは、 デバイスが侵害されたことを検出する方法として、いくつかの量のビットコインを管理する鍵を、 あなたが気をつけているデバイスのすべてに配置するというものです。ビットコインの量が十分多ければ、 攻撃者はおそらく、不正アクセスを長期的な攻撃に利用して全体的な被害が広がるのを待つのではなく、 目先の利益のためにそのコインを使用するでしょう。

    このアプローチの問題は、提供するビットコインの量を攻撃者を誘うのに十分な大きさにしたいものの、 大量のビットコインをすべてのデバイスに配置したくはなく、どちらかというと大きな報奨金を1つだけ提供したいという点です。 しかし、すべてのデバイスに同じ鍵を配置すると、攻撃者がビットコインを使用するトランザクションからは、 どのデバイスが侵害されたかはわかりません。 Taprootでは、すべてのデバイスに異なるscriptpathの異なる鍵を簡単に配置することができます。 これらの鍵のいずれかが、そのアドレスで管理されているすべての資金を使用することができますが、 どのデバイスが侵害されたか一意に特定することができます。

Footnotes

  1. Electrumがsegwit v0にアップグレードされた際、 bech32アドレスで受け取りたい人は誰でも新しいシードを生成する必要がありました。 これは技術的には必要ありませんでしたが、 Electrumの作者は自分たちのカスタムシードの導出方法にいくつかの新しい機能を導入することができました。 その1つがシードのバージョン番号で、シードを使用するスクリプトを指定する機能です。 これにより古いスクリプトを安全に非推奨にできます(例えば、将来リリースされるElectrumのバージョンでは、 従来のP2PKHアドレスへの受信がサポートされなくなる可能性があります)。

    Electrumの開発者がバージョン付きのシードを展開していたのと同時期に、 Bitcoin Coreの開発者は、output script descriptorを使用して、 (他の問題の解決に加えて)スクリプトの非推奨を可能にするという同じ問題を解決し始めました。 次の表は、Electrumのバージョン付きのシードとBitcoin Coreのdescriptorを、 以前両方のウォレットで使用され、 現在も多くの他のウォレットで一般的に使用されているimplicit scripts方式と比較したものです。

    スクリプト管理 初期バックアップ 新しいスクリプトの導入 スキャン(帯域幅/CPUコスト) 非推奨スクリプト
    Implicit scripts (例:BIP44) シードワード 自動(ユーザー操作は不要) サポートされているすべてのスクリプトをスキャン、O(n) サポートされていないスクリプトを使用していることをユーザーに警告する方法はありません
    Explicit scripts(バージョン付きシード) シードワード(バージョンビットを含む) ユーザーは新しいシードのバックアップが必要。 資金は2つの別々のウォレットに分割されるか、ユーザーは旧ウォレットから新しいウォレットに資金を送信する必要があります 単一のスクリプトテンプレートのみをスキャン、O(1) サポートされていないスクリプトに関するユーザーへの警告
    Explicit scripts (descriptor) シードワードとdescriptor ユーザーは新しいdescriptorのバックアップが必要 実際に使用されたスクリプトテンプレートのみをスキャン、O(n); 新しいウォレットの場合はn=1 サポートされていないスクリプトに関するユーザーへの警告

  2. 最初のTaprootブロックでP2TR支払いを受けたいユーザーは、 誰にも教えずにアドレスを生成し、そのアドレス宛にnLockTimeを709,631に設定したトランザクションを作成してください。 このトランザクションは、ブロック709,631を受信するとすぐにブロードキャストできます。 nLockTimeは、そのトランザクションがTaprootのルールが提供される709,632より前のブロックに含まれないことを保証します。 新しいスクリプトタイプやカスタムlocktimeに手を出すのは、 それが何をしているのか分からない場合には危険なので気をつけてください。 

  3. 支払者は、HTLCの相関分析を誤らせるために、 非常に複雑なパス(つなり経路のランダム化)を選択することができますが、 それには欠点があります:

    • 複雑なパスは、コストがかかり、かつ信頼性も低いものになります (より多くのノードに支払いを行い、支払いが宛先に到達するためには より多くのノードが転送に成功する必要があります)。
    • 複雑なパスは長いので、支払者は支払いについてより多くのノードに伝えることになり、 監視ノードに当たる可能性が高くなります。 このように複雑なパスは、必ずしもプライバシーを完全に改善するものではありません。

  4. 非公開チャネルを検討する際には、タンゴを踊るには二人必要なことを思い出してください。 非公開チャネルを閉じる場合、もう1人の参加者(例えばLNサービスプロバイダー)が残りの資金を公開チャネルに使用した場合、 ブロックチェーンエクスプローラは、資金のソースが閉鎖された非公開チャネルであった可能性をある程度推測できます。 

  5. 確かに詳細は重要ですが、それだけではありません。高い視点から見ると、 開発のある側面での予期せぬ困難と、開発の他の側面での予期せぬ非困難は相殺され、 すべての主要な機能は、ある平均的なタイムフレームにほぼ沿っていることになります。 感覚的な見積もりではなく、正確な見積もりをしたいのであれば、 計画錯誤を避ける方法を使うべきです つまり、過去に完成した似たような機能を探し、その詳細をわざと無視して、 その機能の実装にかかった時間だけを見るのです。 

  6. 事前に分かっていれば、特定のnSequenceを持つ支払いトランザクションに事前署名することができますが、 そうすると「アクティブ」なキーを使った別の支払いパスはまったく必要ありません。 また、通常コインを受け取った時点で、そのコインをどう使うかはわかりません。