OP_CHECKLOCKTIMEVERIFY는 거래의 nLockTime이 스크립트가 정한 절대 블록 높이나 시각 이상인지 검사하며, 해당 입력의 nSequence가 최종값이 아니어야 효력이 있습니다. OP_CHECKSEQUENCEVERIFY는 입력 nSequence에 담긴 상대 지연이, 참조하는 UTXO가 확인된 뒤 충분히 지났는지 검사합니다. CLTV의 시각 기준은 500,000,000 경계와 중간값 시각(Median Time Past)을, CSV는 BIP68 버전 2 상대 잠금 규칙과 512초 단위를 쓰므로 벽시계 만료 시각으로 단순히 바꿔 읽으면 안 됩니다.
CLTV는 거래의 절대 잠금을 스크립트가 요구합니다
BIP65 OP_CHECKLOCKTIMEVERIFY는 스택 맨 위 값과 거래 nLockTime의 종류가 둘 다 높이인지, 둘 다 타임스탬프인지 확인한 뒤 nLockTime이 요구값 이상인지 검사합니다. 기준값 500,000,000 미만은 블록 높이로, 그 이상은 유닉스 시각 계열 값으로 분류됩니다. 피연산자가 음수이거나 nLockTime보다 크면 스크립트가 실패합니다.
검사가 끝나도 값이 스택에서 빠지지 않으므로 보통 OP_DROP을 이어 씁니다. 현재 입력의 nSequence가 0xffffffff 최종값이면 nLockTime이 무시될 수 있어, CLTV도 이 경우를 실패 조건으로 둡니다. 스크립트 숫자 인코딩과 피연산자 최대 5바이트 조건도 구현에 넣어야 합니다.
CLTV는 특정 달력 시간을 예약하는 기능이 아니라, 체인이 인정한 절대 높이·시간보다 이른 지출을 막는 스크립트 조건입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- CLTV는 거래의 절대 잠금을 스크립트가 요구합니다
BIP65 OP_CHECKLOCKTIMEVERIFY는 스택 맨 위 값과 거래 nLockTime의 종류가 둘 다 높이인지, 둘 다 타임스탬프인지 확인한 뒤 nLockTime이 요구값 이상인지 검사합니다.
- CSV는 UTXO가 얼마나 오래됐는지 검사합니다
BIP112 OP_CHECKSEQUENCEVERIFY는 피연산자에 비활성 플래그가 없을 때 거래 버전이 2 이상인지, 입력 nSequence가 상대 잠금을 켜 두었는지, 종류와 마스킹한 값이 요구 조건을 채우는지 봅니다.
- 거래 필드와 스크립트 조건을 함께 맞춥니다
스크립트에 CLTV 옵코드만 넣고 거래 nLockTime을 0으로 두면 지출은 성공하지 않습니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
CSV는 UTXO가 얼마나 오래됐는지 검사합니다
BIP112 OP_CHECKSEQUENCEVERIFY는 피연산자에 비활성 플래그가 없을 때 거래 버전이 2 이상인지, 입력 nSequence가 상대 잠금을 켜 두었는지, 종류와 마스킹한 값이 요구 조건을 채우는지 봅니다. 실제 상대 잠금 계산 규칙은 BIP68이 정합니다.
높이 종류는 블록 단위이고, 시각 종류 플래그가 켜지면 512초 단위입니다. 시각은 참조 출력이 담긴 블록 이전의 중간값 시각과, 지출 블록 이전의 중간값 시각을 씁니다. ‘CSV 144=정확히 24시간’처럼 평균 10분 간격을 확정 시각처럼 안내하면 블록 간격의 변동이 가려집니다.
| 항목 | CLTV | CSV |
|---|---|---|
| 기준 | 절대 높이·시각 | UTXO 생성 뒤 상대 지연 |
| 거래 필드 | nLockTime | 입력 nSequence |
| 주요 BIP | 65 + 잠금 시각 규칙 | 112 + BIP68 |
| 시간 판정 | 중간값 시각 관련 | 512초 단위 중간값 시각 |
| 대표 사용 | 만료 후 환불 | 채널·복구 지연 |
거래 필드와 스크립트 조건을 함께 맞춥니다
스크립트에 CLTV 옵코드만 넣고 거래 nLockTime을 0으로 두면 지출은 성공하지 않습니다. 반대로 nLockTime만 미래로 잡아도 UTXO 스크립트가 특정 절대 시점을 약속한 것은 아닙니다. 지갑의 거래 작성기와 서명기가 스크립트 피연산자, nLockTime, nSequence를 함께 검토해야 합니다.
CSV도 입력 nSequence의 마스킹한 값이 스크립트 피연산자보다 작으면 실패합니다. 비활성 플래그나 시각·높이 종류가 다르면 결과가 예상과 달라집니다. 입력이 여러 개인 거래는 입력마다 시퀀스와 전체 최종성 규칙을 확인하고, 수수료 올리기가 시간 잠금의 의미를 바꾸지 않는지 봅니다.
- 스크립트 피연산자의 숫자와 단위를 해석합니다.
- CLTV라면 nLockTime의 종류·값과 최종 시퀀스 여부를 확인합니다.
- CSV라면 버전 2와 nSequence 플래그를 확인합니다.
- 현재 높이·중간값 시각과 필요한 여유를 계산합니다.
- 회귀 테스트망(regtest)에서 경계 직전과 직후 블록을 모두 시험합니다.
라이트닝은 두 잠금을 역할별로 조합합니다
HTLC는 결제 원상(preimage)으로 일찍 청구하거나, CLTV 만료 뒤 시간 초과 경로를 쓰는 구조입니다. 커밋먼트 거래의 to_local 출력은 CSV 상대 지연을 둬서, 상대방이 폐기된 상태를 발견하고 벌칙 거래를 실행할 시간을 줍니다. 같은 ‘시간 잠금’이라도 지키는 대상이 다릅니다.
경로의 각 홉은 들어오는 만료가 나가는 만료보다 충분히 늦도록 cltv_expiry_delta를 둡니다. 덕분에 중간 노드는 아래쪽에서 원상을 얻은 뒤 위쪽에 청구할 안전한 시간을 확보합니다. 앱 화면의 만료 시각 하나만으로 채널 정책과 온체인 지연을 설명하지 않습니다.
경계값은 다음 블록 포함 가능성으로 검증합니다
시간 잠금 조건을 채웠다고 거래가 바로 확정된다는 뜻은 아닙니다. 멤풀의 최종성 정책, 수수료율, 채굴자 선택, 블록 간격이 더해집니다. 환불 거래를 만료 순간에 만들어도 수수료가 낮거나 조상 거래 정책에 걸리면 늦게 포함될 수 있습니다.
운영 쪽은 절대 마감 전에 필요한 확인 깊이와 수수료 올리기 경로를 거꾸로 계산해 둡니다. 하드웨어 서명기는 nLockTime과 시퀀스를 숨기지 말고 평소와 다른 값에 경고해야 합니다. 테스트 벡터에는 499,999,999/500,000,000 종류 경계, 시퀀스 비활성 플래그, 정확히 한 블록 모자란 경우를 넣습니다.
자주 묻는 질문
CLTV 시간이 되면 거래가 바로 확정되나요?
아닙니다. 그 뒤에 조건을 채운 거래를 서명·전파하고 블록에 포함시켜야 합니다.
CSV 144는 정확히 하루인가요?
높이 종류라면 144블록이며, 실제 벽시계 시간은 블록 간격에 따라 달라집니다.
nLockTime만 설정하면 스크립트 없이도 절대 잠금인가요?
거래 자체가 포함될 수 있는 가장 이른 시점은 제한합니다. 하지만 UTXO에 미래 지출 정책을 영구히 약속하려면 스크립트 조건을 함께 설계해야 합니다.
