今週のニュースレターでは、Covenant opcodeの新しい提案と、 signetでの定期的なreorgの実装に関するフィードバックの要求について掲載しています。 また、Taprootの準備や、新しいリリースおよびリリース候補のリスト、 人気のあるBitcoinインフラストラクチャソフトウェアの説明など、恒例のセクションも含まれています。

ニュース

• ● Covenant opcodeの提案: Anthony Townsは、Bitcoin-Devメーリングリストに、 Covenant opcodeのアイディアの概要と、 そのopcode（および他のいくつかのtapscriptの変更）がどのように機能するかを説明する、 より技術的に詳細なメッセージを投稿しました。

  要約すると、新しいOP_TAPLEAF_UPDATE_VERIFY opcode (TLUV)は、 使用されるTaprootのインプットに関する情報を受け取り、Tapscriptの記述を変更し、 その結果がインプットと同じ位置にあるアウトプットのscriptPubKeyと同じであることを要求します。 これにより、TLUVは、OP_CHECKSIGFROMSTACK (CSFS)や OP_CHECKTEMPLATEVERIFY (CTV)などの他の提案されているopcodeと同様に、 ビットコインの使用先（Covenantの定義）を制限できます。 これまでの提案と異なるのは、Tapscriptの作成者に許可されている以下の変更点です:

  • ● 内部キーの調整: すべてのTaprootアドレスは、署名のみで使用できる内部キーにコミットします。 （TLUVを含む）Tapscriptを使用するためには、現在の内部キーを明らかにする必要があります。 TLUVでは、その鍵に加算する調整値を指定する必要があります。例えば、 内部キーが鍵A+B+Cの集約鍵である場合、鍵Cを-Cの調整値を指定することで削除できたり、 調整値Xを指定することで鍵Xを追加できます。TLUVは、変更された内部キーを計算し、 それが同じ位置のアウトプットが支払うものであることを保証します。

    Townsのメールに記載されているこの機能の強力な使用法の１つは、 Joinpoolをより効率的に作成する機能です。 Joinpoolは、それぞれがUTXOの資金の一部を管理しているものの、 その所有権をオンチェーンで公に公開する必要がない（また、UTXOの所有者の数を公開する必要もない） 複数のユーザーが共有する１つのUTXOのことです。 すべてのプール参加者が一緒に署名すれば、彼らは資金を非常にファンジブルなトランザクションで使用できます。 もし合意に至らない場合は、各プール参加者は、 （オンチェーン手数料を差し引いた）すべての資金を持ってプールを抜けるためのトランザクションを使用できます。

    現在、署名済みのトランザクションのみを使用してJoinpoolを作るのは可能ですが、 プールの各参加者が他の参加者の協力を得ずに個別に抜けれるようにするためには、 指数関数的に増加する署名を作成する必要があります。CTVにも同様の問題があり、 プールから抜けるためには、他の複数の参加者に影響を与える複数のトランザクションの作成が必要になる場合があります。 TLUVでは、１人の参加者がJoinpoolから抜けたことを明らかにするだけで、 何かに事前に署名する必要もなく、他の参加者に影響を与えることもなく、１人でいつでも抜けることができます。

  • ● マークルツリーの調整: Taprootアドレスは、Tapscriptのツリーのマークルルートにコミットすることができ、 TLUV opcodeを実行するのは、トランザクションインプット内のこれらのTapscriptの１つになります。 TLUVにより、そのScriptは、マークルツリーのその部分がどう変更されるべきかを指定することができます。 例えば、現在実行されているノード（Tapleaf）をツリーから削除したり（例えばJoinpoolを抜ける人）、 別のTapscriptへ支払うTapleafに置き換えたりすることができます。 TLUVは、変更されたマークルルートを計算し、それを同じ位置のアウトプットへ支払うことを保証します。

    Townsのメールでは、2019年のBryan BishopのVaultの設計（ニュースレター #59参照）を実装するために、 これがどう利用できるか説明されています。アリスは、安全性の低いホットウォレット用と、 安全性の高いコールドウォレット用の２つの鍵ペアを作成します。 コールドウォレットの鍵はTaprootの内部キーになり、いつでも資金を使用できます。 ホットウォレットの鍵はTLUVと一緒に使用され、ホットウォレットの鍵から2回めの支払いが送信されるまでの遅延時間を含む、 マークルツリーの変更へのみ支払いを許可します。

    つまり、アリスはホットキーで全資金の支払いを開始できますが、 そのためにオンチェーントランザクションを作成し、任意のアドレスで資金を本当に使用できるようになるまで、 遅延時間（例えば1日）が経過するのを待たなければなりません。 他の誰かがアリスのホットキーを使って支払いプロセスを開始した場合、 アリスはコールドキーを使って資金を安全なアドレスに移動させることができます。

  • ● 量のイントロスペクション: TLUVに加えて、インプットのビットコインの量と対応するアウトプットを スクリプトの実行スタックにプッシュする2つめのopcodeが追加されます。 これにより、計算や比較用のopcodeを使って使用される量を制限することができます。

    Joinpoolの場合、抜ける参加者が自分の資金のみを引き出せるようにするのに使用されます。 Vaultでは、1日につき1BTCなど、定期的な引き出し制限を設定するのに利用できます。

  この記事を書いている時点では、この提案はまだメーリングリストで初期のフィードバックを受けています。 注目すべきコメントがあれば、今後のニュースレターでまとめてご紹介します。

