Glossário / Protocolo e atualizações
OP_CHECKSEQUENCEVERIFY
Outros nomes: CSV, BIP112.
- O que é OP_CHECKSEQUENCEVERIFY?
- OP_CHECKSEQUENCEVERIFY bloqueia um bitcoin por um período de tempo medido a partir da confirmação do próprio bitcoin, e faz falhar qualquer gasto cuja entrada não tenha esperado o tempo suficiente.
Especificação no BIP-112.
O opcode lê um número da pilha e o compara com o campo de sequência da entrada que está sendo gasta, de modo que a contagem começa quando o bitcoin entra em um bloco, e não em uma data do calendário. O BIP-112 o definiu e a rede passou a aplicá-lo no bloco 419.328, em 4 de julho de 2016. Todo canal Lightning que você abre depende dele.
Como funciona
O opcode 178 antes era OP_NOP3 e não fazia nada, e foi assim que a regra chegou à rede como um soft fork, e não como uma divisão.
A verificação é feita com três entradas: o número na pilha, o campo de sequência da entrada que está sendo gasta e a versão da transação. Exige-se a versão 2 ou superior, porque as regras de timelock relativo do BIP-68 só se aplicam a partir dessa versão. Se o bit mais alto de qualquer um dos dois valores estiver definido, o timelock fica desativado e o opcode desiste. Caso contrário, os dois precisam concordar quanto à unidade e o valor da pilha não pode superar o campo de sequência.
As unidades vêm em dois tipos e não podem ser misturadas em uma mesma comparação. Desative um determinado sinalizador e o número conta blocos; ative-o e o número conta intervalos de 512 segundos. De qualquer forma, há dezesseis bits disponíveis, então o teto é de 65.535 blocos, cerca de 455 dias, ou a mesma quantidade de intervalos de 512 segundos, o que fica um pouco abaixo de 389 dias. Qualquer espera mais longa precisa, em vez disso, de um timelock absoluto.
A falha não é um atraso, é uma rejeição. Antes de o período de espera terminar, o gasto não é uma transação pendente em uma fila, e sim uma transação inválida que nenhum nó retransmite e nenhum minerador inclui. Nada precisa ser tentado de novo até que o bitcoin tenha idade suficiente, momento em que a transação idêntica passa a ser válida.
Onde você o vê
A Lightning é o maior usuário em volume, e o opcode está no script que protege o seu próprio lado de cada canal.
Quando um canal é fechado unilateralmente, o saldo da parte que fecha vai para uma saída que não pode ser movimentada até que um atraso tenha passado, o to_self_delay do BOLT 3, comumente algumas centenas de blocos. O atraso existe para que o outro par tenha uma janela para publicar uma revogação e ficar com os fundos se o fechamento usou um estado desatualizado. Seu dinheiro está seguro de qualquer forma, mas é por isso que um fechamento forçado deixa você esperando um dia ou mais, enquanto um fechamento cooperativo paga imediatamente.
A mesma construção aparece em swaps submarinos e swaps atômicos, em que um caminho de reembolso só deve se abrir depois que a contraparte teve uma chance justa de reivindicar, e em carteiras de recuperação, em que uma chave de backup passa a ser utilizável depois de um longo silêncio.
Uma armadilha merece um alerta. Um timelock relativo é medido a partir da confirmação do bitcoin específico que está sendo gasto, então ele reinicia toda vez que esse bitcoin se move. Consolidar poeira, movimentar o troco ou deixar uma carteira reorganizar suas saídas vai reiniciar a contagem em cada ramo de recuperação que você configurou, e um herdeiro que esperava que a chave de backup funcionasse no mês seguinte pode encontrar o relógio de volta no zero.
OP_CHECKSEQUENCEVERIFY vs OP_CHECKLOCKTIMEVERIFY
CSV pergunta há quanto tempo o bitcoin existe; CLTV pergunta que horas são. Os dois opcodes ficam lado a lado na numeração, 178 e 177, e são escolhidos para tarefas bem diferentes.
Use a forma absoluta quando o prazo for uma data real: um trust que se desbloqueia em 2030, um reembolso que expira em uma altura conhecida. Use a forma relativa quando a espera deve começar sempre que o contrato começar, que é o que qualquer script escrito uma vez e reutilizado muitas vezes precisa. A Lightning não podia usar timelocks absolutos para os atrasos de canal, porque um canal aberto hoje e um canal aberto no ano seguinte precisariam de scripts diferentes. A dupla também chegou com alguns meses de diferença, o CLTV no bloco 388.381, em 14 de dezembro de 2015, e o CSV no julho seguinte, e o segundo existiu em grande parte porque o primeiro não bastava para construir canais de pagamento.