nLockTime은 거래 전체가 특정 블록 높이 또는 시간 전에는 채굴되지 않게 하는 절대 잠금 필드입니다. nSequence는 입력마다 있으며 거래 버전 2 이상에서 BIP 68 규칙을 쓰면 해당 UTXO가 확인된 뒤 일정 블록 또는 시간이 지나야 하는 상대 잠금이 됩니다. 같은 sequence 필드가 RBF 신호에도 쓰이므로 숫자 하나만 보고 목적을 단정하지 말고 버전·비트·스크립트를 함께 해석해야 합니다.
nLockTime은 거래 전체가 유효해지는 절대 경계를 둡니다
BIP 65는 거래의 nLockTime이 일정 블록 높이 또는 블록 시간에 도달하기 전 채굴을 막는다고 설명합니다. 값의 범위에 따라 높이와 시간 유형을 구분하므로 숫자를 일반 Unix 시간처럼만 읽으면 안 됩니다. 경계를 충족하기 전 거래는 단순히 우선순위가 낮은 것이 아니라 해당 조건에서 블록에 포함될 수 없습니다.
그러나 nLockTime 숫자만 넣으면 항상 활성화되는 것은 아닙니다. 모든 입력의 nSequence가 최종값이면 잠금이 비활성화되는 조건이 있습니다. Bitcoin Core 30.0 `send` 문서도 0이 아닌 locktime을 설정하면 입력을 locktime 활성 상태로 만든다고 별도로 적습니다.
시간 잠금은 지갑 화면의 예약 발송이 아니라 어떤 블록부터 거래를 포함할 수 있는지 정하는 유효성 조건입니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- nLockTime은 거래 전체가 유효해지는 절대 경계를 둡니다
BIP 65는 거래의 nLockTime이 일정 블록 높이 또는 블록 시간에 도달하기 전 채굴을 막는다고 설명합니다.
- nSequence는 입력별 상대 잠금으로 재해석될 수 있습니다
BIP 68은 거래 버전이 2 이상이고 disable bit가 설정되지 않은 입력의 sequence를 상대 lock-time으로 해석합니다.
- CLTV와 CSV는 출력의 지출 조건까지 잠급니다
nLockTime만 있는 미서명 거래는 다른 조건의 거래로 UTXO를 쓸 가능성을 막지 못합니다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
nSequence는 입력별 상대 잠금으로 재해석될 수 있습니다
BIP 68은 거래 버전이 2 이상이고 disable bit가 설정되지 않은 입력의 sequence를 상대 lock-time으로 해석합니다. 블록 기반 값은 소비하려는 출력이 확인된 뒤 지정한 블록 수를 기다리고, 시간 기반 값은 512초 단위로 이전 출력의 확인 시점에 상대적인 최소 시간을 표현합니다.
가정으로 블록 기반 sequence가 6이면 해당 출력의 확인 뒤 6블록이 지난 조건을 봅니다. 시간 기반 원시 단위가 12라면 `12×512=6,144초`입니다. 평균 블록 간격 10분을 곱해 정확한 시각을 약속하면 안 됩니다. 블록 기반은 실제 블록 수, 시간 기반은 median-time-past 규칙을 사용합니다.
| 필드·규칙 | 기준점 | 확인 항목 |
|---|---|---|
| nLockTime 높이 | 절대 블록 높이 | 입력의 non-final sequence |
| nLockTime 시간 | 절대 블록 시간 경계 | 높이형과 시간형 구분 |
| BIP 68 블록형 | 각 입력 UTXO 확인 높이 | 거래 버전 2 이상과 disable bit |
| BIP 68 시간형 | 이전 출력 블록의 MTP | 512초 단위와 type bit |
| CLTV·CSV | 출력 스크립트 조건 | 거래 필드와 스크립트 값의 호환 |
CLTV와 CSV는 출력의 지출 조건까지 잠급니다
nLockTime만 있는 미서명 거래는 다른 조건의 거래로 UTXO를 쓸 가능성을 막지 못합니다. BIP 65의 CHECKLOCKTIMEVERIFY는 출력 스크립트가 거래 nLockTime과 비교하도록 해 정한 절대 시점 전에는 해당 경로로 지출할 수 없게 합니다. 높이형과 시간형이 서로 다르면 검증에 실패합니다.
BIP 112의 CHECKSEQUENCEVERIFY는 BIP 68의 상대 잠금 의미를 스크립트 지출 조건에 사용합니다. 복구 경로, 결제 채널, HTLC처럼 ‘출력이 확인된 뒤 일정 시간’이 필요한 구조에 적합합니다. 지갑 UI의 locktime과 스크립트 내부 CLTV·CSV를 같은 기능으로 보지 마세요.
- 거래 version과 nLockTime 원시 값을 확인합니다.
- 각 입력의 nSequence를 10진수와 16진수로 기록합니다.
- 높이형·시간형과 disable/type bit를 구분합니다.
- 지출 출력 스크립트에 CLTV 또는 CSV가 있는지 확인합니다.
- 잠금이 끝난 뒤에도 수수료와 멤풀 수용 여부를 별도로 점검합니다.
RBF도 sequence를 보지만 상대 잠금과 질문이 다릅니다
BIP 125의 opt-in RBF는 sequence 값으로 교체 가능성을 신호하는 규칙을 정의했습니다. 따라서 탐색기가 sequence를 근거로 ‘replaceable’이라고 표시할 수 있습니다. 하지만 그 표시는 상대 잠금이 실제로 몇 블록 남았다는 해석과 같지 않습니다.
거래 버전, sequence의 상위 비트와 하위 16비트, 부모의 신호 상속, 사용 노드의 현행 교체 정책을 함께 봐야 합니다. 지갑이 fee bump를 지원한다고 표시해도 모든 교체안이 수용되는 것은 아닙니다. 절대 수수료와 추가 중계 비용, 충돌 집합 조건을 별도로 충족해야 합니다.
탐색기 pending 표시는 잠금 원인을 증명하지 않습니다
pending은 블록에 아직 포함되지 않았다는 화면 상태입니다. locktime 조건 미충족, 낮은 수수료, 부모 거래 누락, 입력 충돌, 노드 간 전파 차이 모두 비슷하게 보일 수 있습니다. 한 탐색기가 거래를 모른다고 체인이 거래를 거부했다고 결론 내릴 수 없습니다.
원시 거래를 디코딩해 locktime과 sequence를 확인하고, 사용 노드의 `testmempoolaccept` 거부 사유를 기록하세요. locktime이 미래라면 경계가 높이인지 시간인지 계산하고, 이미 충족됐다면 멤풀 정책과 수수료를 다음 원인으로 조사합니다.
잠금 종료 시각은 벽시계 약속이 아닙니다
블록 높이 기반 6블록 잠금은 평균적으로 약 한 시간이라는 설명이 가능하지만 정확히 한 시간 뒤라는 예약은 아닙니다. 블록 간격은 변동합니다. 시간 기반 규칙도 사용자 PC 시계가 아니라 median-time-past를 사용하므로 탐색기 예상 시각과 실제 유효 시점이 차이 날 수 있습니다.
환불·상속·채널 종료처럼 손실 비용이 큰 작업은 앱의 남은 시간 카운트다운만 믿지 마세요. 기준 UTXO 확인 높이, 현재 높이, 사용한 잠금 유형과 안전 여유를 기록하고 원래 지갑의 공식 복구 절차를 따르세요.
자주 묻는 질문
nLockTime이 미래면 거래를 네트워크에 미리 보낼 수 있나요?
노드 정책에 따라 비최종 거래를 멤풀에 받지 않을 수 있습니다. 서명 보관과 네트워크 수용은 별도 문제입니다.
sequence가 낮으면 무조건 RBF인가요?
BIP 125 신호와 상대 잠금 비트 해석, 현행 노드 교체 정책을 함께 봐야 하므로 숫자 크기만으로 단정하면 안 됩니다.
6블록 잠금은 정확히 60분인가요?
아닙니다. 블록 생성 간격은 변동하므로 실제 경과 시간은 짧거나 길 수 있습니다.
