Timelock

Anna와 Pavel은 공동 자금을 둘이 함께라면 언제든 쓸 수 있지만, Anna 혼자서는 일정 기간 후에만 쓸 수 있도록 설정할 수 있습니다. Pavel이 응답하지 않으면 지연된 분기가 미리 합의한 회수 경로를 제공합니다. 분기는 허용된 사용 방법 하나를 뜻하며, 각 방법의 조건은 다를 수 있습니다. 따라서 잠금이 모든 방법을 동시에 막는 것은 아닙니다. 규칙은 출력이 만들어질 때부터 포함되어야 합니다. 나중에 일반 지갑에 “일주일 후 잠금 해제”라고 적는 것만으로는 부족합니다. 기다린 뒤에도 Anna에게는 해당 키와 유효한 거래를 만드는 데 필요한 정보가 있어야 합니다. Timelock은 접근을 제어하지만 잃어버린 키를 복구하지는 않습니다. [3]

절대 잠금은 고정된 경계를 정하며, 거래의 nLockTime이라는 항목에 기록합니다. 거래의 유효한 nLockTime이 높이 1 000 000이라면 이 조건을 만족하는 첫 블록은 1 000 001입니다. 같은 값으로는 부족합니다. 상대 잠금은 사용할 출력이 확인된 뒤부터 지연을 계산합니다. Anna의 출력이 블록 1 000 000에서 만들어지고 해당 분기에 6블록 지연이 필요하다면, 그 출력을 사용하는 거래는 가장 일찍 블록 1 000 006에서 이 조건을 만족합니다. 이는 예시 숫자이며 현재 네트워크 높이가 아닙니다. 서명, 다른 입력, 추가 잠금의 조건은 여전히 충족해야 합니다. 여섯 블록도 정확히 한 시간은 아닙니다. 블록은 불규칙한 간격으로 나옵니다. 상대 대기는 지갑을 만들 때나 Anna가 돈을 쓰기로 결정할 때 시작되는 것이 아닙니다. [1] [2] [5]

Anna의 대기 기간이 방금 끝났다고 해 봅시다. 네트워크가 대신 행동하지는 않습니다. 누군가는 거래를 만들거나 준비된 것을 사용하고, 서명을 제공하고, 수수료를 내고, 네트워크에 전달해야 합니다. 그 후에야 채굴자가 블록에 넣을 수 있습니다. Timelock 충족은 조건 하나를 만족한 것이지 자리 예약이나 자동 이체가 아닙니다. 보통 사용 가능성이 시작되는 때를 정하며, 그 가능성이 스스로 만료되는 때를 정하지는 않습니다. 체인 재구성은 체인의 일부가 다른 유효한 분기로 교체되는 일입니다. 이로 인해 출력의 확인과 상대 지연 계산을 바꿀 수 있습니다. 직접 설계할 때는 모든 분기, 지갑 지원, 키와 사용 규칙의 백업을 미리 확인해야 합니다. 시간이 잘못 정한 조건을 고쳐 주지는 않습니다. [2] [5]

시간 조건은 Median Time Past, 줄여서 MTP를 사용합니다. 검사하는 블록 기준으로 이전 블록까지의 최근 11개 블록 타임스탬프의 중앙값입니다. 시간을 정렬해 가운데인 여섯 번째를 고르면 됩니다. 이것이 중앙값이며 산술평균이 아닙니다. BIP113이 이 규칙을 설명하고 Bitcoin Core는 GetMedianTimePast로 계산합니다. 기준은 Anna 휴대전화의 현재 시각도, 제안된 블록 자체의 타임스탬프도 아닙니다. 달력상 자정이 잠금 조건을 만족하는 순간과 같을 필요는 없습니다. 높이 기반 잠금은 블록을 기다리며 초를 세지 않습니다. [4]

이제 문서에 등장하는 네 이름을 구별할 수 있습니다. nLockTime은 거래 전체에서 절대 경계를 나타내는 필드입니다. 입력의 nSequence는 BIP68에 따라 상대 지연을 담습니다. 하지만 nLockTime만으로 UTXO, 즉 아직 사용하지 않은 출력을 다른 설정의 별도 거래로부터 잠글 수는 없습니다. 사용 권한이 있는 사람은 출력 규칙이 막지 않으면 그 다른 거래를 만들 수 있습니다. Bitcoin Script는 이러한 사용 규칙을 작성하는 언어입니다. OP_CHECKLOCKTIMEVERIFY, 즉 BIP65의 CLTV는 선택한 분기에 해당 절대 설정을 요구합니다. OP_CHECKSEQUENCEVERIFY, 즉 BIP112의 CSV는 상대 설정을 확인하고 실제 지연은 BIP68이 강제합니다. CLTV나 CSV는 돈을 보내거나 빠진 서명을 채우지 않습니다. 다른 허용된 분기는 다른 조건에서 사용할 수 있습니다. [1] [2] [3]

다음 절은 기술 참고 자료입니다. 필드는 거래에 저장된 항목이며 입력은 사용할 출력을 가리킵니다. 각 입력에는 nSequence가 있습니다. 특별한 값은 nLockTime의 효과를 끌 수 있으므로 날짜를 적는 것만으로는 부족합니다. nLockTime은 부호 없는 32비트 필드이며 0은 절대 시간 조건을 끕니다. 모든 입력이 값 0xffffffff인 SEQUENCE_FINAL을 사용하면 충족되지 않은 nLockTime은 무시됩니다. 유효한 절대 잠금에는 적어도 하나의 입력에 다른 nSequence가 필요합니다. 이는 특정 거래를 평가하는 것이지 입력을 영구 동결하는 것이 아닙니다. [5] [7]

