OP_CHECKLOCKTIMEVERIFY

Um bloqueio temporal escrito na saída, e não na transação que a gasta. Peter Todd especificou-o no BIP65, onde ele assumiu o lugar do antigo opcode no-op NOP2, e a regra é aplicada desde o bloco 388.381, em dezembro de 2015. Se você já configurou um plano de herança ou um caminho de recuperação, este opcode é o que mantém a porta fechada.

Como funciona

OP_CHECKLOCKTIMEVERIFY lê um número da pilha do script, compara-o com o campo locktime da transação que tenta gastar a saída e aborta todo o script se o gasto for antecipado.

O BIP65 lista cinco formas de a verificação falhar: a pilha está vazia, o item do topo é negativo, o item e o locktime da transação divergem quanto a estarem contando blocos ou contando segundos, o item é maior que o locktime da transação, ou o número de sequência da entrada está definido como 0xffffffff. Essa última condição fecha um furo evidente. Um locktime é ignorado por completo quando todas as entradas estão marcadas como finais, então, sem ela, quem gasta poderia simplesmente desligar o prazo e levar o dinheiro.

Dois detalhes surpreendem quem lê um script assim pela primeira vez. O opcode não consome o número que verifica, então os scripts reais colocam depois dele o OP_DROP para organizar a pilha. E aceita um operando de cinco bytes em vez dos quatro habituais, porque o maior valor com que pode ter de se comparar é 2**32-1, o intervalo completo do campo que verifica.

A mecânica do soft fork foi a de sempre. Redefinir um no-op é invisível para o software que não foi atualizado: um nó antigo executa o opcode, não faz nada e aceita o bloco mesmo assim. A ativação usou os limites de sinalização dos mineradores da época: 750 blocos em 1.000 para começar a aplicar a regra e 950 em 1.000 para torná-la obrigatória.

Onde ele aparece

OP_CHECKLOCKTIMEVERIFY aparece onde o dinheiro tem de ficar parado até que chegue uma data.

As carteiras de herança e de recuperação são o caso mais claro. Um descritor pode indicar que a sua própria chave gasta a qualquer momento, enquanto uma chave de backup gasta somente após uma altura indicada, o que dá a um herdeiro um caminho que não precisa da cooperação de ninguém nem de um advogado segurando um envelope lacrado. O Miniscript escreve isso como o fragmento after(), e as carteiras que o aceitam mostram a altura em linguagem simples em vez de script bruto.

A Lightning o usa para o prazo absoluto de um pagamento roteado. Uma fatura BOLT11 carrega um delta de expiração final, de 18 blocos por padrão, e os contratos com hash ao longo da rota são empilhados acima desse número para que cada salto possa recuperar seus fundos em uma ordem fixa se o pagamento nunca for concluído.

O depósito em garantia e os reembolsos sem confiança seguem a mesma forma: pague agora para um script e, se a contraparte nunca assinar, receba o dinheiro de volta quando o prazo passar. O opcode também é a resposta honesta a quem vende um “cofre com bloqueio temporal” como produto, porque é só isso que um produto assim pode ser.

OP_CHECKLOCKTIMEVERIFY vs OP_CHECKSEQUENCEVERIFY

OP_CHECKLOCKTIMEVERIFY nomeia um momento; OP_CHECKSEQUENCEVERIFY nomeia uma duração. Um diz “não antes de dezembro”, o outro diz “não até 144 blocos depois que esta saída específica for confirmada”, e só o segundo começa a contar quando a saída chega. O BIP112 definiu a forma relativa, que foi ativada no bloco 419.328 em julho de 2016, cerca de sete meses depois de seu irmão absoluto. Protocolos de contrato usam os dois, muitas vezes em um mesmo script: um prazo absoluto para limitar todo o acordo e um atraso relativo para garantir a uma das partes uma janela para reagir.