CLTV

Anna planeja uma custódia em que ela e Pedro autorizam juntos os pagamentos habituais. Para uma ausência prolongada, também quer um caminho de recuperação que só possa ser usado após um limite escolhido. CLTV coloca essa condição temporal no script, as regras para gastar moedas recebidas anteriormente. O campo nLockTime, sozinho, adiaria apenas uma transação específica. CLTV impede contornar esse caminho com uma nova transação que use um limite menor. Outros ramos ainda podem ter regras diferentes. [1] [5]

CLTV não identifica o dono nem envia dinheiro. Se o caminho de recuperação exigir a assinatura de Anna, ela precisará fornecê-la mesmo após cumprir a condição de tempo. A chave privada é um valor numérico secreto usado para criar essa assinatura. O tempo não recupera uma chave privada perdida. As moedas tampouco vão automaticamente para outro endereço: alguém precisa preparar, assinar e transmitir uma transação válida. Se outro ramo permitir gastar antes, o bloqueio no ramo de recuperação não restringe essa alternativa por si só. [1]

Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. CLTV serve para uma condição ligada a um ponto predeterminado, e não para exigir uma espera de certa quantidade de blocos após receber aquelas moedas. Essa segunda opção cabe a CSV junto com BIP 68, as regras de bloqueio relativo. Nesse caso, importa a confirmação de uma saída específica: uma quantia recebida com condições de gasto. Nenhuma abordagem garante uma data exata no calendário. O ritmo da mineração varia, e uma reorganização pode alterar o histórico confirmado. Em uma reorganização, a rede adota outro ramo válido da cadeia, substituindo parte do histórico anterior de blocos. [1] [7] [8] [9]

CLTV distingue dois tipos de valor. Abaixo de 500000000, o valor significa altura de bloco, sua posição na cadeia. A partir desse limite, significa um timestamp, uma representação numérica do tempo. A condição do script e o nLockTime da transação que gasta precisam usar o mesmo tipo. Comparar apenas qual número é maior não basta: a posição de um bloco e um horário têm significados diferentes. [1] [3] [5]

Um Full Node verifica as regras por conta própria. Ele compara o limite não negativo do script com o nLockTime absoluto da transação. O limite não pode superar nLockTime; a igualdade é permitida nessa verificação. Também precisam ser satisfeitas as regras para incluir a transação em um bloco específico. CLTV não lê o relógio do computador nem pausa um programa até amanhã. Uma falha torna inválida aquela tentativa de usar o caminho de gasto. [1] [3] [4]

Uma entrada da transação identifica as moedas anteriormente recebidas que estão sendo gastas. Entre seus campos está nSequence. Na entrada verificada por CLTV, ele não pode ser 0xffffffff, o valor especial de sequência final. Se todas as entradas usassem esse valor, nLockTime poderia ser desativado. CLTV impede isso ao exigir uma sequência não final nessa entrada. Isso não estabelece automaticamente um período específico de espera relativa; outras regras cuidam dessa questão. [1] [3] [4]

Considere uma transação hipotética com nLockTime igual a 900000 e uma entrada não final. Para essa condição de tempo, o primeiro bloco possível é 900001. A inclusão exige que nLockTime seja estritamente menor que a altura do bloco candidato. O bloco 900000 não basta, embora a comparação interna de CLTV aceite igualdade. “Finalidade” aqui significa aptidão para inclusão, não irreversibilidade do pagamento. Taxas, outras condições e a escolha do minerador podem adiar ainda mais a confirmação. [4]

Para um timestamp, BIP 113 usa o Median Time Past do bloco anterior: o valor central dos horários ordenados dos últimos até 11 blocos. Não é o relógio do usuário nem o horário do bloco que está sendo minerado. O nLockTime baseado em tempo precisa ser estritamente menor que esse valor. Não se pode, portanto, prometer que as moedas estarão disponíveis exatamente ao meio-dia local. A condição é verificável pela rede, não um cronograma preciso de pagamentos. [2] [4]

Durante a execução, o script usa uma pilha, um espaço de trabalho em que os dados são empilhados. CLTV verifica seu argumento temporal, mas não o remove. Em um esquema simples, OP_CHECKLOCKTIMEVERIFY é seguido de OP_DROP para removê-lo; depois uma chave pública é colocada na pilha e OP_CHECKSIG verifica a assinatura. A chave pública serve para verificar assinaturas e não precisa ficar secreta. Isso explica as funções das instruções, não é uma receita pronta para bloquear dinheiro. A versão do script, os dados iniciais e todos os outros caminhos de gasto também precisam estar corretos. [1] [3]

BIP 65 introduziu CLTV por meio de um soft fork, um endurecimento das regras que substituiu o antigo OP_NOP2. Portanto, não se trata apenas de uma função proposta para o futuro. Ainda assim, é preciso conferir o projeto inteiro: tipo de limite, nLockTime, nSequence, assinaturas e ramos alternativos. Bitcoin Core v29.0 e as especificações indicadas documentam os detalhes. Para o usuário, o principal é entender quem pode gastar antes e depois do limite e quais opções de recuperação existem. [1] [3] [6] [10]