OP_CHECKTEMPLATEVERIFY

BIP-119에서 이를 설명하며, Jeremy Rubin이 2020년 1월에 첫 초안을 공개했고, 네트워크는 이를 채택하지 않았습니다. 이 옵코드는 스택에서 32바이트 해시를 가져와, 사용 트랜잭션 템플릿(버전, 록타임, 입력 수, 시퀀스, 출력, 입력 인덱스)의 해시가 일치하지 않으면 실패합니다. 지갑에서 이를 사용하는 것은 없으며, 소프트 포크가 활성화되기 전까지는 이를 사용하는 것도 없을 것입니다.

작동 방식

상태: 제안되었으나 활성화되지 않았습니다. BIP-119는 2020년부터 초안 상태이며, 2022년의 활성화 제안은 반대가 충분히 많아 보류되었고, Bitcoin Core에는 이에 대한 배포 매개변수가 없습니다.

이 설계는 오래된 업그레이드 기법을 재사용합니다. 이전에 OP_NOP4였던 옵코드 179는 현재 아무것도 하지 않으므로, 이를 포함한 스크립트는 네트워크의 모든 노드에서 유효합니다. 소프트 포크는 그 바이트를 재정의하여 업그레이드된 노드는 검사를 수행하고 구 버전 노드는 스크립트를 계속 통과시키게 하며, 이는 CLTV가 OP_NOP2를, CSV가 OP_NOP3을 거친 것과 같은 경로입니다.

해시에 들어가는 내용은 유별나게 신중하게 선택됩니다. 템플릿은 출력, 금액, 입력 수와 시퀀스 번호를 포함하지만, 사용되는 코인의 txid인 아웃포인트는 의도적으로 제외합니다. 이를 제외하는 데는 제안 전체의 근거가 되는 두 가지 결과가 있습니다. 첫째, 자금 조달 트랜잭션이 존재하기 전에 해시를 계산할 수 있으며, 이것이 미래 지출의 연쇄를 만들고 나서 자금을 조달할 수 있게 합니다. 둘째, 템플릿은 자기 자신에 대한 확약을 담을 수 없으므로 제한이 영원히 반복되게 만들 수 없으며, 그래서 지지자들은 이를 좁은 코버넌트라고 부릅니다.

그 결과는 발생 전에 txid를 알 수 있는 지출입니다. 지갑은 나중에 존재할 결제의 영수증을 제공하고, 그 코인의 다른 지출이 불가능함을 증명할 수 있습니다.

나타나는 곳

OP_CHECKTEMPLATEVERIFY는 메인넷 어디에서도 실행되지 않으므로, 살펴볼 곳은 이 옵코드가 활성화되면 출시될 커스텀 시그넷 위에 구축된 애플리케이션들입니다.

혼잡 제어가 가장 많이 인용됩니다. 수수료 급등에 직면한 거래소는 1,000건의 출금을 이후 결제 트리에 확약하는 단일 출력으로 지급하며, 각 사용자는 나중에 자신의 가지를 확장하여 수수료가 내려갈 때 받을 수 있고, 거래소는 1,000개의 출력이 아니라 1개의 출력을 사용한 것입니다. 볼트가 두 번째입니다. 출금은 먼저 지연이 있는 준비 출력에 도착해야 하므로, 요청이 본인의 것이 아니었다면 자금을 콜드 스토리지로 되찾을 시간이 생깁니다. 결제 풀과 비대화형 라이트닝 채널 자금 조달도 같은 확약 후 확장 형태를 사용합니다.

비트코인을 구매하는 사람에게 정직한 입장은 이것이 실행할 수 있는 무엇도 바꾸지 않는다는 것입니다. 이 약어를 알아둘 가치는 있는데, 비트코인이 무엇이 되어야 하는지에 관한 논쟁에서 끊임없이 등장하고, 이 옵코드가 활성화된다면 일부 수탁 서비스가 광고하는 볼트 기능이 실제로 강제 가능해지기 때문입니다.

OP_CHECKTEMPLATEVERIFY vs OP_CHECKLOCKTIMEVERIFY

OP_CHECKTEMPLATEVERIFY는 사용 트랜잭션의 형태를 제약하는 반면, OP_CHECKLOCKTIMEVERIFY는 지출이 언제 발생할 수 있는지를 제약하며 돈이 어디로 가는지에 대해서는 아무것도 말하지 않습니다. 거의 동일한 이름 때문에 둘은 끊임없이 혼동됩니다.

다른 차이는 상태이며, 이것이 중요한 것입니다. OP_CHECKLOCKTIMEVERIFY는 블록 388,381, 즉 2015년 12월 14일부터 시행되어 왔고, 라이트닝, 에스크로 스크립트, 상속 지갑이 매일 사용합니다. OP_CHECKTEMPLATEVERIFY는 메인넷의 단일 노드도 시행한 적이 없습니다. 어떤 서비스가 귀하의 코인이 템플릿 확약으로 보호된다고 말한다면, 그것은 네트워크가 현재 검사하지 않는 것을 설명하는 것입니다.