Table of Contents

비트코인 절대·상대 타임락과 거래 대기 조건 구분하기

비트코인 타임락은 코인을 예약 송금하는 단순 달력 기능이 아닙니다. 거래 전체가 특정 블록 높이·시각 전에는 확정될 수 없게 만들거나, 특정 UTXO가 확인된 뒤 일정 블록·시간이 지나야 스크립트의 한 지출 경로를 사용할 수 있게 하는 합의 조건입니다. 조건이 충족돼도 자동으로 송금되지는 않으며 유효한 거래를 만들어 서명하고 전파해야 합니다.

이 글은 2026년 8월 6일 확인한 Bitcoin 개발자 거래 문서와 Bitcoin Core 구현 문서, 배포된 BIP 65·68·112를 기준으로 합니다. 타임락 스크립트를 직접 설계하도록 권하는 글이 아니며, 구현 오류·키 분실·백업 실패·수수료 부족과 가격 변동으로 원금 전부를 잃을 수 있습니다.

비트코인 절대·상대 타임락과 거래 대기 조건 구분하기 — 핵심 개념을 이해하기 위한 로드투코인 설명 이미지

타임락을 이해하는 네 가지 축

타임락은 먼저 절대 기준과 상대 기준으로 나눕니다. 절대 타임락은 블록체인이 특정 높이 또는 시각에 도달했는지 봅니다. 상대 타임락은 지출하려는 이전 출력이 확인된 뒤 얼마나 오래됐는지를 봅니다. 다음으로 거래 수준과 스크립트 수준을 나눠야 합니다. nLockTime과 BIP 68의 시퀀스 잠금은 거래의 최종성·블록 포함 가능성을 제한하고, CHECKLOCKTIMEVERIFY(CLTV)와 CHECKSEQUENCEVERIFY(CSV)는 특정 스크립트 경로를 쓸 수 있는 조건을 검사합니다.

구분	대표 장치	기준점	적용 범위	대표 용도
절대·거래 수준	`nLockTime`	정해진 높이 또는 시각	거래 전체	미리 서명한 거래의 유효 시점 제한
절대·스크립트 수준	CLTV, BIP 65	정해진 높이 또는 시각	해당 스크립트 경로	특정 시점 이후 환불 경로
상대·거래 수준	시퀀스 잠금, BIP 68	소비할 UTXO의 확인 시점	입력별 조건을 거래에 적용	확인 뒤 최소 지연
상대·스크립트 수준	CSV, BIP 112	소비할 UTXO의 나이	해당 스크립트 경로	에스크로·채널의 지연 경로

“거래에 locktime 숫자가 있다”와 “출력 스크립트에 시간 조건이 있다”는 같은 말이 아닙니다. 어느 필드와 opcode가 조건을 강제하는지 확인해야 합니다.

nLockTime 절대 잠금의 계산 구조

Bitcoin 거래의 lock_time은 4바이트 부호 없는 정수입니다. Bitcoin 개발자 문서에 따르면 값이 500,000,000 미만이면 블록 높이, 그 이상이면 유닉스 시각으로 해석합니다. 예를 들어 850000은 높이 기준이지만 1767225600은 UTC 시각 기준입니다. 단위 표시 없이 숫자만 복사하면 완전히 다른 의미가 될 수 있습니다.

nLockTime < 500,000,000 → 높이 기반

nLockTime ≥ 500,000,000 → 시간 기반

하지만 nLockTime 값만 넣는다고 항상 잠금이 활성화되는 것은 아닙니다. 개발자 문서는 모든 입력의 시퀀스가 최댓값 0xffffffff이면 타임락을 비활성화할 수 있다고 설명합니다. 따라서 절대 잠금을 사용하려면 적어도 한 입력의 시퀀스가 최댓값보다 작아야 합니다. 지갑 구현이 이를 어떻게 설정하는지 원시 거래와 공식 디코더로 검증해야 합니다.

CLTV는 출력의 특정 지출 경로를 제한한다

BIP 65의 CHECKLOCKTIMEVERIFY는 스택의 잠금값과 거래의 nLockTime을 비교합니다. 조건이 맞지 않으면 스크립트 실행이 실패합니다. CLTV는 코인을 스스로 이동시키는 알람도 아니고 UTXO 자체의 전 지출을 무조건 막는 독립 필드도 아닙니다. 스크립트에 여러 분기가 있다면 한 분기만 절대 시점 뒤에 허용하고 다른 서명 조합은 더 일찍 허용하도록 설계할 수 있습니다.

CLTV 인수와 거래 nLockTime의 유형은 일치해야 합니다. 하나가 높이이고 다른 하나가 유닉스 시각이면 유효한 비교가 되지 않습니다. 거래의 입력 시퀀스가 최댓값인 경우에도 CLTV 검증이 실패하도록 정의되어 있어, 서명자가 nLockTime을 무력화하는 거래를 만들지 못하게 합니다.

