OP_CHECKLOCKTIMEVERIFY

タイムロックを、コインを使用するトランザクションではなくコイン自体に書き込むものです。Peter ToddがBIP65で仕様を定め、そこで旧来の何もしないオペコードNOP2の枠を引き継ぎ、このルールは2015年12月のブロック388,381以降、適用されています。相続プランやリカバリー経路を設定したことがあれば、このオペコードが扉を閉ざしておく役割を果たしています。

仕組み

OP_CHECKLOCKTIMEVERIFYはスクリプトスタックから数値を1つ読み取り、コインを使用しようとするトランザクションのlocktimeフィールドと比較し、使用が早すぎる場合はスクリプト全体を中断します。

BIP65はチェックが失敗する5つの方法を挙げています。スタックが空である、最上位の項目が負である、その項目とトランザクションのlocktimeがブロックを数えるのか秒を数えるのかで一致しない、その項目がトランザクションのlocktimeより大きい、またはインプットのシーケンス番号が0xffffffffに設定されている、というものです。最後の条件は明らかな穴を塞ぎます。すべてのインプットがfinalとマークされているとlocktimeは完全に無視されるため、これがなければ使用者は単に期限を無効にして金を持ち去ることができてしまいます。

このようなスクリプトを初めて読む人を驚かせる点が2つあります。オペコードはチェックする数値を消費しないため、実際のスクリプトではスタックを整えるためにその後にOP_DROPを続けます。そして通常の4バイトではなく5バイトのオペランドを受け付けます。比較しなければならない最大値が2**32-1、つまりチェックするフィールドの全範囲だからです。

ソフトフォークの仕組みは通常のものでした。何もしないオペコードを再定義することは、アップグレードされていないソフトウェアには見えません。古いノードはオペコードを実行し、何もせず、そのままブロックを受け入れます。有効化には当時のマイナーのシグナリング閾値が使われ、適用を開始するには1,000ブロック中750ブロック、必須にするには1,000ブロック中950ブロックでした。

使われる場面

OP_CHECKLOCKTIMEVERIFYは、日付が来るまで資金を動かせないあらゆる場面に現れます。

相続およびリカバリー用ウォレットが最も明確な例です。ディスクリプターは、自分の鍵はいつでも使用できる一方、バックアップ鍵は指定された高さの後にのみ使用できると記述でき、これにより相続人は誰の協力も、封印された封筒を保管する弁護士も必要としない経路を得られます。Miniscriptはこれをafter()フラグメントとして記述し、対応しているウォレットは生のスクリプトではなく平易な言葉で高さを表示します。

ライトニングネットワークは、ルーティングされる支払いの絶対的な期限にこれを使います。BOLT11のインボイスは最終的な有効期限デルタを伴い、既定では18ブロックで、ルート上のハッシュ化されたコントラクトはその数値の上に積み重ねられ、支払いが完了しない場合に各ホップが定められた順序で資金を取り戻せるようになっています。

エスクローと信頼を必要としない返金も同じ形をとります。今スクリプトに支払い、相手方が署名しなければ、期限が過ぎた時点で資金を取り戻します。このオペコードは、「タイムロック付き保管庫」を製品として販売する人に対する正直な答えでもあります。そうした製品の中身は、これがすべてだからです。

OP_CHECKLOCKTIMEVERIFY vs OP_CHECKSEQUENCEVERIFY

OP_CHECKLOCKTIMEVERIFYは時点を指定し、OP_CHECKSEQUENCEVERIFYは期間を指定します。一方は「12月より前ではない」と言い、もう一方は「この特定のコインが確認されてから144ブロック後までではない」と言い、時計が動き出すのは2つ目の方だけです。BIP112が相対的な形式を定義し、それは絶対的な形式の約7か月後の2016年7月、ブロック419,328で有効になりました。コントラクトプロトコルは両方を、多くの場合1つのスクリプト内で、契約全体を区切る絶対的な期限と、一方の当事者に反応するための時間的猶予を保証する相対的な遅延として使います。