OP_CHECKTEMPLATEVERIFY

アンナは資金を用意し、後からペーターとエヴァに分配したいと考えています。お金を預かる人の約束だけに頼りたくはありません。Bitcoin では、まだ使っていない資金は取引の出力、UTXO として記録され、それぞれに金額と使用条件があります。CTV はその条件に具体的な分配計画を組み込めます。誰かが出力を使うとき、ネットワークのルールを確認するソフトウェアであるノードが、新しい取引が計画を守っているか検証します。別の受取人や指定と異なる金額では、検証に通りません。Jeremy Rubin が BIP119 でこの提案を説明しており、BIP 番号は2020年に割り当てられました。 [1] [3]

テンプレートは、入力で過去の出力をいくつ参照し、どの新しい出力を作るかという送金の構成を定めます。新しい出力については、金額とスクリプト、つまり今後の使用条件を固定します。さらに詳しく見ると、BIP119 は取引のバージョン、取引全体の時間制約に使う nLockTime、時間制限に影響しうる入力の nSequence、そして現在検査している入力の位置も含みます。支出に必要なデータを渡す入力スクリプト、scriptSig が一つでも空でなければ、すべての scriptSig フィールドを対象とするハッシュも加わります。受取人の一覧だけではなく、対象となる別のデータを変えても違うテンプレートになるのです。使う古いコインの具体的な参照先と金額については、別の論点として後で説明します。 [1]

バイトはデータ量を表す一般的な単位です。提案された検査では、テンプレートのデータから SHA256 で計算した 32 バイトのハッシュ値を使います。ノードは、その出力を使う取引から同じ指紋を計算し、不一致なら拒否します。デジタル署名は、秘密の数値である秘密鍵を使って支払いの許可を証明し、鍵そのものは公開しません。スクリプトの別の部分が署名を要求することもあり、CTV が署名を全面的に置き換えるわけではありません。別の長さの引数はこの検査を行わず、将来の拡張用に予約されていますが、中継ポリシーでは拒否される場合があります。誤った引数だからといって、安全に資金をロックできるとは限りません。 [1] [4] [12]

次の例では、ビットコインの最小単位である sats を使います。テンプレートのハッシュ値は、支出する特定の UTXO を指す outpoint や、その入力金額を直接は含みません。ただし入力数は固定されます。入力を一つだけ認め、出力の合計を 99,000 sats とした場合を考えましょう。100,000 sats の入力なら、1,000 sats が手数料になります。入力が出力合計未満なら、この取引には足りません。逆に入力が多くても出力が同じなら、増えるのは手数料であり、お釣りが自動で作られるわけではありません。 [6] [9]

テンプレートは、遅延と回復経路を持つスクリプトの別の出力へ移すことを要求できます。これを使えば、望まない引き出しに対応する時間を設けた保管庫を構成できます。ただし CTV だけで安全が完結するわけではなく、鍵、後続出力の条件、監視、回復取引が間に合って承認されることが重要です。一部の制約は事前署名済み取引でも用意できますが、協力や鍵の削除に関する要件が異なります。 [8] [5]

ブロックは、共有する履歴に追加する取引のまとまりです。提案されている混雑制御では、後の分配を約束する出力をまず承認させます。各受取人の個別の出力は、その後の取引で、例えばネットワークが空いた時に作れます。受取人には計画のデータと、自分の権利を実際に行使する手段が必要です。これは自分のアドレスへの通常の支払いが既に承認された状態とは異なり、限りあるブロック容量を無限にはしません。 [7] [11]

ウォレットは、ビットコインを受け取ったり送ったりするためのアプリや機器です。アンナは支払いを公開するずっと前に計画を用意できますが、その時点では将来の手数料率を知りません。出力が固定されているため、自分のウォレットに戻す金額を自由に減らして、その差額を採掘者に渡すことはできません。構成には手数料を追加する方法が必要です。一つは適切に準備した CPFP です。後続の取引で元の取引の出力を使い、両方を採掘者に取り込んでもらうための手数料を提示します。別の方法は、最初から追加の入力を認めるテンプレートを作ることです。入力を一つしか認めないテンプレートに、その入力を後から足すことはできません。Mempool は各ノードが保持する未承認取引の集まりであり、受け入れられてもブロックに入る保証はありません。 [2] [6] [10]

CTV 単独で検査するのは特定のテンプレートです。取引の全データを読み取り、自由に比較する汎用言語ではありません。将来の取引が分岐する計画を作ることはできますが、一般的な再帰型 Covenants と同じではありません。他の提案命令との組み合わせなら、さらに多くのことが可能になる場合があります。実演が CTV だけを使うのか、複数の変更に依存するのかを確認する必要があります。 [1] [2]

2026年10月17日の確認時点で、BIP119 は Draft、つまり検討中の提案です。現在のブロック検証では何もしない命令 OP_NOP4 に、新しい検査機能を与える構想です。このように共通ルールを厳しくする変更を Soft Fork と呼びます。ただし、文書自体は有効化の方法を定めていません。BIP を公開しても、opcode が実際に強制される命令になるわけではありません。コード、開発者の支持、デモ用ウォレットも、Bitcoin の本番ネットワークである mainnet での強制を証明しません。各実演について、使用するネットワーク、ルール、依存する他の提案を確認する必要があります。 [1]

ルールが強制されるまでは、スクリプトに書かれているだけで保護を期待できません。コンセンサスと mempool による拒否は別です。CTV 対応環境でも、逃げ道のない単一の必須テンプレートは、資金不足の出力を使えなくする可能性があります。ただし新しく少額を入金したからといって、別の正しく資金を入れた UTXO まで自動で凍結されるわけではありません。安全な設計には、金額、手数料、バックアップ、すべての回復経路の確認が必要です。 [1] [4] [6]