130 / 736CSV

CSV

특정 코인의 확정부터 기다리기

고정된 날짜까지가 아니라 코인이 체인에서 일정 시간을 보낼 때까지 기다려야 하는 경우가 있습니다. CSV는 이 대기 시간을 강제하는 데 쓰입니다. 지갑을 만들거나 결제에 서명한 때부터 세는 것이 아닙니다.

CSV는 Bitcoin Script의 OP_CHECKSEQUENCEVERIFY를 줄인 말입니다. BIP 68과 함께 상대 잠금을 구현해, 확정된 출력이 충분히 오래되었을 때만 특정 사용 경로를 허용합니다. 출력은 받은 금액과 그 사용 조건입니다. 기다린다고 서명이 필요 없어지거나 돈이 보내지지는 않습니다.

안나와 피터는 함께 보관하는 코인을 합의해 쓸 수 있습니다. 여기에 안나 혼자 쓸 수 있는 복구 경로도 원하지만, 해당 출력의 확정부터 일정 시간을 기다려야 합니다. CSV는 이 조건을 강제하는 데 도움이 됩니다. 고정 높이나 시간을 지정하는 CLTV와 달리, 경계가 전체 기록 중 미리 정해진 한 지점은 아닙니다. 특정 코인에 따라 달라집니다. 지갑 생성, 서명 준비, 미확정 거래가 오래 대기한 시간은 이 시작점을 대신하지 못합니다. 지갑은 비트코인을 받고 보내는 앱이나 기기입니다. [1] [2] [8]

블록은 공동 기록에 추가하는 거래 묶음입니다. 블록 높이는 체인에서 블록의 위치를 나타냅니다. 출력이 높이 900000에서 확정되고 필요한 지연이 10블록이라고 해 보겠습니다. 이 잠금 조건에서 가장 이른 사용 블록은 900010입니다. 9블록 간격만으로는 부족합니다. 블록은 일정 간격으로 생기지 않으므로 정확히 몇 분이 걸릴지 약속하는 것은 아닙니다. 충분히 오래되었다고 결제가 확정된 것도 아닙니다. 거래는 다른 조건에서도 유효해야 하며, 채굴자가 실제로 블록에 포함해야 합니다. [2] [4] [9]

지연은 512초 단위로도 표현할 수 있습니다. 코드 2는 1024초를 뜻합니다. 하지만 두 컴퓨터의 시계를 비교하는 것은 아닙니다. 시작은 출력을 확정한 블록의 직전 블록에 대한 Median Time Past이고, 반대쪽은 후보 블록의 직전 블록에 대한 Median Time Past입니다. 최근 최대 11개 블록의 타임스탬프를 정렬한 중앙값입니다. 두 중앙값의 차이가 필요한 지연에 도달해야 합니다. 현지 시간에 정확히 울리는 알람은 아닙니다. [2] [4] [7]

지갑은 결제에 이전에 받은 여러 금액을 합칠 수 있습니다. 각 거래 입력은 이전에 받은 출력을 참조합니다. 그 출력의 경과 기간은 체인에서 확정된 시점부터 세며, nSequence 필드는 입력 자체에 속합니다. 이 필드가 상대 대기에 쓰이는 정보를 담습니다. 일부 돈만 충분히 오래되었다고 되는 것은 아닙니다. 거래에 적용되는 모든 잠금 조건을 만족해야 합니다. 체인 재구성은 확정 위치를 바꿀 수도 있습니다. 따라서 이전에 쓸 수 있었다는 상태는 코인의 되돌릴 수 없는 속성이 아닙니다. 재구성은 네트워크가 다른 유효한 체인 분기를 채택해 기존 블록 기록의 일부를 바꾸는 일입니다. [2] [4] [9]

Full Node는 연결된 검사를 통해 규칙을 독립적으로 검증합니다. BIP 112의 CSV는 스크립트 인수를 해당 출력을 쓰는 입력의 nSequence와 비교합니다. 나이를 직접 계산하지는 않으며, 거래 검증에서 BIP 68이 이를 담당합니다. 비활성화 플래그가 없는 일반 인수라면 거래 버전이 최소 2이고 nSequence의 비트 31이 꺼져 있어야 합니다. 비트는 숫자 필드 안의 작은 스위치입니다. 음수 인수, 이전 버전, 호환되지 않는 nSequence는 검사 실패를 일으킵니다. [1] [2] [3]

