Timelock

Anna と Pavel は、二人ならいつでも共有資金を使える一方、Anna 一人では一定期間後にしか使えないよう設定できます。Pavel が応答しなくなれば、遅延付きの分岐が、事前に合意した回収経路になります。分岐とは、許可された使い方の一つで、それぞれ別の条件を持てます。したがって、ロックがすべての使い方を同時に止めるとは限りません。このルールは、出力を作るときから組み込まれている必要があります。後から普通のウォレットに「一週間後に解除」とメモするだけでは足りません。待った後も、Anna は対応する鍵と、有効な取引を作るための情報を必要とします。Timelock はアクセスを制御しますが、失った鍵は復元しません。 [3]

絶対ロックは固定された境界を指定し、取引の nLockTime という項目に記録します。取引の有効な nLockTime がブロック高 1 000 000 に設定されていれば、この条件を満たす最初のブロックは 1 000 001 です。同じ値ではまだ足りません。相対ロックは、使う出力が確認されてからの待ち時間を測ります。Anna の出力がブロック 1 000 000 で作られ、その分岐に 6 ブロックの遅延が必要なら、使用時にこの条件を満たす最も早いブロックは 1 000 006 です。数字は例であり、現在のネットワークの高さではありません。署名、他の入力、追加のロック条件は引き続き満たす必要があります。六つのブロックも正確に一時間ではありません。ブロックは不規則な間隔で生まれます。相対的な待ち時間は、ウォレットを作った時や Anna がお金を使おうと決めた時から始まるのではありません。 [1] [2] [5]

Anna の待ち時間が今終わったとします。ネットワークが代わりに動いてくれるわけではありません。誰かが取引を作るか準備済みのものを使い、署名を用意し、手数料を払い、ネットワークに送る必要があります。その後で初めて、マイナーはブロックに取り込めます。Timelock の成立は一つの条件を満たしただけで、場所の予約でも自動振込でもありません。通常は使えるようになる始点を定めるのであり、その選択肢が自動的に失効する時点ではありません。チェーンの再編では、チェーンの一部が別の有効な分岐に置き換わります。それにより出力の確認や相対遅延の計算を変える場合があります。自分で仕組みを組むなら、すべての分岐、ウォレットの対応、鍵と使用ルールのバックアップを事前に確認しましょう。時間は誤った条件を直してくれません。 [2] [5]

時間条件には Median Time Past、略して MTP を使います。評価するブロックにとっては、前のブロックまでの直近 11 ブロックのタイムスタンプの中央値です。時刻を並べて真ん中、六番目を取ったものが中央値で、算術平均ではありません。BIP113 がこのルールを定め、Bitcoin Core は GetMedianTimePast で計算します。基準は Anna のスマートフォンの現在時刻でも、候補ブロック自身のタイムスタンプでもありません。カレンダーの午前零時にロック条件が満たされるとは限りません。高さによるロックはブロックを待つもので、秒を数えているのではありません。 [4]

ここで、文書に出てくる四つの名前を整理できます。nLockTime は取引全体のフィールドで、絶対的な境界を示します。入力の nSequence は BIP68 に従って相対遅延を表します。ただし、nLockTime だけでは UTXO、つまりまだ使われていない出力を、設定の違う別の取引から保護できません。使用権限を持つ人は、出力のルールに禁じられていなければ、その別の取引を作れます。Bitcoin Script は、こうした使用ルールを記述するための言語です。OP_CHECKLOCKTIMEVERIFY、略して BIP65 の CLTV は、使用する分岐で対応する絶対設定を要求します。OP_CHECKSEQUENCEVERIFY、つまり BIP112 の CSV は相対設定をチェックし、実際の遅延は BIP68 が強制します。CLTV も CSV も、送金したり不足する署名を補ったりはしません。別の許可された分岐は違う条件で使える場合があります。 [1] [2] [3]

ここからは技術的な参考資料です。フィールドは取引に保存する項目、入力は使用する出力への参照です。各入力に nSequence があります。特定の値で nLockTime の効果を無効にできるため、日付を入れるだけでは十分ではありません。 nLockTime は符号なし 32 ビットのフィールドで、ゼロは絶対時間条件を無効にします。すべての入力が値 0xffffffff の SEQUENCE_FINAL なら、満たされていない nLockTime は無視されます。有効な絶対ロックには、少なくとも一つの入力で異なる nSequence が必要です。評価対象はそのトランザクションであり、入力を永久に凍結するものではありません。 [5] [7]

