OP_CHECKTEMPLATEVERIFY

BIP-119がこれを説明しており、Jeremy Rubinが2020年1月に最初の草案を公開し、ネットワークはこれを採用していません。このオペコードはスタックから32バイトのハッシュを受け取り、支出トランザクションのテンプレート、すなわちそのバージョン、ロックタイム、入力数、シーケンス、出力、入力インデックスのハッシュが一致しない限り失敗します。ウォレットの中でこれを利用しているものはなく、ソフトフォークが有効になるまで利用されることもありません。

仕組み

状態： 提案中で、有効化されていません。BIP-119は2020年から草案のままであり、2022年に提案された有効化は多くの反対を受けて棚上げされ、Bitcoin Coreにはこれに関するデプロイパラメーターが含まれていません。

この設計は古いアップグレードの手法を再利用しています。以前はOP_NOP4だったオペコード179は現在まったく何も行わないため、これを含むスクリプトはネットワーク上のすべてのノードにとって有効です。ソフトフォークはそのバイトを再定義し、アップグレードしたノードがチェックを実行する一方で古いノードはスクリプトをそのまま通し続けます。CLTVがOP_NOP2を、CSVがOP_NOP3を経て通ったのと同じ経路です。

何をハッシュに含めるかは、並外れた注意をもって選ばれています。テンプレートは出力、金額、入力数とそのシーケンス番号を対象としますが、アウトポイント、すなわち支出されるコインのtxidは意図的に除外しています。これを除外することには、提案全体が依拠する2つの帰結があります。第一に、資金提供のトランザクションが存在する前にハッシュを計算できるため、将来の支出の連鎖を構築してから資金を提供できます。第二に、テンプレートはそれ自体へのコミットメントを含むことができないため、制限を永久に繰り返す形にすることはできません。支持者がこれを狭いコベナントと呼ぶのはそのためです。

その結果、発生する前にtxidが分かっている支出となります。ウォレットは、後に存在する支払いの領収書をあなたに渡し、そのコインの他の支出が不可能であることを証明できます。

どこで見られるか

OP_CHECKTEMPLATEVERIFYはメインネット上のどこでも動作していないため、目を向けるべき場所は、このオペコードが有効になった場合にリリースされる、独自のsignet上に構築されたアプリケーションの集合です。

最も多く挙げられるのは混雑制御です。手数料の急騰に直面した取引所は、1,000件の出金を、後続の支払いのツリーにコミットする単一の出力にまとめて支払います。各ユーザーは後から自分のブランチを展開し、手数料が下がったときに受け取ることができ、取引所は1,000個ではなく1つの出力を支出したことになります。2つ目はボールトです。出金はまず遅延付きの中間出力に着地しなければならず、その要求があなた自身のものでなかった場合に、資金をコールドストレージに引き戻す猶予が生まれます。ペイメントプールや非対話型のライトニングネットワークのチャネル開設も、同じくコミットしてから展開する形を用います。

ビットコインを購入する人にとって正直な立場は、これはあなたが実行できることを何も変えないというものです。この略語を認識しておく価値があるのは、ビットコインがどうなるべきかをめぐる議論で絶えず登場するからであり、また、一部のカストディサービスが宣伝するボールト機能は、このオペコードがもし有効になれば真に強制可能になるからです。

OP_CHECKTEMPLATEVERIFY vs OP_CHECKLOCKTIMEVERIFY

OP_CHECKTEMPLATEVERIFYは支出トランザクションの形を制約するのに対し、OP_CHECKLOCKTIMEVERIFYは支出がいつ行われるかを制約し、資金がどこへ行くかについては何も述べません。ほぼ同一の名前のため、この2つは絶えず混同されます。

もう1つの違いは状態であり、重要なのはこちらです。OP_CHECKLOCKTIMEVERIFYは2015年12月14日のブロック388,381以降強制されており、ライトニングネットワーク、エスクロースクリプト、相続用ウォレットで毎日使われています。OP_CHECKTEMPLATEVERIFYはメインネット上の単一のノードによっても強制されたことがありません。サービスがあなたのコインはテンプレートのコミットメントで保護されていると述べるなら、それはネットワークが現在チェックしていないものを説明していることになります。