비트 22가 지연을 읽는 방법을 결정합니다. 꺼져 있으면 단위는 블록이고, 켜져 있으면 512초 단위입니다. 스크립트 인수와 nSequence는 같은 유형을 사용해야 합니다. 측정값 비교와 비슷합니다. 한쪽은 킬로미터, 다른 쪽은 시간을 센다면 숫자가 크다는 것만으로는 부족합니다. 여기서 구별하는 것은 블록 수와 시간 간격입니다. [1] [2] [3]

하위 16비트가 지연 길이를 담습니다. 마스크 0x0000ffff는 숫자 필드에서 이 부분을 선택합니다. CSV는 이 부분과 지연 유형을 비교하며, 큰 nSequence를 무조건 긴 기다림으로 보지 않습니다. 관련 비트를 선택한 뒤에는 스크립트 요구값이 입력값을 넘을 수 없습니다. 지갑 설계자에게 중요한 기술 조건입니다. 일반 사용자가 전체 절차를 이해하지 않은 채 직접 설정할 항목은 아닙니다. [1] [2] [3]

지연이 0이면 대기를 더하지 않지만 일반 CSV의 다른 검사는 남습니다. 반면 음수가 아닌 스크립트 인수 자체에 비트 31이 켜져 있으면 CSV는 상대 잠금에 영향을 주지 않는 NOP처럼 동작합니다. 그런 인수는 기다림을 강제하지 않습니다. 입력의 nSequence에 있는 같은 플래그와 구별해야 합니다. 일반 인수에서는 그 입력 플래그가 꺼져 있어야 합니다. [1] [3]

안나의 복구 경로가 서명을 요구하면 지연이 끝나도 서명을 제공해야 합니다. 개인 키는 이러한 서명을 만드는 데 사용하는 비밀 숫자 값입니다. 잃어버린 개인키는 돌아오지 않으며, 다른 분기는 여전히 더 이른 사용을 허용할 수 있습니다. 스크립트 실행 중 CSV는 데이터를 쌓는 작업 공간인 스택에 인수를 남깁니다. 그래서 흔히 OP_DROP으로 인수를 제거합니다. 데이터를 지운다고 누구에게나 돈을 가져갈 권한이 생기는 것은 아닙니다. 서명과 선택한 경로의 다른 조건이 권한을 결정합니다. [1] [3] [5]

BIP 112는 OP_NOP3를 CSV로 대체했고 BIP 68, BIP 113과 함께 도입되었습니다. 단순한 계획이 아닌 활성 기능입니다. 예를 들어 Lightning Network의 결제 채널에서 상대에게 대응할 시간을 주는 데 쓰입니다. 하지만 그 대응 자체를 해 주지는 않습니다. 기다림이 끝나도 거래의 전파와 확정이 필요합니다. 수수료, 이용 가능한 데이터, 체인의 상태도 영향을 줍니다. 검증 세부 사항은 Bitcoin Core v29.0과 제시된 명세에서 확인할 수 있습니다. [1] [2] [6]

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 CLTV, Opcode, Timelock, Bitcoin Script, Bitcoin, Full Node. 다음 항목에서도 이 글을 참조합니다 확인, Timelock, HTLC, Opcode.

DOC · 001BIP 112 — OP_CHECKSEQUENCEVERIFY명세 DOC · 002BIP 68 — Relative lock-time명세 DOC · 003Bitcoin Core v29.0 — Script interpreter문서 DOC · 004Bitcoin Core v29.0 — Transaction sequence locks문서 DOC · 005Bitcoin Developer Reference — Transactions문서 DOC · 006Bitcoin Core 0.12.1 — BIP 68/112/113 release notes문서 DOC · 007BIP 113 — Median time-past lock-time calculations명세 DOC · 008BIP 65 — OP_CHECKLOCKTIMEVERIFY명세 DOC · 009Bitcoin Developer Guide — Block Chain문서
개정일: 1차 출처 우선 · 투자 조언이 아닙니다