• ● signetのreorgに関する議論: 開発者の0xB10Cは、 signetで定期的にブロックチェーンの再編成（reorg）を行うための提案をBitcoin-Devメーリングリストに投稿しました。 最終的にreorgされるブロックは、versionフィールドの１つにシグナルをセットし、 reorgを追跡したくない人はそれらのブロックを無視できるようにします。 reorgは定期的に、おそらく1日に3回発生し、mainnetで起こりうるreorgを再現した２つの異なるパターンに従います。

  0xB10Cはフィードバックを求め、この記事を書いている時点でいくつかのコメントを受け取っています。 signetでのreorgのテストに興味のある方（またはそれを回避したい方）は、 議論を読んで参加を検討してみてください。

Taprootの準備 #13: バックアップとセキュリティのスキーム

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

先週のコラムでは、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の異なる鍵を簡単に配置することができます。 これらの鍵のいずれかが、そのアドレスで管理されているすべての資金を使用することができますが、 どのデバイスが侵害されたか一意に特定することができます。

リリースとリリース候補

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

• ● Bitcoin Core 22.0は、このフルノード実装と、 それに付随するウォレットなどのソフトウェアの次のメジャーバージョンのリリースです。 この新バージョンの主な変更点は、I2P接続のサポート、 version 2 Tor接続のサポートの削除、 ハードウェアウォレットのサポートの強化などです。 なお、ニュースレター #162に掲載しているように、 このリリースではリリース検証手順が変更されていることに注意してください。

• ● BTCPay Server 1.2.3は、責任をもって報告された３つのクロスサイトスクリプティング（XSS）の脆弱性を修正するリリースです。

• ● Bitcoin Core 0.21.2rc2は、 Bitcoin Coreのメンテナンスバージョンのリリース候補です。 いくつかのバグ修正と小さな改善が含まれています。

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

今週の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 #22079は、ZMQインターフェースにIPv6のサポートを追加しました。

• ● C-Lightning #4599は、BOLTs #843で説明されている迅速なクローズのための手数料調整プロトコルを実装しています。 先週のニュースレーターでこのプロトコルについて説明しましたが、 このプロトコルで置き換えられる既存のプロトコルについての説明は不正確でした。 従来のプロトコルでは、協調クローズトランザクションに使用する手数料率をトライ＆エラーで調整する必要があり、 現在のコミットメント・トランザクションよりも高い手数料率を設定することはできませんでした。 これは低手数料率のコミットメント・トランザクションが使用された際に手数料を引き上げるために設計された anchor outputでは意味をなしません。 新しいプロトコルでは、より高い手数料を支払うことができ、可能な場合は、より効率的な範囲ベースの調整を使用します。 今週マージされたEclair #1768も、このプロトコルを実装しています。

• ● Eclair #1930は、非デフォルトの実験的なパラメーターセットで経路探索アルゴリズムを実行できるようになりました。 これは一定の割合のトラフィックに対して自動的に行うことも、APIを通じて手動で行うこともできます。 実験的なパラメーターセット毎にメトリクスが記録され、最適な経路探索パラメーターの最適化に利用できます。

• ● Eclair #1936は、ノードのTorオニオンサービスのアドレスを非公開にしたい場合に、 そのアドレスの公開を無効にすることができるようになりました。

• ● LND #5356は、BatchChannelOpenRPCを追加し、 同じバッチオンチェーントランザクションで、異なるノードと複数のチャネルを開くことができるようになりました。

• ● BTCPay server #2830では、シングルシグのP2TR支払いの受信と送信の両方が可能なTaproot対応ウォレットの作成をサポートしました。 signetでテストされています。追加のマージ済みのPR #2837は、 ウォレットの設定でP2TRアドレスのサポートがリストされていますが、ブロック709,632までは選択できないようになっています。