한 필드가 두 가지를 표현할 수 있어 숫자 경계로 구별합니다. Unix timestamp는 UTC 기준 1970년 시작부터의 초로 시간을 나타냅니다. 후보 블록은 검사 중인 거래가 들어가려는 블록입니다. LOCKTIME_THRESHOLD 값은 500000000입니다. 이보다 작은 nLockTime은 블록 높이, 같거나 큰 값은 Unix timestamp를 뜻합니다. 절대 검사가 켜져 있으면 nLockTime은 후보 블록 높이나 해당 MTP보다 엄격히 작아야 합니다. 같은 값으로는 부족하며, 금액이나 평균 높이 또는 프로토콜 활성화 날짜를 뜻하지 않습니다. [5] [8]

피연산자는 명령에 전달하는 값이고 opcode는 Script 명령 자체입니다. CLTV는 분기에 저장된 요구 사항과 거래 설정을 비교합니다. 체인이 충분히 진행되었는지는 별도 검사로 판단합니다. 오늘 날짜와 숫자 하나를 비교하는 것 이상입니다. OP_CHECKLOCKTIMEVERIFY는 음이 아닌 피연산자, nLockTime과 동일한 높이/시간 유형, nLockTime 이하의 피연산자를 요구합니다. 해당 지출 입력의 nSequence는 0xffffffff일 수 없습니다. Opcode는 시계나 체인 높이를 직접 읽지 않으며, 거래 설정은 시간에 따른 유효성을 검사할 때 별도로 평가됩니다. 다른 Script 조건도 여전히 필요합니다. [1] [6]

nSequence라는 숫자에는 대기 기간과 그 의미를 정하는 스위치가 함께 들어 있습니다. 비트는 이 표현의 0 또는 1이며, 설정하면 어떤 기능을 켤 수 있습니다. 아래 비트 위치는 기술 형식의 일부이지 확인 횟수가 아닙니다. 버전 2 이상의 거래에서 BIP68은 비트 31이 설정되지 않은 입력에 상대 조건을 적용합니다. 하위 16비트가 지연을 정하고 비트 22가 설정되면 512초 단위, 아니면 블록 단위입니다. 블록 지연은 지출할 출력의 확인 높이부터 계산합니다. 시간 지연은 그 확인 블록 직전 블록의 MTP에서 후보 블록 직전의 MTP까지 계산합니다. 지갑에서 거래를 만든 뒤 흐른 시간이 아닙니다. [2] [5]

CSV는 상대 대기를 비슷하게 검사합니다. 마스크는 해당 nSequence 비트를 골라내고 disable flag는 끄는 스위치입니다. Lightning Network는 결제 채널로 이루어진 네트워크입니다. 참여자들은 함께 잠근 자금의 분배에 관한 합의를 갱신합니다. 누군가 이미 폐기된 옛 상태를 공개하면 이 지연이 상대방에게 대응할 시간을 줍니다. commitment transaction은 자금 분배를 기록하는 거래이며, 폐기 키를 가진 상대방은 폐기된 버전의 해당 출력을 페널티 분기로 사용할 수 있습니다. 활성화된 음이 아닌 피연산자를 쓰는 OP_CHECKSEQUENCEVERIFY는 버전 2 이상, 입력의 disable flag 해제, 동일한 지연 유형, 마스크를 적용한 nSequence 값이 충분히 클 것를 요구합니다. 실제 경과 기간은 BIP68이 별도로 강제합니다. CSV는 지연된 복구 분기를 허용합니다. Lightning의 to_local 출력에서는 to_self_delay가 commitment transaction 소유자를 제한하며, 올바른 폐기 키를 가진 상대방은 그 지연 없이 페널티 분기를 사용할 수 있습니다. [3] [9]

거의 같은 두 숫자도 효과는 다를 수 있습니다. 아래 0x로 시작하는 값은 16진수입니다. NOP는 여기서 시간 제한을 더하지 않는 명령을 뜻합니다. 스위치가 거래 입력에 있는지, CSV에 전달한 값에 있는지도 중요합니다. 비트 31은 SEQUENCE_LOCKTIME_DISABLE_FLAG이며 해당 입력의 BIP68 상대 해석만 끕니다. 0xfffffffe에는 이 비트가 있지만 SEQUENCE_FINAL은 아니므로 유효한 nLockTime과 CLTV를 허용합니다. 0xffffffff는 final입니다. disable flag가 설정된 음이 아닌 CSV 피연산자는 NOP로 동작하지만 입력에 그 플래그가 설정되면 활성 CSV 요구를 만족하지 못합니다. 두 경우를 혼동해서는 안 됩니다. [3] [7]

RPC는 비트코인의 블록과 거래를 검증하는 프로그램인 자기 노드를 조작하는 명령입니다. 디코딩은 저장된 정보를 읽기 쉬운 목록으로 바꿀 뿐이며, 테스트 명령이 특정 서명된 거래가 통과할지 검사합니다. Mempool은 해당 노드의 로컬 대기 거래 목록입니다. Core 31의 decoderawtransaction RPC는 version, locktime과 각 입력의 sequence를 보여 줍니다. CLTV/CSV에는 실제 사용한 Script와 지출할 출력을 확인해야 하며 디코딩만으로 유효성이 증명되지는 않습니다. testmempoolaccept RPC는 서명된 후보를 현재 체인, 비트코인의 유효성 규칙, 노드의 로컬 거래 수락 규칙에 따라 시험하며 mempool 수락이나 브로드캐스트는 하지 않습니다. allowed와 거부 이유를 확인해야 하며 성공이 향후 확인을 약속하지는 않습니다. [10] [11] [12]