OP_CHECKSEQUENCEVERIFY

このオペコードはスタックから数値を読み取り、使用される入力のシーケンスフィールドと比較するため、時計はカレンダー上の日付ではなく、コインがブロックに取り込まれた時点から始まります。これを定義したのはBIP-112で、ネットワークは2016年7月4日にブロック419,328でこれを適用し始めました。開設するすべてのライトニングネットワークのチャネルはこれに依存しています。

仕組み

オペコード178は以前OP_NOP3と呼ばれ、何も行いませんでした。このルールがチェーンの分裂ではなくソフトフォークとしてネットワークに届いたのはそのためです。

チェックは3つの入力に対して行われます。スタック上の数値、使用される入力のシーケンスフィールド、そしてトランザクションのバージョンです。バージョン2以上が必要です。BIP-68の相対タイムロックのルールはそのバージョン以降にのみ適用されるからです。どちらかの値の最上位ビットが設定されている場合、タイムロックは無効になり、オペコードは処理を中止します。そうでない場合、両者の単位が一致していなければならず、スタックの値はシーケンスフィールドを超えてはなりません。

単位には2種類があり、1回の比較で混在させることはできません。特定のフラグを解除すると数値はブロック数を数え、設定すると512秒の間隔を数えます。いずれの場合も16ビットが利用できるため、上限は65,535ブロック、およそ455日、または同じ数の512秒間隔となり、それは389日を少し下回ります。それより長い待機には、代わりに絶対タイムロックが必要です。

失敗は遅延ではなく、拒否です。待機期間が終わる前の使用は、キューで待つ保留中のトランザクションではなく、どのノードもリレーせず、どのマイナーも取り込まない無効なトランザクションです。コインが十分に古くなるまで、何も再試行する必要はなく、その時点でまったく同じトランザクションが有効になります。

使われる場面

取引量で最大の利用者はライトニングネットワークであり、このオペコードはすべてのチャネルであなた自身の側を保護するスクリプトに含まれています。

チャネルが一方的に閉鎖されると、閉鎖する側の残高は、遅延が経過するまで引き出せない出力に入ります。これはBOLT 3のto_self_delayで、通常は数百ブロックです。この遅延は、閉鎖が古い状態を使った場合に、相手側のピアが失効を公開して資金を取得するための時間枠を確保するために存在します。いずれの場合もあなたの資金は安全ですが、だからこそ強制閉鎖では1日以上待たされ、協調閉鎖では即座に支払われるのです。

同じ構造は、サブマリンスワップやアトミックスワップにも現れます。そこでは、相手方が請求する公正な機会を得た後にのみ返金経路が開く必要があります。また、長期間の沈黙の後にバックアップ鍵が使えるようになるリカバリーウォレットにも現れます。

1つの落とし穴には警告が必要です。相対タイムロックは、使用される特定のコインの承認時点から計測されるため、そのコインが移動するたびにリセットされます。ダストの統合、おつりのスイープ、またはウォレットによる出力の並べ替えは、設定したすべてのリカバリー分岐のカウントダウンをリセットし、来月バックアップ鍵が機能すると期待していた相続人は、時計がゼロに戻っているのを目にするかもしれません。

OP_CHECKSEQUENCEVERIFY vs OP_CHECKLOCKTIMEVERIFY

CSVはコインがどれだけ存在しているかを問い、CLTVは今何時かを問います。この2つのオペコードは番号上で隣り合っており、178と177で、まったく異なる用途のために選ばれます。

期限が実際の日付である場合は絶対形式を使用します。2030年に解除される信託、既知の高さで失効する返金などです。待機がコントラクトの開始時に始まるべき場合は相対形式を使用します。これは一度書いて何度も再利用されるスクリプトに必要なことです。ライトニングネットワークはチャネルの遅延に絶対タイムロックを使用できませんでした。今日開設されたチャネルと来年開設されるチャネルでは異なるスクリプトが必要になるからです。また、この2つは数か月の間隔をあけて登場しました。CLTVは2015年12月14日のブロック388,381で、CSVは翌年の7月で、2つ目が存在したのは主に、1つ目だけでは支払いチャネルを構築するのに十分でなかったためです。