OP_CHECKTEMPLATEVERIFY

O BIP-119 o descreve, Jeremy Rubin publicou o primeiro rascunho em janeiro de 2020 e a rede não o adotou. O opcode pegaria um hash de 32 bytes da pilha e falharia a menos que um hash do modelo da transação que gasta, ou seja, sua versão, seu locktime, o número de entradas, as sequências, as saídas e o índice da entrada, coincidisse. Nada na sua carteira o usa, e nada o usará até que um soft fork o ative.

Como funciona

Status: proposto, não ativado. O BIP-119 é um rascunho desde 2020, uma ativação proposta em 2022 atraiu objeções suficientes para ser arquivada, e o Bitcoin Core não contém parâmetros de implantação para ele.

O projeto reutiliza um velho truque de atualização. O opcode 179, antes OP_NOP4, atualmente não faz absolutamente nada, então um script que o contém é válido para todos os nós da rede. Um soft fork redefiniria esse byte para que os nós atualizados fizessem a verificação enquanto os antigos continuassem deixando o script passar, o mesmo caminho que o CLTV seguiu com OP_NOP2 e o CSV com OP_NOP3.

O que entra no hash é escolhido com um cuidado incomum. O modelo cobre as saídas, os valores, o número de entradas e seus números de sequência, mas deixa de fora deliberadamente os outpoints, ou seja, os txids das saídas que estão sendo gastas. Deixá-los de fora tem duas consequências sobre as quais toda a proposta se apoia. Primeiro, é possível calcular o hash antes de a transação de financiamento existir, e é isso que permite construir uma cadeia de gastos futuros e depois financiá-la. Segundo, um modelo não pode conter um compromisso consigo mesmo, então a restrição não pode ser feita para se repetir para sempre, e é por isso que seus defensores o chamam de covenant estreito.

O resultado é um gasto cujo txid é conhecido antes de acontecer. Uma carteira pode lhe entregar um recibo de um pagamento que existirá mais tarde e provar que nenhum outro gasto dessa saída é possível.

Onde você o encontra

OP_CHECKTEMPLATEVERIFY não roda em lugar nenhum na mainnet, então o lugar de olhar é o conjunto de aplicativos construídos sobre signets personalizadas que seriam lançados se o opcode fosse ativado.

O controle de congestionamento é o mais citado. Uma corretora diante de um pico de taxas paga 1.000 saques em uma única saída que fixa uma árvore de pagamentos posteriores; cada usuário pode depois expandir seu próprio ramo e receber os fundos quando as taxas caírem, e a corretora gastou uma saída em vez de mil. Os cofres são o segundo: um saque precisa primeiro chegar a uma saída intermediária com um atraso, o que lhe dá uma janela para trazer os fundos de volta ao armazenamento a frio se a solicitação não foi sua. Pools de pagamento e o financiamento não interativo de canais Lightning usam o mesmo formato de fixar primeiro e expandir depois.

Para quem compra bitcoin, a posição honesta é que isso não muda nada que você possa colocar em prática. Vale a pena reconhecer a sigla porque ela aparece constantemente em discussões sobre o que bitcoin deveria se tornar, e porque os recursos de cofre que alguns serviços de custódia anunciam seriam de fato exigíveis se ela algum dia fosse ativada.

OP_CHECKTEMPLATEVERIFY vs OP_CHECKLOCKTIMEVERIFY

OP_CHECKTEMPLATEVERIFY restringe o formato da transação que gasta, enquanto OP_CHECKLOCKTIMEVERIFY restringe quando um gasto pode acontecer e não diz nada sobre para onde vai o dinheiro. Os nomes quase idênticos fazem os dois serem confundidos o tempo todo.

A outra diferença é o status, e é a que importa. OP_CHECKLOCKTIMEVERIFY é exigido desde o bloco 388.381, em 14 de dezembro de 2015, e é usado todos os dias pela Lightning, por scripts de depósito em garantia e por carteiras de herança. OP_CHECKTEMPLATEVERIFY nunca foi exigido por um único nó na mainnet. Se um serviço lhe diz que seus bitcoins estão protegidos por um compromisso de modelo, ele está descrevendo algo que a rede atualmente não verifica.