ブロック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. バックアップとセキュリティのスキーム
  14. Signetでのテスト
  15. まだ必要なsignmessageプロトコル
  16. アウトプットのリンク
  17. 協力は常にオプション？
  18. トリビア
  19. 将来のコンセンサスの変更
  20. アクティベーション時に何が起こる？
  21. ありがとう！

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を使用します。

この１つの定数を変更することで、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やDLC、 Coinswapおよびその他の多くのプロトコルで使用されるこれらの強力な構造は、 今のところ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アウトプットがBIP341とBIP342のルールを満たす場合にのみ使用できる最初のブロック
  • 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 340、 341および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と、 もう１つは最初は秘密にしておくけど他の人が発見しても安全な好きな数字です。 寄付者は、これら2つの値を加算し1つのnonceであるかのようにして完全に有効な署名を作成します。

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

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

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

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

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

マルチシグアダプター

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

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

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

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

PTLC

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

先週のコラムでは、署名アダプターと Schnorr署名をサポートするTaprootのアクティベーションにより、 アダプターを非公開で効率的に使用することが簡単になることを紹介しました。 署名アダプターをBitcoinで使用する方法はいくつかありますが、最もすぐに役立つものの１つは、 長年使用されてきた歴史ある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の現在のプライバシー上の弱点であるリンク可能性問題の１つです。

Illustration of HTLC linkability problem

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

現在のHTLCのもう１つの問題は、オンチェーンにする必要のある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ポイントと自身が選択した公開鍵を一緒に使用して、ボブに渡す署名アダプターを作成します。 ボブは、自身が選択した公開鍵と同じポイントを使用してキャロルに渡す署名アダプターを作成できます。 キャロルは、ボブのアダプターを有効な署名に変換することでスカラーを公開し、ボブのコインを受け取ります。 ボブは有効な署名からスカラーを復元し、アリスのアダプターを自分の有効な署名に変換し、アリスのコインを受け取ります。

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

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

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

この経路の２つのホップ（アリス→ボブとボブ→キャロル）では、２つの異なる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になります。 支払いのルーティングが成功すると、ボブとキャロルは相手の協力を得ること無く、 それぞれのパートをオンチェーンで決済することができます。 これにより、このルーティングされた支払いは、シングルシグの支払い、通常のマルチシグの支払い、 協調的に解決されたコントラクトと区別がつきません。また、ブロックスペースの使用を最小限に抑えることができます。 払い戻し条件の１つを実行する場合でも、それはかなり効率的でかなりプライベートなものです—pk(x) && older(n)は、 デグレード・マルチシグやHODLの強制、 その他のさまざまなScriptと区別がつきません。

来週のコラムでは、私たちのお気に入りのLN開発者の１人によるゲスト投稿で、 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プロトコルをサポートすることになると、メンテナンスの負担が増えるため、 そのようなプロトコルが多くならないことを願っています（理想的には１つだけ）。

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プロトコルは、ほとんどの事前署名されたトランザクションプロトコルと同様に、 BIP118のSIGHASH_ANYPREVOUTのようなTaprootを基に提案されたBitcoinのアップグレードから大きな恩恵を受けるでしょう。 さらなる注意とプロトコルの調整が必要ですが、ANYPREVOUTやANYPREVOUTANYSCRIPTは、再バインド可能なキャンセル署名を可能にします。 これにより、対話を大幅に減らすことができ、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の異なる鍵を簡単に配置することができます。 これらの鍵のいずれかが、そのアドレスで管理されているすべての資金を使用することができますが、 どのデバイスが侵害されたか一意に特定することができます。

Signetでのテスト

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

mainnetでブロック709,632より前にTaprootを安全に使用することはできませんが、 今日、testnetまたはsignetのいずれかでTaprootを使用することはできます。 Optech taproot workbooksで行われているように、 Bitcoin Coreのregtestモードでローカルのテストネットワークを作成するのに比べて、 testnetやsignetを使用すると、自分のウォレットが他の人のウォレットとどのように相互作用するか簡単にテストできます。

この記事では、signet上でBitcoin Coreの内蔵ウォレットを使って、 Taprootトランザクションを受信したり支払いしたります。 自分のウォレットとBitcoin Coreの間で送受信をテストするのに、この手順を利用できます。

技術的には、Bitcoin Core 22.0の内蔵ウォレットを使ってTaprootトランザクションを受信および使用することは可能ですが、 代わりに、descriptorウォレットのデフォルトをTaprootにした、 Bitcoin CoreのPR #22364をビルドすることをお勧めします。 ビルドし、signetを起動します:

$ bitcoind -signet -daemon

初めてsignetを起動する場合は、ブロックチェーンを同期する必要があります。 現在は、200 MB以下のデータで、わずか1分で同期が完了します。 同期の進捗状況はgetblockchaininfo RPC使って確認できます。 同期後、descriptorウォレットを作成します:

$ bitcoin-cli -signet -named createwallet wallet_name=p4tr descriptors=true load_on_startup=true
{
  "name": "p4tr",
  "warning": "Wallet is an experimental descriptor wallet"
}

これで、bech32mアドレスを作成できます:

$ bitcoin-cli -named -signet getnewaddress address_type=bech32m
tb1p6h5fuzmnvpdthf5shf0qqjzwy7wsqc5rhmgq2ks9xrak4ry6mtrscsqvzp

このアドレスを使って、signet faucetに資金をリクエストできます。 その後、承認を待つ必要がありますが、これにはmainnetと同じように時間がかかります（通常は最大30分、 時にはそれ以上かかることもあります）。 トランザクションが確認できると、作成したP2TRスクリプトが表示されるでしょう。

