Timelock には nLockTime、OP_CHECKLOCKTIMEVERIFY（CLTV/BIP65）、BIP68 による相対的な nSequence、OP_CHECKSEQUENCEVERIFY（CSV/BIP112）が含まれます。トランザクションのフィールドが時間に関する有効性条件を定め、Script はその設定を要求できます。時間基準の方式はウォレットの時計ではなく Median Time Past（MTP）を使います。ロックを満たしても受け入れや承認は保証されません。
nLockTime と CLTV が絶対方式の組、BIP68 と CSV が相対方式の組です。nLockTime は特定のトランザクション全体を制限しますが、それだけで別の設定を持つ別トランザクションによる UTXO の支出を防ぐわけではありません。実行されるスクリプト分岐の CLTV または CSV が、支出トランザクションの対応するフィールドを要求します。別の許可された分岐には異なる条件があり得ます。 [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 68 — Relative lock-time] [BIP 112 — CHECKSEQUENCEVERIFY]
nLockTime は符号なし 32 ビットのフィールドで、ゼロは絶対時間条件を無効にします。すべての入力が値 0xffffffff の SEQUENCE_FINAL なら、満たされていない nLockTime は無視されます。有効な絶対ロックには、少なくとも一つの入力で異なる nSequence が必要です。評価対象はそのトランザクションであり、入力を永久に凍結するものではありません。 [Bitcoin Core v31.0 — Transaction finality] [Bitcoin Core v31.0 — Sequence constants]
LOCKTIME_THRESHOLD は 500000000 です。これ未満の nLockTime はブロック高、等しいかそれ以上なら Unix timestamp を表します。絶対チェックが有効な場合、nLockTime は候補ブロック高または該当する MTP より厳密に小さくなければなりません。等しいだけでは不十分です。金額、平均の高さ、プロトコルの有効化日を表すものではありません。 [Bitcoin Core v31.0 — Transaction finality] [Bitcoin Core v31.0 — Locktime threshold]
BIP113 は時間に関する最終性に前ブロックの MTP を使います。これはそのブロックを末尾とする直近 11 ブロックのタイムスタンプの中央値です。算術平均、利用者の現在時刻、候補ブロックのタイムスタンプではありません。Bitcoin Core は GetMedianTimePast を使い、カレンダー上の期日に達しただけではロック成立を保証しません。 [BIP 113 — Median time-past]
OP_CHECKLOCKTIMEVERIFY は、非負のオペランド、nLockTime と一致する高さ／時刻の種類、nLockTime 以下のオペランドを要求します。対応する支出入力の nSequence は 0xffffffff であってはなりません。opcode は時計やチェーン高を直接読みません。トランザクションの設定は時間的な有効性の確認で別途検証されます。その他の Script 条件も必要です。 [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v31.0 — Script interpreter]
バージョン 2 以上のトランザクションでは、BIP68 がビット 31 の立っていない入力に相対条件を適用します。下位 16 ビットが遅延量を表し、ビット 22 が立っていれば 512 秒単位、そうでなければブロック単位です。ブロック遅延は使用する出力の承認高から数えます。時間遅延は、その承認ブロックの一つ前の MTP から候補ブロックの一つ前の MTP までを測ります。ウォレットでの作成時点からではありません。 [BIP 68 — Relative lock-time] [Bitcoin Core v31.0 — Transaction finality]
有効な非負オペランドを持つ OP_CHECKSEQUENCEVERIFY は、バージョン 2 以上、入力の disable flag が未設定、遅延の種類の一致、マスク後の十分な nSequence を要求します。実際の経過期間は BIP68 が別途要求します。CSV は遅延付き復旧分岐を可能にします。Lightning の to_local 出力では to_self_delay が commitment transaction の所有者を制限し、正しい失効鍵を持つ相手はその遅延なしにペナルティ分岐を使えます。 [BIP 112 — CHECKSEQUENCEVERIFY] [BOLT 3 — Commitment transaction outputs]
ビット 31 は SEQUENCE_LOCKTIME_DISABLE_FLAG で、その入力の BIP68 相対解釈だけを無効にします。0xfffffffe はこのビットを含みますが SEQUENCE_FINAL ではなく、有効な nLockTime と CLTV を許します。0xffffffff が final です。disable flag を持つ非負 CSV オペランドは NOP として動作しますが、入力側でそのフラグが立っていれば有効な CSV 要求を満たせません。この二つを混同してはいけません。 [BIP 112 — CHECKSEQUENCEVERIFY] [Bitcoin Core v31.0 — Sequence constants]
時間ロックは適格性条件であり、送信スケジューラーではありません。ウォレットはトランザクションの保持または作成、署名と他のデータの提供、全条件の充足、手数料と伝播の手配を行う必要があります。ローカル方針とマイナーの選択も承認に影響します。再編は入力の承認高と相対的な経過期間を変え得るため、時間の経過は不可逆な結果を保証しません。 [BIP 68 — Relative lock-time] [Bitcoin Core v31.0 — Transaction finality]
Core 31 の decoderawtransaction RPC は version、locktime、各入力の sequence を表示します。CLTV/CSV では実際に使う Script と使用する出力を確認します。デコードだけでは有効性の証明になりません。testmempoolaccept RPC は署名済み候補を現在のチェーンとローカルのコンセンサス／ポリシー検証に照らしてテストし、mempool への受け入れもブロードキャストも行いません。allowed と拒否理由を確認してください。成功しても将来の承認は約束されません。 [Bitcoin Core 31.0 — decoderawtransaction RPC] [Bitcoin Core 31.0 — testmempoolaccept RPC] [Bitcoin Core v31.0 — Mempool RPC implementation]
理解を深めるには、この項目とあわせて次もお読みください CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, Lightning Network, Payment Channel, トランザクション, Bitcoin Script. 次の項目からも参照されています 承認, Bitcoin Script, HTLC, CHECKLOCKTIMEVERIFY.