Covenants

안나는 Bitcoin으로 저축합니다. 지갑은 비트코인을 받고 보내는 앱이나 기기입니다. 지갑에 보이는 잔액은 이전 트랜잭션에서 생겨 아직 쓰이지 않은 출력인 UTXO로 이루어집니다. 각 출력에는 금액과 그 돈을 쓰기 위한 조건이 기록됩니다. 조건을 적은 짧은 프로그램이 Bitcoin Script입니다. 디지털 서명은 비밀 숫자 값인 개인 키로 결제 승인을 증명하며, 키 자체는 공개하지 않습니다. Multisig는 여러 서명을 요구할 수 있고 Timelock은 기다려야 하는 조건을 더합니다. Covenant는 자금이 이동해야 할 출력처럼 다음 트랜잭션의 구조도 제한할 수 있습니다. 올바른 키를 훔친 사람도 이 규칙을 따라야 합니다. 다만 가능한 모든 지출 경로가 중요합니다. 다른 분기에서 제한을 우회할 수 있다면 그 제한을 믿고 자금을 맡길 수 없습니다. [1] [5] [9] [11]

안나가 지연형 금고에 저축을 넣는다고 생각해 보세요. 여기서 금고는 특별한 기기가 아니라 지출 규칙의 조합입니다. 평소 쓰는 키로 출금을 시작할 수 있어도 자금은 먼저 대기용 출력으로 이동합니다. 대기 기간이 끝나야 예정된 수취인에게 보낼 수 있습니다. 도둑이 출금을 시작했다면 안나는 기다리는 동안 미리 준비한 복구 경로를 이용해 자금을 더 안전한 조건 아래로 옮길 수 있습니다. 하지만 출금을 알아차리고 복구 트랜잭션이 제때 블록에 포함되어 확인되도록 해야 합니다. 블록은 공동 기록에 추가하는 거래 묶음입니다. 이미 끝난 지불을 취소하거나 아무 조치 없이 자금을 자동으로 구하는 기능은 아닙니다. 구체적인 선택지는 금고 설계에 따라 달라집니다. [6] [10]

앱이 출금을 늦추겠다고 약속해도 운영자의 약속에 그칠 수 있습니다. 반면 Bitcoin 스크립트의 규칙은 노드가 검사합니다. 노드는 네트워크의 공통 규칙에 따라 트랜잭션을 검증하는 소프트웨어입니다. 적절한 covenant 구성에서는 제한을 어기는 이체를 거부해야 합니다. 제안된 도구 중 하나가 BIP119의 OP_CHECKTEMPLATEVERIFY, 줄여서 CTV입니다. BIP는 Bitcoin에 관한 제안 문서입니다. CTV는 검사 중인 트랜잭션에서 선택한 데이터의 해시를 미리 저장한 지문과 비교합니다. 해시는 여기서 데이터로부터 계산할 수 있는 짧은 확인용 지문이라고 이해하면 됩니다. 정해진 수취인이나 금액이 바뀌면 지문도 달라져 템플릿과 맞지 않는 이체는 검사를 통과하지 못합니다. 앱에 “금고”라고 적혀 있다는 것만으로 이런 강제력이 생기지는 않습니다. [2]

CTV는 출력을 포함한 트랜잭션을 미리 준비한 템플릿에 묶습니다. 연구되는 방식은 이것뿐이 아닙니다. BIP443의 OP_CHECKCONTRACTVERIFY는 특정 데이터에 대한 검증 가능한 커밋먼트를 담는 출력을 제안합니다. 커밋먼트란 나중에 다른 값으로 바꾸면 검사에서 불일치가 드러나도록 값을 묶어 두는 것을 뜻합니다. 데이터는 공동 자금의 현재 배분처럼 계약 상태를 나타낼 수 있습니다. 정해진 규칙을 충족하면 다음 출력은 갱신된 상태를 담을 수 있습니다. 따라서 CTV와 이 제안은 같은 것을 가리키는 두 이름이 아닙니다. 무엇을 미리 확정해야 하고 무엇을 나중에 바꿀 수 있으며 전체 구성을 위해 어떤 추가 도구가 필요한지 각각 살펴봐야 합니다. [2] [7]

재귀적인 구성은 다음 출력에도 다시 일정한 제한이 붙도록 요구할 수 있습니다. 계약 상태가 차례로 바뀌는 경우처럼 규칙이 여러 트랜잭션에 걸쳐 이어질 수 있습니다. 하나의 스크립트를 검증하면서 무한 반복을 실행한다는 뜻은 아닙니다. Russell O’Connor와 Marta Piekarska는 2017년 논문에서 이런 구성을 설명했습니다. 반복 가능 여부는 개별 제안에 달려 있습니다. [3]

사전 서명 트랜잭션, 시간 잠금, 키 관리를 조합하면 일부 제한을 미리 준비할 수 있습니다. 다만 키를 확실히 삭제하거나 모든 트랜잭션을 보관하거나 추가 협력을 얻어야 할 수 있습니다. 다른 서명자가 부적절한 지불을 거부하리라고 기대하는 Multisig에는 별도의 신뢰 전제가 있습니다. 사용 경험이 비슷해도 규칙을 강제하는 방식이나 복구 가능성이 같지는 않습니다. [5] [6]

금고 외에도 UTXO 공유와 시간에 걸쳐 정산을 나누는 지불 준비 방식이 연구됩니다. 지속적인 협력 필요성을 줄이거나 블록 공간을 더 잘 사용하는 것이 목적일 수 있습니다. 거래가 무제한이 되거나 낮은 수수료가 보장된다는 뜻은 아닙니다. 한 참여자가 혼자 나가는 방법, 다른 참여자가 응답하지 않을 때의 처리, 혼잡할 때 수수료를 내는 방법도 설명해야 합니다. [2] [7]

2026년 10월 17일 기준 BIP119와 BIP443의 상태는 Draft로, 아직 개발 중인 제안입니다. 이전 제안인 BIP345, OP_VAULT는 Closed 상태이며 BIP443을 제안된 대체안으로 명시합니다. 문서가 종결됐다고 금고 연구까지 끝난 것은 아닙니다. 마찬가지로 BIP 번호를 받았다고 네트워크가 변경을 채택한 것도 아닙니다. 테스트 네트워크나 시연용 지갑은 Bitcoin의 실제 운영망인 mainnet 규칙이 그대로인 상태에서도 기능을 보여 줄 수 있습니다. Covenant 금고를 제공하는 서비스라면 실제로 어느 네트워크와 어떤 규칙에서 작동하는지 확인하세요. [6] [8]

너무 좁은 템플릿이나 금액, 스크립트, 수수료 처리의 오류는 의도한 지출을 불가능하게 만들 수 있습니다. 명령이 늘어나면 구현이 안전하게 검증해야 할 범위도 넓어집니다. 따라서 합의 변경은 정확한 명세와 오류 시 동작을 기준으로 평가해야 합니다. Covenant 자체가 타인에게 기존 UTXO의 조건을 사후에 바꿀 권리를 주지는 않습니다. [4] [8]

특정 해법을 볼 때는 누가 출금이나 복구를 시작할 수 있는지, 대응 시간이 얼마나 되는지, 누군가 체인을 계속 감시해야 하는지 물어보세요. 백업, 수수료, 이탈 방법, 실제로 작동하는 네트워크도 확인해야 합니다. Covenants는 자금에 대한 직접 통제력을 넓힐 수 있지만, 제품 설명에 그 단어가 있다는 것만으로 통제력이 입증되지는 않습니다. [3] [6]