$ bitcoin-cli -signet getrawtransaction 688f8c792a7b3d9cb46b95bfa5b10fe458617b758fe4100c5a1b9536bedae4cd true | jq .vout[0]
{
  "value": 0.001,
  "n": 0,
  "scriptPubKey": {
    "asm": "1 d5e89e0b73605abba690ba5e00484e279d006283bed0055a0530fb6a8c9adac7",
    "hex": "5120d5e89e0b73605abba690ba5e00484e279d006283bed0055a0530fb6a8c9adac7",
    "address": "tb1p6h5fuzmnvpdthf5shf0qqjzwy7wsqc5rhmgq2ks9xrak4ry6mtrscsqvzp",
    "type": "witness_v1_taproot"
  }
}

続いて、2つめのbech32mアドレスを作成し、そこに資金を送って支払いをテストできます。

$ bitcoin-cli -named -signet getnewaddress address_type=bech32m
tb1p53qvqxja52ge4a7dlcng6qsqggdd85fydxs4f5s3s4ndd2yrn6ns0r6uhx
$ bitcoin-cli -named -signet sendtoaddress address=tb1p53qvqxja52ge4a7dlcng6qsqggdd85fydxs4f5s3s4ndd2yrn6ns0r6uhx amount=0.00099
24083fdac05edc9dbe0bb836272601c8893e705a2b046f97193550a30d880a0c

この支払いについて、インプットの１つを確認すると、そのwitnessには64バイトの署名が1つだけ含まれています。 これはP2WPKHやその他のタイプの古いBitcoinの支払いをした場合に必要とされるwitnessよりもvbyte数が小さくなっています。

$ bitcoin-cli -signet getrawtransaction 24083fdac05edc9dbe0bb836272601c8893e705a2b046f97193550a30d880a0c true | jq .vin[0]
{
  "txid": "bd6dbd2271a95bce8a806288a751a33fc4cf2c336e52a5b98a5ded432229b6f8",
  "vout": 0,
  "scriptSig": {
    "asm": "",
    "hex": ""
  },
  "txinwitness": [
    "2a926abbc29fba46e0ba9bca45e1e747486dec748df1e07ee8d887e2532eb48e0b0bff511005eeccfe770c0c1bf880d0d06cb42861212832c5f01f7e6c40c3ce"
  ],
  "sequence": 4294967294
}

上記のコマンドをいじってみると、signetに対応しているウォレットでTaprootを使ってお金を受け取ったり、 支払ったりするのが簡単であることが分かります。

まだ必要なsignmessageプロトコル

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

4年以上前にsegwitが有効になって以来、bech32やbech32mアドレスに対して 署名付きテキストメッセージを作成する広く受け入れられた方法はありません。 間違いなく、これは広範なメッセージ署名のサポートが、ユーザーや開発者にとってそれほど重要ではないことを意味し、 そうでなければ、もっと多くの作業がそれに費やされていることでしょう。 しかし、誰もがレガシーアドレスを使い、署名されたメッセージを簡単に交換できた時代から、 Bitcoinウォレットソフトウェアは後退したように感じます。

約2年前にbech32支払いのサポートシリーズで書いた 汎用的なsignmessageソリューションは低迷しており、 プロトコルドキュメントであるBIP322が時折更新されているにもかかわらず （ニュースレター#118および#130参照）、 Bitcoin Coreには採用されませんでした。 それにもかかわらず、私たちはこれ以上の代替案を知らないため、 P2TRウォレットにsignmessageサポートを追加したい開発者にとっては、 BIP322が依然として好ましい選択であるはずです。

実装されている場合、汎用のsignmessageは、P2TRアウトプットに対して、 シングルシグやマルチシグ、または任意のTapscriptを使用して メッセージに署名できるようにします。 また、すべてのレガシーアドレスおよびbech32アドレスとの後方互換性と、 近い将来に想定されている変更（そのうちのいくつかは、今後のTaprootの準備コラムで紹介します）との前方互換性も提供されます。 完全なUTXOセットにアクセスできるアプリケーション（例: フルノード経由）は、 BIP322を使用してリザーブ・プルーフを生成・検証することもできます。 これは、署名者がある時点で一定量のビットコインを管理していたことを証明するものです。

汎用的な署名付きメッセージを作成するためのサポートは、非常に簡単に実装できるでしょう。 BIP322では、仮想トランザクションと呼ばれる技術を使っています。 最初の仮想トランザクションは、存在しない前のトランザクション（txidがすべてゼロのトランザクション）から支払いしようとすることで、 意図的に無効になるように作成されます。この最初のトランザクションは、 ユーザーが署名したいアドレス（スクリプト）に支払い、希望するメッセージのハッシュコミットメントを含みます。 2つめのトランザクションは、最初のトランザクションのアウトプットを使用します。 その支払いの署名およびその他のデータが有効なトランザクションであれば、 メッセージは署名されているとみなされます（ただし、2つめの仮想トランザクションは、 無効なトランザクションを参照しているため、オンチェーンに含めることはできません）。

汎用的な署名付きメッセージを検証することは、多くのウォレットにとって困難です。 任意のBIP322メッセージを完全に検証できるようにするには、 基本的にすべてのBitcoinのコンセンサスルールを実装する必要があります。 ほとんどのウォレットではそれを行っていないため、BIP322ではScriptを完全に検証できない場合に 「不確定」な状態を返すことができます。 実際には、特にTaprootがkeypathの支払いを奨励している場合、それは稀なことかもしれません。 最もよく使われるScriptタイプのいくつかを実装したウォレットであれば、 全UTXOの99%以上の署名付きメッセージを検証することができます。

