OP_CHECKTEMPLATEVERIFY

Anna quer reservar fundos para dividir mais tarde entre Peter e Eva. Ela não quer depender apenas da promessa de alguém que guarda o dinheiro. No Bitcoin, fundos não gastos são registrados como saídas de transações, chamadas UTXO: cada uma contém um valor e as condições para usá-lo. CTV poderia incluir um plano específico de distribuição nessas condições. Quando a saída fosse gasta, os nós, programas que verificam as regras da rede, confeririam se a nova transação segue o plano. Outro destinatário ou um valor diferente do fixado não passariam na verificação. Jeremy Rubin descreve essa proposta em BIP119, que recebeu seu número BIP em 2020. [1] [3]

O modelo define a estrutura da transferência: a quantas saídas anteriores as entradas fazem referência e quais novas saídas devem surgir. Para as novas saídas, fixa valores e scripts, ou seja, suas condições de gasto futuro. Mais detalhadamente, BIP119 também inclui a versão da transação; nLockTime, um campo para restrições temporais da transação inteira; os campos nSequence das entradas, que podem afetar bloqueios temporais; e o índice da entrada que está sendo verificada. Se algum scriptSig, um script de entrada com dados para o gasto, não estiver vazio, inclui-se também um hash de todos os campos scriptSig. Portanto, não é só uma lista de destinatários: alterar outro dado incluído também produz um modelo diferente. As referências às moedas anteriores específicas e seus valores são outra questão, explicada abaixo. [1]

Byte é uma unidade comum para medir dados. A verificação proposta usa um hash de modelo de 32 bytes calculado com SHA256. O nó calcula a mesma impressão digital da transação que gasta a saída e rejeita uma divergência. Uma assinatura digital comprova a autorização de um pagamento por meio de uma chave privada, um valor numérico secreto, sem revelar essa chave. Outra parte do script pode exigir uma assinatura; CTV não a substitui em todos os casos. Outros tamanhos de argumento não executam essa verificação e ficam reservados para extensões futuras, embora a política de retransmissão possa rejeitá-los. Um argumento incorreto não garante, portanto, um bloqueio seguro. [1] [4] [12]

No exemplo seguinte usamos sats, as menores unidades de bitcoin. O hash do modelo não inclui diretamente os outpoints, isto é, as referências aos UTXO específicos gastos, nem seus valores de entrada. O número de entradas, porém, é fixado. Suponha uma única entrada permitida e saídas que somem 99 000 sats. Uma entrada de 100 000 sats deixa 1 000 sats como taxa. Uma entrada menor que a soma das saídas não financia a transação. Uma entrada maior, mantendo as saídas, aumenta a taxa em vez de criar troco automaticamente. [6] [9]

O modelo pode exigir a passagem para outra saída cujo script inclua um atraso e uma via de recuperação. Isso permite construir um cofre com tempo para reagir a uma retirada indesejada. CTV não é toda a segurança: importam as chaves, as condições das saídas seguintes, o monitoramento e a confirmação da recuperação a tempo. Algumas restrições podem usar transações pré-assinadas, mas com outras exigências de cooperação e eliminação de chaves. [8] [5]

Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. No controle de congestionamento proposto, confirma-se primeiro uma saída que compromete os fundos com uma distribuição posterior. As saídas individuais dos destinatários podem aparecer em transações seguintes, talvez quando a rede estiver menos ocupada. Os destinatários precisam dos dados do plano e de um meio de exercer seu direito. Isso difere de um pagamento comum já confirmado para seu endereço e não transforma o espaço limitado do bloco em espaço infinito. [7] [11]

Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. Anna pode preparar o plano muito antes de publicar o pagamento, sem ainda saber quais serão as taxas. Saídas fixas impedem que ela reduza livremente o valor devolvido à carteira e ofereça a diferença ao minerador. A construção precisa, portanto, de um modo de acrescentar taxas. Uma opção é um CPFP preparado de forma adequada: uma transação seguinte gasta uma saída da original e oferece uma taxa destinada a incentivar o minerador a incluir ambas. Outra opção é um modelo que já preveja uma entrada adicional desde o início. Essa entrada não pode simplesmente ser adicionada a um modelo que permita apenas uma. O mempool é o conjunto de transações não confirmadas de um nó específico; ser aceito nele não garante inclusão em um bloco. [2] [6] [10]

CTV sozinho verifica um modelo específico; não é uma linguagem geral para ler e comparar livremente todos os dados da transação. Permite preparar planos ramificados de transações futuras, mas não deve ser confundido com Covenants recursivos gerais. Combinações com outras instruções propostas podem fazer mais. É preciso verificar se uma demonstração usa apenas CTV ou todo um pacote de mudanças. [1] [2]

Na verificação de 17 de outubro de 2026, BIP119 tem status Draft, ou seja, ainda é uma proposta em desenvolvimento. Ele daria uma nova função de verificação a OP_NOP4, uma instrução que hoje não tem efeito durante a validação de blocos. Esse endurecimento das regras comuns é chamado Soft Fork. O documento, porém, não determina a ativação por si só. Publicar um BIP não transforma o opcode em uma instrução aplicada pela rede; código, apoio de um desenvolvedor ou carteira de demonstração também não comprovam sua aplicação na rede principal do Bitcoin, mainnet. É necessário identificar a rede, as regras e outras propostas das quais cada demonstração depende. [1]

Enquanto a regra não for aplicada, sua presença no script não basta para proteger os fundos: consenso e rejeição pelo mempool são distintos. Mesmo com CTV, um único modelo obrigatório sem saída alternativa pode prender uma saída com fundos insuficientes. Um novo depósito pequeno não bloqueia automaticamente outros UTXO financiados corretamente. Um projeto seguro exige conferir valores, taxas, backups e todas as vias de recuperação. [1] [4] [6]