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비트 필드이며 0은 절대 시간 조건을 끕니다. 모든 입력이 값 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.