汎用的なsignmessageのサポートはBitcoinの有用な追加機能になるでしょう。 ここ数年、注意が払われてこなかったことを無視することはできませんが、 これを読んでいるウォレット開発者には、プログラムに実験的なサポートを追加することの検討をお勧めします。 これは、ここ数年ユーザーが失っていた機能をユーザーに提供する簡単な方法です。 BIP322や関連するリザーブ・プルーフの実装に取り組んでいる開発者の方や、 このような機能が有用であると思われるサービスプロバイダーの方は、 info@bitcoinops.orgまでお気軽に連絡いただき、取り組みを調整ください。

アウトプットのリンク

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

Taprootがアクティベートされると、ユーザーはP2TRアウトプットへの支払いを受け入れます。 その後、ユーザーはそのアウトプットを使用します。場合によっては、 P2TR以外のアウトプットに支払いをして、P2TRのお釣り用アウトプットを使って自分自身にお釣りを返すこともあります。

Example transaction P2TR -> {P2WPKH, P2TR}

このようなトランザクションを観察している専門家やアルゴリズムは、 P2TRアウトプットがユーザー自身のお釣り用のアウトプットであり、 もう一方のアウトプットが支払い用のアウトプットであると合理的に推測することができます。 これが真実であるとは限りませんが、最も可能性の高い説明です。

ウォレットがP2TRに移行する間、このように一時的にプライバシーが低下する可能性があるため、 Taprootのプライバシー上の利点を無視すべきだと主張する人もいます。 多くの専門家は、それは不当な過剰反応であるとしています。 私たちもそれに同意し、さらにいくつかの反論をしたいと思います:

  • ● 他のメタデータ: トランザクションには、どのアウトプットがお釣りで、 どのアウトプットが支払いかを明らかにする、その他のメタデータが含まれている場合があります。 最も気になるのは、現在アドレスを再利用しているアウトプットが大きな割合を占めており、 これらのトランザクションに関わる送信者と受信者の両方のプライバシーが著しく低下していることです。 これらの問題が続く限り、ベストプラクティスを実装しているウォレットやサービスのユーザーのプライバシーを 大幅に改善しないのは愚かなことだと思います。

  • ● Output Scriptのマッチング: Bitcoin Coreの内蔵ウォレットでは、 支払いのアウトプットタイプのいずれかがsegwitでもある場合、 デフォルトでsegwitのお釣り用アウトプットを使用します。 それ以外の場合、デフォルトのお釣り用アドレスタイプを使用します。 例えば、P2PKHのアウトプットへの支払い時には、P2PKHのお釣り用アウトプットが使用され、 P2WPKHアウトプットに対しては、P2WPKHのお釣りが使用されます。 ニュースレター #155に記載されているように、Taprootのアクティベート後、 Bitcoin Coreは、同じトランザクション内の他のアウトプットがP2TRである場合、 P2TRのお釣り用アウトプットを機会的に使用し始めます。 これにより、移行期間中のお釣りの識別性の増加を最小限に抑えることができます。

  • ● アップグレードのリクエスト: P2TRの使用は、 セキュリティ要件に関係なく、誰もが同じタイプのOutput Scriptを使用することができ、 また、区別できないインプットを頻繁に使用することで、プライバシーを大幅に向上させることができるという、 Bitcoinの歴史上初めての機会になります。 Bitcoinのプライバシーを有意義に向上させたいのであれば、あなたが支払いをしているユーザーやサービスに、 Taprootのサポートを提供するよう依頼することができます（また、該当する場合は、アドレスの再利用を停止することも）。 あなたと彼らの両方がアップグレードすれば、お釣り用アウトプットの識別は難しくなり、 Taprootの他の驚くべきプライバシー上の利点もすべて得られます。

協力は常にオプション？

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

Gregory Maxwellによる最初の最初のTaprootの提案は、 コントラクト設計の興味深い原則を示唆していました:

“興味深いScriptには、ほとんどの場合、論理的なトップレベルの分岐があり、 参加者全員による署名だけでコントラクトを成立させることができます。 他の分岐は、ある参加者が協力できない場合にのみ使用されます。 もっと強く言うと、固定の有限の参加者が前もって設定されている 任意の コントラクトは、 N-of-Nと、より複雑なコントラクトを表現したい場合のOR条件として表現することができ、 またそうすべきであると考えています。” (強調は原文のまま)

それ以来、専門家はこの原則の普遍性について議論してきましたが、 私たちの知る限り、タイムロックにフォーカスした2つの例外があります:

  • ● コンセンサスによるセルフコントロールの強化: タイムロックを利用して、一定期間、自分のビットコインを使わないようにしている人もいます。 タイムロックの要件は、署名以上のものが必要であることを示唆ししているように思えますが、 いくつかの批判があります:

    • タイムロックされたビットコインをどうしても使いたい人は、 おそらく他の資産を担保にしてローンを組むことができます。 これは、このセルフコントラクトの有用性を損ないます。

    • コンセンサスによるscriptpathのタイムロックに加えて、 ユーザーは自分の鍵とタイムロックの期限が切れた時にのみ署名する第三者の鍵とでkeypathによる支払いを可能にできます。 これは、より効率的なだけでなく、受け取ったフォークコインを販売したり、 人生の大きな変化や価格上昇などにより早期の使用を許可する第三者と協力するなど、 より柔軟な支払いポリシーを実装することができます。

  • ● Vault: 数週間前の本サイトのAntoine Poinsotのコラムで言及されているように、 Vaultも資金保護のためにタイムロックを多用していますが、 「ほとんどのコントラクトには参加者全員が署名に協力するハッピーパスがあるというTaprootの洞察とは対照的」 だと思われます。また、Vaultのユーザーがkeypathを使ってVaultの条件から抜け出すオプションを望まないケースはなく、 scriptpath用に作成されたコントラクトにkeypathオプションを追加してもコストはかからないので、 keypathを有効にする方が厳密には優れていると主張する人もいます。