확인 항목	올바른 질문	오류가 생기는 사례
잠금 유형	높이와 시각 중 무엇인가	500,000,000 경계를 무시
스크립트 분기	어느 키·조건이 지연되는가	전체 UTXO가 잠겼다고 오해
거래 nLockTime	CLTV 인수 이상인가	스크립트만 맞고 거래 필드가 낮음
입력 시퀀스	최댓값으로 비활성화되지 않았는가	서명 거래가 예상과 다름
서명 범위	서명이 어떤 거래 필드에 커밋하는가	수정 뒤 기존 서명을 재사용

BIP 68 상대 잠금과 시퀀스 필드

BIP 68은 버전 2 이상 거래에서 입력의 nSequence 일부를 상대 잠금으로 해석합니다. 기준점은 달력의 고정 날짜가 아니라 그 입력이 소비하는 UTXO가 블록에 확인된 시점입니다. 높이 기반이면 블록 수, 시간 기반이면 512초 단위로 최소 나이를 표현합니다.

시퀀스의 31번 비트가 설정되면 BIP 68 상대 잠금 해석이 비활성화됩니다. 22번 비트는 높이와 시간 유형을 구분하며, 하위 16비트가 상대 값을 담습니다. 시간 기반 값의 한 단위는 512초이므로 사람이 원하는 초 단위를 그대로 넣는 것이 아닙니다. 이는 저수준 구현 규칙이며 검증되지 않은 수동 비트 조작은 자금 잠금을 일으킬 수 있습니다.

높이 기반 144는 “정확히 24시간”이 아니라 최소 144블록의 상대 나이를 뜻합니다. 평균 블록 간격을 10분으로 잡으면 약 하루지만 실제 경과시간은 달라질 수 있습니다. 시간 기반 조건도 블록 헤더의 단순 벽시계 하나가 아니라 합의가 사용하는 블록 시간 규칙과 중간값을 고려하므로 휴대전화 시계와 정확히 일치하지 않습니다.

CSV는 UTXO가 생긴 뒤 시작되는 지연을 검사한다

BIP 112의 CHECKSEQUENCEVERIFY는 BIP 68과 결합해 스크립트 경로를 이전 출력의 나이로 제한합니다. BIP 112의 공식 설명처럼 에스크로 출력이 확인된 뒤 30일이 지나면 한 당사자가 단독으로 회수하는 경로를 만들 수 있습니다. 중요한 차이는 자금이 실제로 확인될 때까지 상대 시계가 시작하지 않는다는 점입니다.

절대 CLTV로 고정 날짜를 쓰면 자금 조달이 늦어질수록 실제 대응 시간이 짧아질 수 있습니다. CSV는 확인 시점부터 같은 지연을 제공하므로 결제 채널의 취소 가능 경로처럼 “사건 발생 뒤 대응 기간”이 필요한 구조에 적합합니다. 다만 CSV가 자동 감시나 자동 처벌을 제공하는 것은 아닙니다. 필요한 거래를 제때 발견하고 전파할 운영 체계가 별도로 필요합니다.

숫자를 넣은 높이 기반 계산 예시

가상 UTXO가 블록 높이 900,000에서 확인됐고 CSV 경로가 144블록의 상대 지연을 요구한다고 가정합니다. 단순 계산상 후보 지출 높이는 900,000 + 144 = 900,144 부근입니다. 실제 포함 가능성은 BIP 68의 경계 의미와 노드 정책, 블록 도착을 정확히 적용한 지갑·노드로 확인해야 하며, “1일 뒤 오전 같은 시각”으로 예약된 것이 아닙니다.

항목	가정값	판단
자금 출력 확인 높이	900,000	상대 기준점
요구 상대 지연	144블록	시간 144분이 아님
단순 후보 경계	900,144	최종 거래 제작 전 노드 검증 필요
실제 벽시계 경과	미정	블록 간격 변동에 따라 달라짐
조건 충족 뒤 자동 송금	없음	서명·전파·수수료 필요

반면 CLTV가 높이 910,000을 요구하면 자금 출력이 900,000에 확인되든 909,900에 확인되든 절대 기준은 910,000입니다. 이 비교가 절대 마감과 사건 후 대기기간을 구분하는 핵심입니다.

시간 기반 상대 잠금 계산 예시

상대 시간 단위는 512초입니다. 최소 24시간을 표현하려는 단순 계산은 86,400 ÷ 512 = 168.75이므로 조건을 짧게 만들지 않으려면 169단위가 필요합니다. 169단위는 169 × 512 = 86,528초, 즉 24시간 2분 8초에 해당합니다. 그러나 이 숫자도 벽시계로 정확한 실행 시각을 보장하지 않습니다.

목표 지연	512초 단위 계산	올림한 단위	명목상 최소값
1시간	3,600÷512=7.03125	8	4,096초
24시간	86,400÷512=168.75	169	86,528초
7일	604,800÷512=1,181.25	1,182	605,184초

내림하면 목표보다 짧은 지연을 만들 수 있습니다. 지갑 라이브러리가 시간값을 어떤 단위와 반올림으로 변환하는지, 최종 시퀀스의 유형 비트가 맞는지 테스트넷·regtest와 독립 검토로 확인해야 합니다.

단계별 확인법: 원시 거래에서 노드 검증까지

