Pular para o conteúdo
buybitcoinsmart

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.

Não confundir com

Perguntas frequentes

Mover meus bitcoins reinicia um timelock relativo?

Sim. A contagem é medida a partir da confirmação do bitcoin exato que está sendo gasto, então consolidar ou reenviar o reinicia. Os ramos de recuperação construídos sobre OP_CHECKSEQUENCEVERIFY devem ser deixados sem alteração depois de depositados.

Quanto tempo pode durar um timelock relativo?

Até 65.535 blocos, cerca de 455 dias, ou 65.535 intervalos de 512 segundos, um pouco abaixo de 389 dias. Esperas mais longas precisam de um timelock absoluto com OP_CHECKLOCKTIMEVERIFY.

Leia a seguir

Termos relacionados

Mais em Protocolo e atualizações

Ler esta página em inglês