常にkeypathオプションを提供することに反対する論拠は、 一緒に行動する署名者が自分自身を信頼していない場合もあるということです。 代わりに他の人を、つまりBitcoinのコンセンサスルールを適用する経済的なフルノードのオペレーターを信頼し、 署名者が自身で適用したくない署名者の支払い能力に対する制限を適用します。

反論として、少なくとも純粋に理論的には、 通常の署名者とそのような経済的フルノードのオペレーターとでkeypathを作成し、 同じセキュリティを得ることができます。より現実的には、もしそれらが利用可能であれば、 あなたが望むポリシーを適用するkeypathマルチシグのセットに追加できるそれらのノードオペレーターのサブセット または代替セットがあるでしょう（そして、利用できなくてもscriptpathが利用できるので、何も失うことはありません）。

理屈はさておき、オプションとは思えない場合でも、 Taprootベースのコントラクトでkeypathを使用する機会があるかどうか、少し時間をかけて検討することをお勧めします。

トリビア

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

  • ● Taprootとは？ ウィキペディアによると、 「Taprootとは、大きく、中央にあり、そこから他の根が横方向に発芽する主要な根です。 一般的には、やや直線的で非常に太く、先細りの形状をしており、真下に向かって伸びています。 人参などの一部の植物では、Taprootは非常によく発達した貯蔵器官であるため、野菜として栽培されます。」

    これはBitcoinにどう当てはまるでしょう？

    • 「名前の由来は’taps into the Merkle root’だと思っていましたが、 Gregory Maxwellの考えがどうだったかは実は知りません。」 —Pieter Wuille (出典)

    • 「”私はもともと言葉を調べる必要がありました。しかし、 key pathが’taproot’になるのは、それが人参スープを作る美味しいものであるためで、 マークル化されたScriptは、無視したいと願う他の少ない根だろうと受け取りました。」 —Anthony Towns (出典)

    • 「名前の由来は、タンポポの根っこのような太い中心部を持つ木を視覚化したものです。 この技術は、高確率のパスが１つあり、残りはファジーなはぐれ者であるという仮定から、 ほとんどの場合役に立ちます。そして、 根っこに隠されたコミットメントを利用してscript-pathの支払いを検証するという面白い事実も良いと考えました。

      […]残念ながら、ソートされた内部ノードを持つハッシュツリーを’Myrtle tree’と呼んでも流行りませんでした。 （ハッシュルートが等しいポリシーのセットは、T-functionで定義できる順列によって順序の異なるものであるため、 Myrtle treeです。そして、Myrtleとは、お茶の木であるメラレウカを含む科であること、 そして’merkle’に聞こえることからきてます。:p）」 —Gregory Maxwell (出典)

  • ● Schnorr署名はECDSAより前から存在: Schnorr署名について、さまざまな暗号トリックの実装が簡単になるため、 Bitcoinの元のECDSA署名のアップグレードとして説明していますが、 Schnorr署名のアルゴリズムはECDSAのベースであるDSAアルゴリズムよりも前からあったものです。 実際、DSAはClaus Peter SchnorrのSchnorr署名の特許を回避するために作られたものですが、 Schnorrはそれでも「[私の]特許は、その種の離散対数署名のさまざまな実装に適用されており、 したがって、これらの事例であるNyberg-RueppelおよびDSA署名の使用をカバーしている。」と主張しています。 Schnorrの主張を支持した裁判所は知られておらず、彼の特許は2011年に失効しました。

  • ● どんな名前を使用するか: うまくいきまんせんでしたが、Schnorr署名をBitcoinに適用する開発の初期段階で、 Claus Peter Schnorrの名前を署名に関連して使うべきではないという提案がありました。 これは、彼の特許が20年以上にわたって貴重な暗号技術の普及を妨げていたためです。 Pieter Wuilleは、「BIP340を’Discrete Logarithm Signatures’から’DLS’と呼ぶことを検討したが、 Schnorrという名前がすでに話題になっていたため、最終的にそうならなかった」と書いています。

  • ● ツイストEdwards曲線のSchnorr署名: 楕円曲線を使用したSchnorr署名のアプリケーションが2011年に公開されました。 スキームEdDSAは、現在いくつかの標準の基礎となっています。 Bitcoinのコンセンサスでは使用されていませんが、他のシステムのコンテキストでの参照は、 Optechが追跡している多くのBitcoinリポジトリで見られます。

  • ● Pay to contract: Ilja GerhardtとTimo Hankeは、支払いがその契約のハッシュにコミットすることを可能する、 2013年のSan JoseのBitcoinカンファレンスでHankeによって紹介されたプロトコルを作成しました。 契約のコピーと、特定の攻撃を回避するために使用されるnonceを持っている人であればコミットメントを検証できますが、 それ以外の人にとってはその支払いは他のBitcoinの支払いと同じように見えます。

    このpay-to-contract (P2C)プロトコルを少し改良したものが、 サイドチェーンに関する2014年の論文に含まれており、 コミットメントには支払いのための元の公開鍵も含まれるようになっています。 Taprootはこれと同じ構造を採用していますが、オフチェーン契約の条項にコミットする代わりに、 アウトプットの作成者は、受信したビットコインをオンチェーンで使用する方法について、 受信者が選んだコンセンサス適用条件にコミットします。

  • ● A Good Morning: P2Cを利用することで、Scriptへの支払いが公開鍵への支払いとチェーン上で同一に見えるようにするアイディアは、 2018年1月22日にカリフォルニア州ロス・アルトスのダイナー「A Good Morning」で考案されました。 Pieter Wuilleは、このアイディアは「私が短時間テーブルを離れている間に… !$%@」[sic] Andrew PoelstraとGregory Maxwellによって開発されたと書いています。

  • ● 2.5年を1.5日で: bech32mに最適な定数を選択するのには、 約2.5年のCPU時間が必要でしたが、 Gregory Maxwellが所有するCPUクラスタを使用してわずか1.5日で実行されました。