첫째, 요구사항을 “고정 높이·시각 뒤”인지 “출력 확인 뒤 일정 기간”인지 문장으로 씁니다. 둘째, 거래 수준 잠금인지 스크립트 분기 수준 잠금인지 정합니다. 셋째, 높이와 시간 단위를 선택하고 경계값을 기록합니다. 넷째, 원시 거래를 decoderawtransaction으로 디코딩해 버전, locktime, 각 입력의 sequence를 확인합니다.

다섯째, 출력 정책은 사람이 읽을 수 있는 디스크립터 또는 Miniscript 표현과 실제 scriptPubKey를 함께 보관합니다. 여섯째, 서명 전후 거래 ID와 필드가 바뀌지 않았는지 봅니다. 일곱째, testmempoolaccept 같은 노드 RPC로 현재 거부 사유를 확인하되, 멤풀 승인은 미래 블록 포함 보장이 아님을 명시합니다. 여덟째, 실제 자금을 보내기 전 소액과 격리된 테스트 환경에서 정상 경로·환불 경로·백업 복구를 모두 연습합니다.

지표 조합별 해석과 운영 시나리오

관측 조합	가능한 원인	다음 확인
높이 도달, 거래 거부	시퀀스·CLTV·수수료·입력 문제	노드 거부 사유와 스크립트 분기
상대 기간 미도달	부모 출력 확인이 늦음	실제 확인 높이·시간 기준
조건 충족, 미확정	전파 안 됨·낮은 수수료	멤풀 수용과 수수료율
지갑 표시와 노드 불일치	정책 추정·갱신 차이	원시 거래와 자체 노드
한 경로만 실패	키·해시·타임락 조합 오류	해당 분기의 만족 자료

타임락 조건 충족은 필요조건일 뿐 충분조건이 아닙니다. 입력이 이미 다른 거래에 소비됐거나 서명이 틀렸거나 수수료가 정책 하한보다 낮으면 확정되지 않습니다. 여러 조건이 있는 스크립트에서는 키, 해시 프리이미지, 절대·상대 잠금이 모두 맞아야 할 수 있습니다.

시장과 사용자 경험이 다르게 보이는 이유

타임락은 거래의 합의 유효성을 제어하지만 BTC 시장가격을 안정시키지 않습니다. 자금이 잠긴 동안 가격이 급락해도 프로토콜은 조기 매도를 허용하지 않습니다. 반대로 잠금 해제 물량이 있다고 모두 즉시 매도되는 것도 아닙니다. 소유자의 의사, 키 가용성, 수수료와 시장 유동성이 별도 변수입니다.

지갑 화면은 “약 1일”, “잠금 해제 예정”처럼 친숙한 표현을 사용할 수 있지만 블록 기반 지연은 확률적으로 진행됩니다. 노드의 멤풀 정책도 합의 규칙보다 엄격할 수 있어, 미래에는 유효해질 거래라도 너무 이르게 전파하면 보관되지 않을 수 있습니다. 사용자는 UI 예상시각보다 원시 조건과 재전파 계획을 우선해야 합니다.

흔한 오해와 위험한 설계

첫째, 잠금 만료 시 자동 송금된다는 오해입니다. 누군가 거래를 만들어 전파해야 합니다. 둘째, 높이 144를 144분으로 읽는 오류입니다. 셋째, nLockTime만 설정하고 모든 시퀀스를 0xffffffff로 두는 오류입니다. 넷째, CLTV와 CSV가 개인키 분실을 해결한다고 믿는 오해입니다. 잠금 뒤 사용할 키와 정책 백업이 없으면 자금은 여전히 움직일 수 없습니다.

다섯째, 환불 거래 하나만 저장하고 장기간 방치하는 설계입니다. 수수료 환경, 서명 플래그, 부모 거래의 변경과 체인 재구성을 고려해야 합니다. 여섯째, 절대 시간과 상대 시간을 한 분기에서 잘못 섞는 오류입니다. BIP 379의 Miniscript 문서는 높이 기반과 시간 기반 잠금을 호환되지 않게 혼합하지 않도록 타입 검사를 설명합니다. 검증된 라이브러리와 동료 검토가 필요한 이유입니다.

데이터 한계와 원금 손실 위험

블록 탐색기의 예상 만료 시각은 평균 블록 간격에 기반한 추정일 수 있습니다. 블록은 정확히 10분마다 생성되지 않고 짧은 체인 재구성으로 확인 높이의 관찰이 달라질 수 있습니다. 시간 기반 합의는 로컬 시계와 동일하지 않으며, 지갑·노드 버전과 멤풀 정책 차이가 전파 결과에 영향을 줍니다.

복잡한 스크립트는 감사되지 않은 구현, 잘못된 분기, 키 순서, 디스크립터 누락으로 영구 손실을 만들 수 있습니다. 감시가 필요한 계약은 노드 중단이나 알림 실패로 대응 기회를 놓칠 수 있습니다. 타임락 기간에는 시장 급락에도 처분하지 못하는 유동성 위험이 있습니다. 큰 금액은 검증된 지갑과 독립된 기술 검토 없이 직접 구성하지 말아야 하며, 어떤 구조도 원금과 수익을 보장하지 않습니다.