CLTV

アンナは、通常の支払いをペーターと共同で承認する保管方法を考えています。長期間連絡が取れなくなった場合に備え、決めた境界を過ぎてから使える予備の経路も用意したいのです。CLTV はこの時間条件をスクリプト、つまり受け取ったコインを使うための規則に組み込めます。nLockTime フィールドだけなら、遅らせられるのは特定の取引に限られます。CLTV があれば、より低い境界の新しい取引を作ってその経路の条件を回避することはできません。ただし、ほかの分岐には別の規則を設定できます。 [1] [5]

CLTV は所有者を識別せず、お金も送りません。復旧経路がアンナの署名を要求するなら、時間条件を満たした後も署名が必要です。秘密鍵は、そのような署名を作るために使う秘密の数値です。時間がたっても紛失した秘密鍵は戻りません。コインが別のアドレスへ自動的に移ることもなく、誰かが有効な取引を作成し、署名して配信する必要があります。また、別の分岐が早い支出を認めるなら、復旧用の分岐にある時間制限だけでそれを制限することはできません。 [1]

ブロックは、共有する履歴に追加する取引のまとまりです。CLTV は、あらかじめ定めた点に結び付く条件に向いています。「このコインを受け取ってから一定数のブロックを待つ」という条件ではありません。後者を扱うのは CSV と、相対ロックの規則を定めた BIP 68 です。その場合は、特定の出力がいつ承認されたかが重要になります。出力とは、受け取った金額とその支出条件の組み合わせです。どちらも正確な日付を保証しません。採掘の間隔は変動し、再編成によって承認済みの履歴が変わることもあります。再編成とは、ネットワークが別の有効な分岐を採用し、それまでのブロック履歴の一部を置き換えることです。 [1] [7] [8] [9]

CLTV は値を二種類に区別します。500000000 未満ならブロック高、つまりチェーン内の位置を表します。この境界以上なら、時刻を数値で記録したタイムスタンプです。スクリプトの条件と、コインを使う取引の nLockTime は同じ種類でなければなりません。単に数の大小を見るだけでは不十分です。ブロックの位置と時刻を同じ意味の数として比べることはできません。 [1] [3] [5]

Full Node は規則を独立に検証するノードです。スクリプトの非負の境界値を、取引の絶対的な nLockTime と比較します。境界値は nLockTime 以下でなければならず、この検査では等しい値も認められます。ただし、特定のブロックへ取引を取り込むための規則も別途満たす必要があります。CLTV はパソコンの時計を読まず、朝までプログラムを停止することもありません。検査に失敗すれば、その経路で支出しようとする試みは無効です。 [1] [3] [4]

取引の入力は、以前受け取ったどのコインを使うかを示します。そのフィールドの一つが nSequence です。CLTV が検査する入力では、最終シーケンスを意味する特別な値 0xffffffff を使えません。すべての入力がこの値なら nLockTime を無効化できてしまいます。CLTV は対象入力を非最終にすることで、それを防ぎます。ただし、これだけで特定の相対待機時間が自動設定されるわけではありません。それは別の規則の役目です。 [1] [3] [4]

nLockTime が 900000 で、非最終の入力を持つ取引を考えます。この時間条件に関して最も早く入れるのはブロック 900001 です。取引を取り込むには、nLockTime が候補ブロックの高さより厳密に小さくなければならないからです。CLTV 内の比較が等しい値を認めても、ブロック 900000 では足りません。ここでいう「最終性」は取込み可能という意味であり、支払いが不可逆になったことではありません。手数料やほかの条件、採掘者の選択によって承認はさらに遅れることがあります。 [4]

時刻の判定では、BIP 113 に従って前のブロックの Median Time Past を使います。直近の最大 11 ブロックのタイムスタンプを並べたときの中央の値であり、自分の時計でも、現在採掘中のブロックの時刻でもありません。時刻を表す nLockTime は、この値より厳密に小さい必要があります。そのため、現地時間の正午ちょうどに使えるとは約束できません。ネットワークが検証できる条件であって、正確な送金予定表ではないのです。 [2] [4]

評価中のスクリプトはスタックという、データを積み重ねる作業領域を使います。CLTV は時間引数を検査しますが、取り除きません。単純な模式例では、OP_CHECKLOCKTIMEVERIFY の後に OP_DROP を置いて引数を除き、公開鍵を積み、OP_CHECKSIG で署名を検証します。公開鍵は署名の検証に使うもので、秘密にしておく必要はありません。これは命令の役割を説明する例で、そのまま資金をロックするための完成手順ではありません。スクリプトのバージョン、初期データ、ほかのすべての支出経路も正しく設計する必要があります。 [1] [3]

BIP 65 は、以前の OP_NOP2 を置き換える soft fork、つまり規則の厳格化として CLTV を導入しました。将来の機能案にすぎないものではありません。それでも境界の種類、nLockTime、nSequence、署名、代替の分岐を含む設計全体の確認は必要です。技術的な詳細は Bitcoin Core v29.0 と掲載した仕様で確認できます。利用者にとって大切なのは、境界の前後で誰がお金を使えるのか、復旧の選択肢を理解できているかです。 [1] [3] [6] [10]