このコラムに関連して楽しい会話をしてくださたAnthony Towns、Gregory Maxwell、Jonas Nick、 Pieter WuilleおよびTim Ruffingに感謝します。誤りがあった場合それは筆者の責任です。

将来のコンセンサスの変更

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

ブロック709,632でのTaprootのアクティベーションが近づくにつれ、 開発者がTaproot上に構築したいと以前から表明していたコンセンサスのいくつかの変更を楽しみにするようになりました。

  • ● インプットをまたいだ署名の集約: Schnorr署名は、複数の異なる公開鍵と秘密鍵のペアの所有者が、 協力して署名を作成したことを証明する単一の署名を簡単に作成することができます。

    将来のコンセンサスの変更により、 トランザクションで使用されているすべてのUTXOの所有者がその支払いを承認したことを証明する 単一の署名をトランザクションに含めることができるようになる可能性があります。 これにより、最初のインプットの後は、keypathでの支払い毎に約16 vbyteが節約され、 統合やCoinJoinでの大幅な節約につながります。 これにより、CoinJoinベースによる支払いの方が、自分単独の支払いよりも安くなり、 より多くのプライベートな支払いを行う緩やかなインセンティブを提供します。

  • ● SIGHASH_ANYPREVOUT: 通常のBitcoinのトランザクションには、1つ以上のインプットが含まれており、 そのインプットのそれぞれがtxidを使って以前のトランザクションアウトプットを参照しています。 この参照により、Bitcoin Coreのような完全な検証ノードに、トランザクションがどれだけの金額を使用できるか、 またその支払いが許可されたことを証明するためにどんな条件を満たす必要があるかが伝えられます。 Bitcoinトランザクションの署名を生成するすべての方法は、Taprootを使用する場合も使用しない場合も、 prevoutのtxidにコミットするか、prevoutにまったくコミットしないかのいずれかです。

    これは事前に準備された正確な一連のトランザクションを使用したくないマルチユーザー・プロトコルにとって問題となります。 ユーザーが特定のトランザクションをスキップしたり、witnessデータ以外のトランザクションの詳細を変更したりすると、 後続のトランザクションのtxidが変更されます。 txidを変更すると後続のトランザクション用に事前に作成されていた署名が無効になります。 これによりオフチェーンプロトコルは古いトランザクションを送信したユーザーにペナルティを与える （LN-penaltyなど）を実装しなければなりません。

    SIGHASH_ANYPREVOUTは、 署名がprevout txidへのコミットをスキップすることを許可することで、 この問題を解消することができます。使用される他のフラグによっては、 prevoutやトランザクションに関する他の詳細（金額やScriptなど）にコミットしますが、 以前のトランザクションで使用されていたtxidは関係なくなります。 これにより、LNのeltooレイヤーの実装や、 Vaultや他のコントラクトプロトコルの改善の両方が可能になります。

  • ● 委譲と一般化: （Taprootまたはそれ以外の）Scriptを作成した後は、 秘密鍵を渡さない限り、そのScriptから支払いをする能力を他の人に委譲する方法はほぼありません （BIP32ウォレットを使っている場合はとても危険です）。 さらにTaprootは、keypathによる支払いや少数のScriptベースの条件のみを使用したいユーザーにとって、 より手軽な価格を提供します。Taprootを一般化し、署名者の委譲を行うことで、 Taprootを強化する方法がいくつか提案されています:

    • ● Graftroot: Taprootのアイディアが紹介された直後に提案されたGraftrootは、 誰もがTaprootのkeypath支払いをできるようにする追加機能を与えるものです。 keypathの署名者は資金を直接使用する代わりに、資金を使用できる新しい条件を記述したScriptに署名し、 そのScriptの条件を満たすことができる人に使用権限を委譲することができます。 署名およびScript、そのScriptを満たすために必要なデータが、支払いトランザクションで提供されます。 keypathの署名者は、実際に支払いが発生するまで、オンチェーンデータを作成することなく、 この方法で無制限の数のScriptに委譲することができます。

    • ● 一般化されたTaproot (g’root): その数ヶ月後、Anthony Townsは、公開鍵ポイントを使って、 必ずしもMASTのような構造を使わずに、 複数の異なる支払い条件にコミットする方法を提案しました。 この一般化されたTaproot (g’root) 構造は、「Taprootの仮定が成立しない場合に、 より効率的になる可能性がある」としています。 また、「ソフトフォーク・セーフなインプットをまたぐ集約システムを簡単に構築する方法を提供する」 としています。

    • ● Entroot: Graftrootとg’rootを最近合成したもので、 多くのケースを単純化し、より帯域幅を効率化しています。これは、トップレベルのkeypath支払いを作成できる人だけでなく、 entrootブランチのいずれかを満たすことができる誰からでも署名者の委譲をサポートすることができます。

  • ● 新旧opcode: Taprootのソフトフォークには、 Bitcoinに新しいopcodeを追加するための改良された方法（OP_SUCCESSx opcode）を提供する Tapscriptのサポートが含まれています。 Bitcoinの初期に追加されたOP_NOPx (no operation) opcodeと同様に、 OP_SUCCESSx opcodeは、常にsuccessを返すことのないopcodeに置き換えられるよう設計されています。 提案されている新しいopcodeには次のようなものがあります:

    • ● 旧opcodeの復活: 数式や文字列操作のための多くのopcodeが、セキュリティの脆弱性への懸念から2010年に無効化されました。 多くの開発者は、これらのopcodeがセキュリティレビューを経て再び有効になること、 そして（場合によっては）より大きな数値が扱えるよう拡張されることを期待しています。

    • ● OP_CAT: 以前無効化されたopcodeの内の１つで、特筆すべきはOP_CATです。 研究者が、OP_CAT自体でBitcoinのあらゆる種類の興味深い動作を可能にしたり、 興味深い方法で他の新しいopcodeと組み合わせることができることを発見しています。

    • ● OP_TAPLEAF_UPDATE_VERIFY: ニュースレター #166に掲載したように、OP_TLUV opcodeは、 Taprootのkeypathとscriptpathの機能を使って特に効率的かつ強力なCovenantsを可能にします。 これは、JoinPoolやVaultおよび、 その他のセキュリティやプライバシーの改善を実装するために使用できます。 また、OP_CHECKTEMPLATEVERIFYとうまく組み合わせることができます。