同じフィールドが二つの意味を持つので、数値の境界で区別します。Unix timestamp は UTC の 1970 年初めからの秒数で時刻を表します。候補ブロックは、確認中の取引を取り込もうとするブロックです。 LOCKTIME_THRESHOLD は 500000000 です。これ未満の nLockTime はブロック高、等しいかそれ以上なら Unix timestamp を表します。絶対チェックが有効な場合、nLockTime は候補ブロック高または該当する MTP より厳密に小さくなければなりません。等しいだけでは不十分です。金額、平均の高さ、プロトコルの有効化日を表すものではありません。 [5] [8]

オペランドは命令に渡す値、opcode は Script の命令そのものです。CLTV は分岐に記録された要求と取引の設定を比較します。チェーンが十分進んだかは別の検証が判断します。今日の日付と一つの数字を比べるだけではありません。 OP_CHECKLOCKTIMEVERIFY は、非負のオペランド、nLockTime と一致する高さ／時刻の種類、nLockTime 以下のオペランドを要求します。対応する支出入力の nSequence は 0xffffffff であってはなりません。opcode は時計やチェーン高を直接読みません。トランザクションの設定は時間的な有効性の確認で別途検証されます。その他の Script 条件も必要です。 [1] [6]

nSequence の数値には待ち時間だけでなく、意味を切り替えるスイッチも入っています。ビットはその表現のゼロまたは一で、設定すると機能が有効になる場合があります。以下のビット位置は形式上の決まりで、確認回数ではありません。 バージョン 2 以上のトランザクションでは、BIP68 がビット 31 の立っていない入力に相対条件を適用します。下位 16 ビットが遅延量を表し、ビット 22 が立っていれば 512 秒単位、そうでなければブロック単位です。ブロック遅延は使用する出力の確認高から数えます。時間遅延は、その確認ブロックの一つ前の MTP から候補ブロックの一つ前の MTP までを測ります。ウォレットでの作成時点からではありません。 [2] [5]

CSV は相対的な待ち時間について、同じように設定を検証します。マスクは nSequence の必要なビットを選び、disable flag は無効化スイッチです。Lightning Network は決済チャネルのネットワークです。参加者は、共同でロックした資金の配分を合意のうえで更新します。失効済みの古い状態が公開された場合、この待ち時間が相手に対応の機会を与えます。commitment transaction は資金配分を記録した取引で、失効鍵を使うと相手側は失効済みの版の該当出力をペナルティ分岐から使えます。 有効な非負オペランドを持つ OP_CHECKSEQUENCEVERIFY は、バージョン 2 以上、入力の disable flag が未設定、遅延の種類の一致、マスクを適用した後の nSequence の値が十分に大きいこと を要求します。実際の経過期間は BIP68 が別途要求します。CSV は遅延付き復旧分岐を可能にします。Lightning の to_local 出力では to_self_delay が commitment transaction の所有者を制限し、正しい失効鍵を持つ相手はその遅延なしにペナルティ分岐を使えます。 [3] [9]

ほぼ同じ二つの数値でも、効果は異なることがあります。以下の 0x で始まる値は十六進表記です。NOP は、ここでは時間制約を追加しない命令を意味します。スイッチが取引の入力にあるのか、CSV に渡す値にあるのかも重要です。 ビット 31 は SEQUENCE_LOCKTIME_DISABLE_FLAG で、その入力の BIP68 相対解釈だけを無効にします。0xfffffffe はこのビットを含みますが SEQUENCE_FINAL ではなく、有効な nLockTime と CLTV を許します。0xffffffff が final です。disable flag を持つ非負 CSV オペランドは NOP として動作しますが、入力側でそのフラグが立っていれば有効な CSV 要求を満たせません。この二つを混同してはいけません。 [3] [7]

RPC はビットコインのブロックや取引を検証するプログラムである自分のノードを操作する命令です。デコードは保存されたデータを読みやすく表示するだけで、テスト命令がその後、特定の署名済み取引が通るかを確かめます。Mempool は、そのノードの確認待ち取引の一覧です。 Core 31 の decoderawtransaction RPC は version、locktime、各入力の sequence を表示します。CLTV/CSV では実際に使う Script と使用する出力を確認します。デコードだけでは有効性の証明になりません。testmempoolaccept RPC は署名済み候補を現在のチェーン、ビットコインの有効性ルール、ノード独自の取引受け入れルールに照らしてテストし、mempool への受け入れもブロードキャストも行いません。allowed と拒否理由を確認してください。成功しても将来の確認は約束されません。 [10] [11] [12]