OP_CHECKTEMPLATEVERIFY

안나는 자금을 준비해 두었다가 나중에 피터와 에바에게 나누어 주려고 합니다. 돈을 보관하는 사람의 약속에만 의존하고 싶지는 않습니다. Bitcoin에서 아직 쓰지 않은 자금은 거래의 출력인 UTXO로 기록되며, 각각 금액과 사용 조건을 담습니다. CTV는 여기에 구체적인 분배 계획을 더할 수 있습니다. 누군가 출력을 쓰면 네트워크 규칙을 검사하는 소프트웨어인 노드가 새 거래가 계획을 따르는지 확인합니다. 수취인이 다르거나 정해진 금액과 다르면 검사를 통과하지 못합니다. Jeremy Rubin이 BIP119에 이 제안을 설명했으며 BIP 번호는 2020년에 부여됐습니다. [1] [3]

템플릿은 입력이 이전 출력 몇 개를 참조할지, 어떤 새 출력을 만들어야 할지 정합니다. 새 출력에서는 금액과 스크립트, 즉 앞으로의 지출 조건을 고정합니다. 더 자세히 보면 BIP119에는 거래 버전, 거래 전체의 시간 제약을 위한 nLockTime, 시간 잠금에 영향을 줄 수 있는 입력의 nSequence 필드, 현재 검사하는 입력의 순서도 포함됩니다. 지출 데이터를 제공하는 입력 스크립트인 scriptSig가 하나라도 비어 있지 않으면 모든 scriptSig 필드를 포괄하는 해시도 들어갑니다. 따라서 단순한 수취인 목록이 아닙니다. 포함된 다른 데이터를 바꿔도 다른 템플릿이 됩니다. 구체적으로 어떤 이전 코인을 가리키는지와 그 금액은 별개 문제이며 아래에서 설명합니다. [1]

바이트는 데이터의 양을 나타내는 일반적인 단위입니다. 제안된 검사는 SHA256으로 계산한 32바이트 템플릿 해시를 사용합니다. 노드는 해당 출력을 쓰는 거래에서 같은 지문을 계산하고, 일치하지 않으면 거부합니다. 디지털 서명은 비밀 숫자 값인 개인 키로 결제 승인을 증명하며, 키 자체는 공개하지 않습니다. 스크립트의 다른 부분이 서명을 요구할 수도 있으므로 CTV가 서명을 언제나 대체하는 것은 아닙니다. 다른 길이의 인수는 이 검사를 수행하지 않고 향후 확장용으로 남겨 두지만, 중계 정책이 거부할 수 있습니다. 잘못된 인수를 썼다고 자금이 안전하게 잠기는 것은 아닙니다. [1] [4] [12]

다음 예에서는 비트코인의 가장 작은 단위인 sats를 사용합니다. 템플릿 해시에는 실제로 쓰는 UTXO를 가리키는 outpoint나 그 입력 금액이 직접 들어가지 않습니다. 다만 입력 개수는 정해져 있습니다. 입력 하나만 허용하고 출력 합계가 99,000 sats인 경우를 생각해 보세요. 100,000 sats 입력은 수수료로 1,000 sats를 남깁니다. 입력이 출력 합계보다 적으면 이 거래를 충당할 수 없습니다. 반대로 입력이 더 크고 출력이 그대로라면 늘어나는 것은 수수료이며, 잔돈이 자동으로 생기지 않습니다. [6] [9]

템플릿은 지연과 복구 경로를 담은 스크립트의 다음 출력으로 자금을 옮기도록 요구할 수 있습니다. 이를 이용하면 원하지 않는 인출에 대응할 시간을 둔 금고를 구성할 수 있습니다. 하지만 CTV가 보안 전체는 아닙니다. 키, 후속 출력의 조건, 모니터링, 복구 거래가 제때 확정되는지가 중요합니다. 일부 제한은 미리 서명한 거래로도 만들 수 있지만, 협력과 키 삭제에 필요한 조건이 다릅니다. [8] [5]

블록은 공동 기록에 추가하는 거래 묶음입니다. 제안된 혼잡 제어에서는 나중의 분배를 약속하는 출력을 먼저 확정합니다. 각 수취인의 개별 출력은 이후 거래에서, 가령 네트워크가 덜 붐빌 때 만들 수 있습니다. 수취인에게는 계획에 관한 데이터와 자신의 권리를 실제로 행사할 방법이 필요합니다. 이는 자신의 주소로 일반 지급이 이미 확정된 상태와 다르며, 제한된 블록 공간을 무한하게 만들지도 않습니다. [7] [11]

지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 안나는 지불을 공개하기 오래전에 계획을 준비할 수 있지만 그때는 미래 수수료율을 모릅니다. 출력이 고정돼 있으므로 자기 지갑으로 돌아올 금액을 임의로 줄여 차액을 채굴자에게 줄 수 없습니다. 따라서 수수료를 더할 방법을 설계에 포함해야 합니다. 적절히 준비한 CPFP가 한 방법입니다. 후속 거래가 원래 거래의 출력을 쓰면서 채굴자가 두 거래를 함께 포함하도록 유도하는 수수료를 제시합니다. 처음부터 추가 입력을 허용하는 템플릿도 가능합니다. 입력 하나만 허용하는 템플릿에 입력을 나중에 그냥 더할 수는 없습니다. Mempool은 개별 노드가 보관하는 미확인 거래의 모음이며, 거기에 받아들여져도 블록 포함이 보장되지는 않습니다. [2] [6] [10]

CTV 자체는 특정 템플릿을 검사합니다. 모든 거래 데이터를 읽고 자유롭게 비교하는 범용 언어는 아닙니다. 미래 거래가 갈라지는 계획을 만들 수는 있지만, 일반적인 재귀적 Covenants와 혼동하면 안 됩니다. 다른 제안 명령과 결합하면 기능이 늘어날 수 있습니다. 따라서 시연이 CTV만 사용하는지, 여러 변경을 묶어서 사용하는지 확인해야 합니다. [1] [2]

2026년 10월 17일 확인 기준 BIP119는 Draft, 즉 아직 개발 중인 제안입니다. 현재 블록 검증에서 아무 효과가 없는 명령인 OP_NOP4에 새로운 검사 기능을 부여하는 내용입니다. 이처럼 공통 규칙을 강화하는 변경을 Soft Fork라고 합니다. 다만 문서 자체가 활성화를 정하지는 않습니다. BIP를 공개했다고 opcode가 실제로 강제되는 명령이 되지는 않습니다. 코드, 개발자의 지지, 시연용 지갑도 Bitcoin의 실제 운영망인 mainnet에서 적용된다는 증거는 아닙니다. 따라서 각 시연이 사용하는 네트워크와 규칙, 의존하는 다른 제안을 확인해야 합니다. [1]

규칙이 적용되기 전에는 스크립트에 적혀 있다는 이유만으로 보호를 기대할 수 없습니다. 합의 규칙과 mempool의 거부는 별개입니다. CTV 지원 환경에서도 다른 길이 없는 단 하나의 필수 템플릿은 자금이 부족한 출력을 묶어 둘 수 있습니다. 그렇다고 새로 들어온 소액 입금이 다른 정상적으로 자금이 들어 있는 UTXO까지 자동으로 막지는 않습니다. 안전한 설계에는 금액, 수수료, 백업과 모든 복구 경로의 검토가 필요합니다. [1] [4] [6]