上記のアイディアはすべて、まだ提案に過ぎません。どれも成功するとは限りません。 各提案を成熟させるのは研究者や開発者であり、その後Bitcoinに各機能を追加することが、 Bitcoinのコンセンサスルールを変更する労力に値するかどうかをユーザーが判断することになります。

アクティベーション時に何が起こる？

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

この投稿の公開から2週間以内に、Taprootはブロック709,632でアクティベートされる予定です。 何が起こるかは分かっていますし、いくつか起こる可能性のある障害も分かっています。

ベストで最も可能性の高い結果は、すべてがうまくいくことです。 何も起こらなければ、通常のユーザーには何も見えないはずです。 ノードを注意深く観察したり、Taprootトランザクションを作成しようとする人だけがなにかに気づくでしょう。 ブロック709,631では、私たちが認識しているほぼすべてのフルノードが同じコンセンサスルールを適用します。 その1ブロック後、Bitcoin Core 0.21.1、22.0または関連リリースを実行しているノードは、 それより前のソフトウェアリリースでは実行されていなかった追加のTaprootルールを適用します。

これには、ノードソフトウェアの以前のバージョンと新しいバージョンで異なるブロックを受け入れるというリスクが伴います。 これは2015年のBIP66ソフトフォークのアクティベーション中に発生し、 6ブロックのチェーン分岐といくつかの短いチェーン分岐が発生しました。 この問題の再発を防ぐために、かなりの技術的な努力が払われてきました。 同様の問題は、マイナーが意図的にTaprootで無効なブロックをマイニングするか、 Bitcoin Coreや関連ノードソフトウェアにハードコードされた安全対策を無効にした場合にのみTaprootで起こるでしょう。

具体的には、チェーン分岐を発生させるためには、マイナーはTaprootのルールに従わずに （segwit v1アウトプットである）Taprootアウトプットから支払いをするトランザクションを作成または受け入れる必要があります。 マイナーがそうした場合、Bitcoinノードのオペレーターが経済的なコンセンサスから、 Taproot無効ブロックを拒否した場合、マイナーは少なくとも6.25 BTC（執筆時点で約$400,000 USD）を失うことになります。

ノードオペレーターがどうするかは、無効なブロックを作ってみないことには分かりません。 ノードは完全にプライベートに実行できますが、プロキシの測定値では、 ノードオペレーターの50%以上がBitcoin CoreのTaproot適用バージョンを実行していることを示しています。 これはTaproot無効ブロックを作成したマイナーが、ネットワークによって拒否されることを確実にするのに十分すぎるほどでしょう。

非常に可能性は低いですが、一時的なチェーン分岐は理論的には可能です。 ForkMonitor.infoのようなサービスやBitcoin Coreのgetchaintips RPCを使って、分岐を監視することが可能です。 分岐が発生した場合、軽量クライアントは誤った承認を受け取る可能性があります。 2015年のチェーン分岐のように、6承認得ることは理論的に可能ですが、 それはマイナーが250万ドル近い価値を失ったことを意味します（2015年の損失は約5万ドルでした）。 これほど大きな価値がかかっているので、マイナーは半年前に準備を通知したTaprootのルールを実際に適用することが期待できます。

私たちが想像するほぼすべての障害状況において、シンプルで効果的な一時的な対応は、承認数の上限を上げることです。 通常、支払いを受け入れるのに6承認待っている場合、 問題が解決されるか、さらに高い承認数が必要であることが明確になるまでの数時間、 承認数を30回にすぐに上げることができます。

