Locktime

Pense no locktime como um cheque pós-datado escrito dentro do protocolo. Um campo, dois significados, decididos por um limiar: qualquer valor abaixo de 500.000.000 conta blocos, e qualquer valor igual ou superior conta segundos desde 1970. A maioria das transações que você enviar terá um locktime, e ele não fará nada além de proteger você de um truque sutil de minerador.

Como funciona

O locktime fica bem no fim da transação serializada e é verificado antes de qualquer outra coisa sobre o gasto ser considerada.

A regra do limiar é o que faz um único campo cumprir duas funções. Um locktime de 900.000 significa que a transação não pode aparecer em um bloco abaixo da altura 900.000. Um locktime de 1.800.000.000 é um carimbo de tempo Unix e significa que a transação não pode aparecer até que o tempo mediano dos onze blocos anteriores ultrapasse esse momento. A linha divisória, 500.000.000, corresponde a 5 de novembro de 1985, que está com folga antes de o bitcoin existir e com folga acima de qualquer altura de bloco plausível. O campo tem quatro bytes, então o momento máximo que pode expressar é 7 de fevereiro de 2106.

Há um interruptor. O locktime só é aplicado se ao menos uma entrada tiver um número de sequência abaixo de 0xffffffff. Com todas as entradas em 0xffffffff, o campo é ignorado por completo, e foi assim que as transações funcionaram por anos, antes de as carteiras encontrarem um uso para ele.

Esse uso é a proteção contra a caça a taxas. Quando as taxas estão altas, um minerador que perde uma disputa de bloco tem incentivo para tentar minerar de novo o bloco anterior e roubar suas taxas, em vez de construir para frente. Se as carteiras definirem o locktime de cada transação para a ponta atual da cadeia, essas transações se tornam inválidas em qualquer bloco anterior, o que elimina a maior parte do butim e o incentivo. O Bitcoin Core faz isso em gastos comuns, e em cerca de uma vez a cada dez ele escolhe uma altura de forma uniforme entre os 100 blocos anteriores, para que transações de softwares de carteira diferentes não se destaquem umas das outras.

Onde você o vê

Abra qualquer transação recente em um explorador de blocos e o campo locktime normalmente terá um número próximo da altura em que ela foi minerada.

Esse é o comportamento de proteção contra a caça a taxas, e vê-lo é uma leve impressão digital do software que construiu o pagamento. Carteiras que deixam o campo em zero também estão anunciando algo. Empresas de análise de cadeia leem esse campo justamente porque pouquíssimos usuários pensam nele.

Os usos deliberados são mais estreitos. Um locktime no futuro cria uma transação que pode ser assinada e entregue agora, mas não transmitida até mais tarde, o que é a base de esquemas simples de herança e de caminhos de reembolso. Transações de fechamento forçado da Lightning e trocas submarinas usam timelocks para que uma contraparte que desaparece não possa deixar seu dinheiro preso para sempre. Quem constrói essas transações deve observar a fraqueza óbvia: uma transação bloqueada vale apenas o que valem as criptomoedas por trás dela, e se o remetente gastar essas entradas de outra forma antes, a transação pós-datada não vale mais nada.

Locktime vs OP_CHECKLOCKTIMEVERIFY

O locktime restringe uma transação; o OP_CHECKLOCKTIMEVERIFY restringe uma saída. A diferença importa porque só um dos dois obriga alguém que não seja a pessoa que assina.

Um locktime é escolhido por quem constrói a transação, então não protege ninguém: um remetente pode simplesmente construir outra transação sem ele. O OP_CHECKLOCKTIMEVERIFY, definido no BIP65 e ativo na rede desde o bloco 388.381, em 14 de dezembro de 2015, coloca a condição no script da própria saída. Qualquer gasto futuro dessa saída deve ele mesmo carregar um locktime igual ou posterior ao ponto indicado, e nenhuma assinatura pode contorná-lo. É isso que transforma um timelock de uma intenção em uma regra, e é por isso que projetos de cofre, depósito em garantia e herança são escritos com o opcode e não com o campo.