OP_CHECKLOCKTIMEVERIFY는 transaction nLockTime이 script의 절대 block height 또는 time 기준 이상인지 검사하고 해당 input nSequence가 final이 아니어야 효력이 있습니다. OP_CHECKSEQUENCEVERIFY는 input nSequence에 인코딩된 상대 지연이 참조 UTXO의 확인 이후 충분히 지났는지 검사합니다. CLTV의 time 기준은 500,000,000 경계와 Median Time Past를, CSV는 BIP68 version 2 상대 lock semantics와 512초 단위를 사용하므로 wall-clock 만료 시각으로 단순 치환하면 안 됩니다.
CLTV는 거래의 절대 잠금을 script가 요구합니다
BIP65 OP_CHECKLOCKTIMEVERIFY는 stack 최상단 값과 transaction nLockTime의 type이 모두 height이거나 모두 timestamp인지 확인하고 nLockTime이 요구 값 이상인지 검사합니다. 기준 500,000,000 미만은 block height, 이상은 Unix time 계열 값으로 분류됩니다. Operand가 음수이거나 더 크면 script가 실패합니다.
검사 후 값은 stack에서 제거되지 않으므로 보통 OP_DROP을 이어 씁니다. 현재 input nSequence가 0xffffffff final이면 nLockTime이 무시될 수 있어 CLTV도 실패 조건으로 둡니다. Script 숫자 encoding과 최대 5바이트 operand 조건도 구현에 포함해야 합니다.
CLTV는 특정 달력 시간을 예약하는 기능이 아니라, chain이 인정한 절대 높이·시간보다 이른 지출을 막는 script 조건입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- CLTV는 거래의 절대 잠금을 script가 요구합니다
BIP65 OP_CHECKLOCKTIMEVERIFY는 stack 최상단 값과 transaction nLockTime의 type 이 모두 height이거나 모두 timestamp인지 확인하고 nLockTime이 요구 값 이상인지 검사합니다.
- CSV는 UTXO가 얼마나 오래됐는지 검사합니다
BIP112 OP_CHECKSEQUENCEVERIFY는 operand의 disable flag가 없을 때 transaction version이 2 이상인지, input nSequence가 상대 lock을 활성화하는지, type과 masked value가 요구 조건을 충족하는지 봅니다.
- Transaction field와 script 조건을 함께 맞춥니다
Script에 CLTV opcode만 넣고 transaction nLockTime을 0으로 두면 지출은 성공하지 않습니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
CSV는 UTXO가 얼마나 오래됐는지 검사합니다
BIP112 OP_CHECKSEQUENCEVERIFY는 operand의 disable flag가 없을 때 transaction version이 2 이상인지, input nSequence가 상대 lock을 활성화하는지, type과 masked value가 요구 조건을 충족하는지 봅니다. 실제 상대 lock 계산 semantics는 BIP68이 정의합니다.
Height type은 block 단위이고 time type flag가 켜지면 512초 단위입니다. Time은 참조 output이 포함된 block 이전의 Median Time Past와 spending block 이전 MTP를 사용합니다. ‘CSV 144=정확히 24시간’처럼 평균 10분을 확정 시각으로 안내하면 block 변동을 숨깁니다.
| 항목 | CLTV | CSV |
|---|---|---|
| 기준 | 절대 height·time | UTXO 이후 상대 지연 |
| 거래 필드 | nLockTime | input nSequence |
| 주요 BIP | 65 + locktime 규칙 | 112 + BIP68 |
| 시간 판정 | Median Time Past 관련 | 512초 단위 MTP |
| 대표 사용 | 만료 후 환불 | 채널·복구 지연 |
Transaction field와 script 조건을 함께 맞춥니다
Script에 CLTV opcode만 넣고 transaction nLockTime을 0으로 두면 지출은 성공하지 않습니다. 반대로 nLockTime만 미래로 설정해도 UTXO script가 특정 절대 시점을 약속한 것은 아닙니다. Wallet builder와 signer가 script operand, nLockTime, nSequence를 함께 검토해야 합니다.
CSV도 script operand보다 input nSequence masked value가 작으면 실패합니다. Disable flag나 time/height type이 다르면 예상과 달라집니다. 여러 inputs를 가진 transaction은 각 input의 sequence와 전체 finality 규칙을 확인하고 fee bump가 timelock 의미를 바꾸지 않는지 봅니다.
- Script operand의 숫자와 단위를 decode합니다.
- CLTV면 nLockTime type·값과 final sequence를 확인합니다.
- CSV면 version 2와 nSequence flags를 확인합니다.
- 현재 height·MTP와 필요한 여유를 계산합니다.
- regtest에서 경계 전·후 block을 모두 시험합니다.
Lightning은 두 잠금을 역할별로 조합합니다
HTLC는 payment preimage로 이른 시점에 청구하거나 CLTV expiry 뒤 timeout path를 쓰는 구조를 가집니다. Commitment transaction의 to_local output은 CSV relative delay를 두어 상대방이 revoked state를 발견하고 penalty를 실행할 시간을 줍니다. 같은 ‘시간 잠금’이지만 보호 대상이 다릅니다.
Route의 각 hop은 incoming expiry가 outgoing보다 충분히 늦도록 cltv_expiry_delta를 둡니다. 이는 중간 node가 downstream preimage를 얻은 뒤 upstream을 청구할 안전 시간을 만듭니다. App UI의 하나의 만료 시각만으로 channel policy와 on-chain delay를 설명하지 않습니다.
경계값은 다음 block 포함 가능성으로 검증합니다
Timelock 조건이 만족됐다는 것은 transaction이 바로 confirm된다는 뜻이 아닙니다. Mempool finality policy, fee rate, miner 선택과 block 간격이 추가됩니다. Refund transaction을 만료 순간에 만들어도 낮은 fee나 ancestor policy 때문에 늦게 포함될 수 있습니다.
운영은 absolute deadline 전에 필요한 confirmation depth와 fee bump 경로를 역산합니다. Hardware signer는 nLockTime·sequence를 숨기지 않고 unusual 값에 경고해야 합니다. Test vector에는 499,999,999/500,000,000 type 경계, sequence disable flag, 정확히 한 block 부족한 경우를 포함합니다.
자주 묻는 질문
CLTV 시간이 되면 transaction이 바로 confirm된다는 뜻이 아닙니다하나요?
아닙니다. 그 이후 조건을 만족하는 거래를 서명·전파하고 block에 포함해야 합니다.
CSV 144는 정확히 하루인가요?
Height type이면 144 blocks이며 실제 wall-clock 시간은 block 간격에 따라 달라집니다.
nLockTime만 설정하면 script 없이도 절대 잠금인가요?
거래 자체의 earliest inclusion을 제한하지만 UTXO에 미래 지출 정책을 영구 약속하려면 script 조건을 함께 설계해야 합니다.