フルノードオペレーターの経済的なコンセンサスからTaprootのルールを適用すると確信しているユーザーやサービスにとっては、 さらにシンプルな解決策として、どのトランザクションが承認されたかという情報のみを Bitcoin Core 0.21.1以降（まてあは互換性のあるノード実装）から取得することができます。

Optechでは、Taprootのアクティベーションはスムーズに進むと予想していますが、 取引所やブロック709,632付近で大きな金額を受け入れる人は、 ノードをアップグレードするか、問題の兆候がある場合には承認数の上限を一時的に引き上げる準備をすることを勧めています。

ありがとう！

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

Taprootは、このコラムが公開されてから数日後になると思われるブロック709,632でアクティベートされます。 このシリーズの最終回として、Taprootの開発とアクティベートに協力してくださった多くの方々に、 そして間もなく適用を開始する方々に感謝します。 以下に記載されていない多くの方々にも感謝の意を表したいと思いますが、 記載漏れがあったらお詫びします。

Bitcoin-devメーリングリストでの議論

Taprootの背後にある重要なアイディアは、2019年1月22日の朝、数人の暗号学者による会議で誕生しました。 それは同じ日のうちにBitcoin-Devメーリングリストに投稿されました。 以下の人々は、”taproot”という名前を含むスレッドに貢献しました。

Adam Back, Andrea Barontini, Andreas Schildbach, Andrew Chow, Andrew Poelstra, Anthony Towns, Antoine Riard, Ariel Lorenzo-Luaces, Aymeric Vitte, Ben Carman, Ben Woosley, Billy Tetrud, BitcoinMechanic, Bryan Bishop, Carlo Spiller, Chris Belcher, Christopher Allen, Clark Moody, Claus Ehrenberg, Craig Raw, Damian Mee, Daniel Edgecumbe, David A. Harding, DA Williamson, Elichai Turkel, Emil Pfeffer, Eoin McQuinn, Eric Voskuil, Erik Aronesty, Felipe Micaroni Lalli, Giacomo Caironi, Gregory Maxwell, Greg Sanders, Jay Berg, Jeremy Rubin, John Newbery, Johnson Lau, Jonas Nick, Karl-Johan Alm, Keagan McClelland, Lloyd Fournier, Luke Dashjr, Luke Kenneth Casson Leighton, Mark Friedenbach, Martin Schwarz, Matt Corallo, Matt Hill, Michael Folkson, Natanael, Oleg Andreev, Pavol Rusnak, Pieter Wuille, Prayank, R E Broadley, Riccardo Casatta, Robert Spigler, Ruben Somsen, Russell O’Connor, Rusty Russell, Ryan Grant, Salvatore Ingala, Samson Mow, Sjors Provoost, Steve Lee, Tamas Blummer, Thomas Hartman, Tim Ruffing, Vincent Truong, vjudeu, yancy, yanmaani—, and ZmnSCPxj.

しかし、Schnorr署名やMASTなどTaprootに含まれているアイディアの多くは、 Taprootより何年も何十年も前から存在しています。これらのアイディアに貢献した多くの人々を列挙することはできませんが、 それでも私たちは彼らに感謝しています。

Taproot BIPのレビュー

2019年11月から、多くのユーザーと開発者がTaprootと関連する開発の組織的なレビューに参加しました。

achow101, afk11, aj, alec, amiti, _andrewtoth, andytoshi, ariard, arik, b10c, belcher, bjarnem, BlueMatt, bsm1175321, cdecker, chm-diederichs, Chris_Stewart_5, cle1408, CubicEarth, Day, ddustin, devrandom, digi_james, dr-orlovsky, dustinwinski, elichai2, evoskuil, fanquake, felixweis, fjahr, ghost43, ghosthell, gmaxwell, harding, hebasto, instagibbs, jeremyrubin, jnewbery, jonatack, justinmoon, kabaum, kanzure, luke-jr, maaku, mattleon, michaelfolkson, midnight, mol, Moller40, moneyball, murch, nickler, nothingmuch, orfeas, pinheadmz, pizzafrank13, potatoe_face, pyskell, pyskl, queip, r251d, raj_149, real_or_random, robert_spigler, roconnor, sanket1729, schmidty, sipa, soju, sosthene, stortz, taky, t-bast, theStack, Tibo, waxwing, xoyi-, and ZmnSCPxj.

GitHubのプルリクエスト

Bitcoin CoreにおけるTaprootの主な実装は、レビューのため2020年1月に2つの プルリクエストが提出されました。 それらのPRにGithubでレビューを残したのは以下の方々です。

Andrew Chow (achow101), Anthony Towns (ajtowns), Antoine Riard (ariard), Ben Carman (benthecarman), Ben Woosley (Empact), Bram (brmdbr), Cory Fields (theuni), Dmitry Petukhov (dgpv), Elichai Turkel (elichai), Fabian Jahr (fjahr), Andreas Flack (flack), Gregory Maxwell (gmaxwell), Gregory Sanders (instagibbs), James O’Beirne (jamesob), Janus Troelsen (ysangkok), Jeremy Rubin (JeremyRubin), João Barbosa (promag), John Newbery (jnewbery), Jon Atack (jonatack), Jonathan Underwood (junderw), Kalle Alm (kallewoof), Kanon (decryp2kanon), kiminuo, Luke Dashjr (luke-jr), Marco Falke (MarcoFalke), Martin Habovštiak (Kixunil), Matthew Zipkin (pinheadmz), Max Hillebrand (MaxHillebrand), Michael Folkson (michaelfolkson), Michael Ford (fanquake), Adam Ficsor (nopara73), Pieter Wuille (sipa) Sjors Provoost (Sjors), Steve Huguenin-Elie (StEvUgnIn), Tim Ruffing (real-or-random), and Yan Pritzker (skwp).

