CLTV

안나는 평소 결제를 자신과 피터가 함께 승인하는 보관 방식을 구상합니다. 누군가 오랫동안 연락되지 않을 때를 대비해 정해진 경계 이후에만 쓸 수 있는 복구 경로도 두고 싶습니다. CLTV는 이 시간 조건을 스크립트, 즉 이전에 받은 코인을 쓰는 규칙에 넣습니다. nLockTime 필드만으로는 특정 거래 하나만 늦출 수 있습니다. CLTV는 경계를 더 낮춘 새 거래로 해당 경로의 조건을 우회하지 못하게 합니다. 다만 다른 분기에는 다른 규칙이 있을 수 있습니다. [1] [5]

CLTV는 소유자를 알아보거나 돈을 보내지 않습니다. 복구 경로가 안나의 서명을 요구하면 시간 조건이 충족된 뒤에도 서명이 필요합니다. 개인 키는 이러한 서명을 만드는 데 사용하는 비밀 숫자 값입니다. 시간이 지난다고 잃어버린 개인키가 복구되지는 않습니다. 코인이 다른 주소로 자동 이동하지도 않습니다. 누군가 유효한 거래를 준비하고 서명해 전파해야 합니다. 다른 분기가 더 이른 사용을 허용한다면 복구 분기의 시간 잠금만으로 그 대안을 제한하지는 못합니다. [1]

블록은 공동 기록에 추가하는 거래 묶음입니다. CLTV는 미리 정한 지점에 묶인 조건에 적합합니다. 코인을 받은 뒤 일정 수의 블록을 기다리라는 조건은 아닙니다. 후자는 CSV와 상대 잠금 규칙인 BIP 68이 담당합니다. 이때는 특정 출력의 확정 시점이 중요합니다. 출력은 이전에 받은 금액과 그 사용 조건을 묶은 것입니다. 어느 방식도 정확한 달력 날짜를 보장하지 않습니다. 채굴 간격은 달라지고 재구성으로 확정된 기록이 바뀔 수 있습니다. 재구성은 네트워크가 다른 유효한 체인 분기를 채택해 기존 블록 기록의 일부를 바꾸는 일입니다. [1] [7] [8] [9]

CLTV는 두 종류의 값을 구별합니다. 500000000 미만이면 체인에서의 위치인 블록 높이를 뜻합니다. 이 경계 이상이면 시간을 숫자로 표현한 타임스탬프입니다. 스크립트 조건과 코인을 쓰는 거래의 nLockTime은 같은 종류여야 합니다. 숫자의 크기만 비교해서는 안 됩니다. 블록 위치와 시간을 같은 의미의 값처럼 비교할 수는 없기 때문입니다. [1] [3] [5]

Full Node는 규칙을 스스로 검증하는 노드입니다. 스크립트의 음수가 아닌 경계를 거래의 절대 nLockTime과 비교합니다. 경계는 nLockTime보다 클 수 없으며 이 검사에서는 같아도 됩니다. 하지만 거래가 특정 블록에 들어갈 수 있는지를 정하는 규칙도 별도로 통과해야 합니다. CLTV는 컴퓨터 시계를 읽거나 프로그램을 내일 아침까지 멈추지 않습니다. 검사가 실패하면 그 경로로 쓰려는 시도는 유효하지 않습니다. [1] [3] [4]

거래 입력은 이전에 받은 코인 중 무엇을 쓰는지 가리킵니다. 입력에는 nSequence라는 필드가 있습니다. CLTV가 검사하는 입력에서는 최종 시퀀스를 나타내는 특별한 값 0xffffffff를 사용할 수 없습니다. 모든 입력이 이 값을 사용하면 nLockTime을 비활성화할 수 있기 때문입니다. CLTV는 해당 입력을 비최종 상태로 요구해 이를 막습니다. 그렇다고 특정 상대 대기 시간이 자동 설정되는 것은 아닙니다. 그것은 다른 규칙의 역할입니다. [1] [3] [4]

nLockTime을 900000으로 설정하고 비최종 입력을 가진 가상의 거래를 보겠습니다. 이 시간 조건만 따지면 가장 이른 블록은 900001입니다. 블록에 포함되려면 nLockTime이 후보 블록의 높이보다 엄격히 작아야 합니다. 따라서 CLTV 내부 비교가 같은 값을 허용했어도 블록 900000은 충분하지 않습니다. 여기서 최종성은 포함될 자격을 뜻하며 결제의 불가역성을 뜻하지 않습니다. 수수료, 다른 조건, 채굴자의 선택으로 확정이 더 늦어질 수 있습니다. [4]

타임스탬프에는 BIP 113에 따라 이전 블록의 Median Time Past를 사용합니다. 최근 최대 11개 블록의 타임스탬프를 정렬한 중앙값이지, 사용자 시계나 현재 채굴 중인 블록의 시간이 아닙니다. 시간 기반 nLockTime은 이 값보다 엄격히 작아야 합니다. 따라서 현지 정오에 정확히 코인을 쓸 수 있다고 약속할 수 없습니다. 네트워크가 검증할 수 있는 조건일 뿐 정밀한 결제 일정표는 아닙니다. [2] [4]

스크립트는 실행할 때 데이터를 쌓아 두는 작업 공간인 스택을 사용합니다. CLTV는 시간 인수를 검사하지만 제거하지는 않습니다. 따라서 간단한 구조에서는 OP_CHECKLOCKTIMEVERIFY 뒤에 OP_DROP을 두어 인수를 제거하고, 공개키를 넣은 다음 OP_CHECKSIG로 서명을 검증합니다. 공개 키는 서명을 검증하는 데 사용하며 비밀로 유지할 필요가 없습니다. 이는 명령의 역할을 설명하는 예시이지 자금을 잠그는 완성된 지침이 아닙니다. 스크립트 버전, 초기 데이터, 다른 모든 사용 경로도 올바르게 설계해야 합니다. [1] [3]

BIP 65는 기존 OP_NOP2를 대체하는 soft fork, 즉 규칙 강화로 CLTV를 도입했습니다. 미래의 기능 제안에 그치는 것이 아닙니다. 그래도 경계 유형, nLockTime, nSequence, 서명, 대체 분기 등 전체 설계를 확인해야 합니다. 기술 세부 사항은 Bitcoin Core v29.0과 연결된 명세에서 확인할 수 있습니다. 일반 사용자에게 중요한 것은 경계 전후에 누가 돈을 쓸 수 있는지, 복구 방법을 이해하고 있는지입니다. [1] [3] [6] [10]