これには、Bitcoin Coreに関連するいくつかのPRや、（Bitcoin Coreで使用される） libsecp256k1のSchnorrサポートや代替ノードソフトウェアなど、他のソフトウェアのTaprootの実装作業は含まれていません。

Taprootアクティベーションの議論

Taprootの実装がBitcoin Coreにマージされてから、それをどのようにアクティベートするかを決めるのはコミュニティの役目でした。 数ヶ月に及ぶ議論が行われましたが、その中で最も活発だったのは、 taproot activation IRCチャンネルでの以下のユーザー、開発者およびマイナー間の会話でした:

6102bitcoin, AaronvanW, achow101, aj, alec, Alexandre_Chery, Alistair_Mann, amiti, andrewtoth, andytoshi, AnthonyRonning, ariel25, arturogoosnargh, AsILayHodling, averagepleb, bcman, belcher, benthecarman, Billy, bitcoinaire, bitentrepreneur, bitsharp, bjarnem, blk014, BlueMatt, bobazY, brg444, btcactivator, btcbb, cato, catwith1hat, cguida, CodeShark__, conman, copumpkin, Crash78, criley, CriptoLuis, CubicEarth, darbsllim, darosior, Day, DeanGuss, DeanWeen, debit, Decentralizedb, devrandom, DigDug, dome, dr_orlovsky, duringo, dustinwinski, eeb77f71f26eee, eidnrf, elector, elichai2, Emcy, emzy, entropy5000, eoin, epson121, erijon, eris, evankaloudis, faketoshi, fanquake, fedorafan, felixweis, fiach_dubh, fjahr, friendly_arthrop, GeraldineG, gevs, gg34, ghost43, ghosthell, giaki3003, gloved, gmaxwell, graeme1, GreenmanPGI, gr-g, GVac, gwillen, gwj, gz12, gz77, h4shcash, harding, hebasto, hiro8, Hotmetal, hsjoberg, huesal, instagibbs, Ironhelix, IT4Crypto, ja, jaenu, JanB, jeremyrubin, jimmy53, jnewbery, jonatack, jonny100051, jtimon, kallewoof, kanon, kanzure, Kappa, keblek, ksedgwic, landeau, lucasmoten, luke-jr, maaku, Majes, maybehuman, mblackmblack, mcm-mike, Memesan, michaelfolkson, midnight, MikeMarzig, mips, mol, molz, moneyball, mrb07r0, MrHodl, murch, naribia, newNickName, nickler, nikitis, NoDeal, norisgOG, nothingmuch, occupier, OP_NOP, OtahMachi, p0x, pinheadmz, PinkElephant, pox, prayank, prepaid, proofofkeags, provoostenator, prusnak, qubenix, queip, r251d, rabidus, Raincloud, raj, RamiDz94, real_or_random, rgrant, riclas, roasbeef, robert_spigler, rocket_fuel, roconnor, rovdi, rubikputer, RusAlex, rusty, sanket1729, satosaurian, schmidty, sdaftuar, setpill, shesek, shinobiusmonk, snash779, solairis, somethinsomethin, stortz, sturles, sugarpuff, taPrOOteD, TechMiX, TheDiktator, thomasb06, tiagocs, tomados, tonysanak, TristanLamonica, UltrA1, V1Technology, vanity, viaj3ro, Victorsueca, virtu, walletscrutiny, wangchun, warren, waxwing, Whatisthis, whuha, willcl_ark, WilliamSantiago, windsok, wumpus, xxxxbtcking, yanmaani, yevaud, ygrtiugf, Yoghurt11411, zmnscpxj, and zndtoshi.

マイナーのシグナリング

また、ブロック681,408以降、Taprootのルールを適用する用意があることを表明してくれたすべてのマイナーに感謝します。

サイドプロジェクト

Taprootのアクティベーションは始まりに過ぎません。 今後は、開発者やユーザーが利用可能になった新しい機能を使い始めることになります。 MuSigや他のプロジェクトなど、何年も前から準備してきた人もいます。 そのような開発者のリストを入手する便利な方法はありませんが、いずれにしてもすべての開発者に感謝しています。

ノードオペレーター

最も重要なことは、Bitcoin Core 0.21.1以降（または互換性のあるソフトウェア）にアップグレードした 数千のBitcoinの完全な検証ノードのオペレーターに感謝することです。 彼らは、支払いを受け取るためにそのノードを使用し、 ブロック709,632から始まるTaprootのルールに従うブロックのトランザクションのみを受け入れることを保証します。 これにより、他のすべてのBitcoinユーザーにもTaprootに準拠したブロックのみを受け入れるという経済的なインセンティブが働き、 誰もがTaprootの機能を安全に利用できるようになります。

Footnotes

  1. Electrumがsegwit v0にアップグレードされた際、 bech32アドレスで受け取りたい人は誰でも新しいシードを生成する必要がありました。 これは技術的には必要ありませんでしたが、 Electrumの作者は自分たちのカスタムシードの導出方法にいくつかの新しい機能を導入することができました。 その１つがシードのバージョン番号で、シードを使用するスクリプトを指定する機能です。 これにより古いスクリプトを安全に非推奨にできます（例えば、将来リリースされる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を持つ支払いトランザクションに事前署名することができますが、 そうすると「アクティブ」なキーを使った別の支払いパスはまったく必要ありません。 また、通常コインを受け取った時点で、そのコインをどう使うかはわかりません。 ↩