Timelock

Anna e Pavel podem organizar seus fundos compartilhados para gastá-los juntos a qualquer momento, mas permitir que Anna os gaste sozinha apenas após uma espera. Se Pavel parar de responder, o ramo adiado oferece uma forma de recuperação combinada antes. Ramo significa aqui uma das opções permitidas de gasto; cada uma pode ter condições diferentes. O bloqueio, portanto, não precisa impedir todas as opções ao mesmo tempo. As regras devem fazer parte da saída desde sua criação. Não basta acrescentar depois “desbloquear em uma semana” numa carteira comum. Mesmo após esperar, Anna precisará da chave correspondente e das informações para construir uma transação válida. Timelock controla o acesso, mas não recupera chaves perdidas. [3]

Um bloqueio absoluto define um limite fixo, registrado no campo nLockTime da transação. Se uma transação tem um nLockTime efetivo de altura 1 000 000, o primeiro bloco que pode satisfazer essa condição é o 1 000 001: a igualdade ainda não basta. Um bloqueio relativo mede uma espera desde a confirmação da saída gasta. Se a saída de Anna surgir no bloco 1 000 000 e o ramo exigir 6 blocos de espera, seu gasto pode satisfazer essa condição no mínimo no bloco 1 000 006. São números de exemplo, não a altura atual da rede. As condições de assinaturas, outras entradas e eventuais bloqueios adicionais continuam valendo. Seis blocos também não são exatamente uma hora: os blocos chegam em intervalos irregulares. A espera relativa não começa na criação da carteira nem quando Anna decide usar o dinheiro. [1] [2] [5]

Imagine que a espera exigida de Anna acabou de terminar. A rede não vai agir por ela. Alguém ainda precisa construir uma transação ou usar uma já preparada, fornecer assinaturas, pagar a taxa e enviá-la à rede. Só então um minerador poderá incluí-la num bloco. Um Timelock satisfeito é uma condição cumprida, não uma reserva de espaço ou transferência automática. Normalmente define quando a possibilidade de gastar começa, não quando ela se encerra sozinha. Numa reorganização, parte da cadeia é substituída por outro ramo válido. Isso pode mudar a confirmação de uma saída e o cálculo de sua espera relativa. Numa construção própria, é preciso conferir antes todos os ramos, o suporte da carteira e os backups das chaves e das regras de gasto; o tempo não corrige uma condição mal definida. [2] [5]

Condições baseadas em tempo usam Median Time Past, ou MTP. Para o bloco avaliado, é a mediana dos registros de tempo dos últimos 11 blocos, terminando no anterior. Ordene os horários e pegue o do meio, o sexto: essa é a mediana, não a média aritmética. BIP113 descreve a regra e Bitcoin Core usa GetMedianTimePast para calculá-la. O tempo relevante não é, portanto, o horário atual do celular de Anna nem o registro de tempo do bloco proposto. Meia-noite no calendário não precisa coincidir com o cumprimento do bloqueio. Bloqueios por altura esperam blocos; não contam segundos. [4]

Agora podemos separar quatro nomes da documentação. nLockTime é um campo da transação inteira para um limite absoluto. nSequence numa entrada carrega uma espera relativa conforme BIP68. Mas nLockTime sozinho não bloqueia um UTXO, uma saída ainda não gasta, contra outra transação com configurações diferentes. Quem está autorizado a gastar pode criar essa outra transação se as regras da saída não impedirem. Bitcoin Script é a linguagem usada para escrever essas regras de gasto. OP_CHECKLOCKTIMEVERIFY, ou CLTV conforme BIP65, exige a configuração absoluta correspondente no ramo utilizado. OP_CHECKSEQUENCEVERIFY, ou CSV conforme BIP112, verifica a configuração relativa; BIP68 exige a espera real. Nem CLTV nem CSV enviam fundos ou fornecem uma assinatura ausente. Outro ramo permitido pode funcionar sob condições diferentes. [1] [2] [3]

As próximas seções são uma referência técnica. Um campo é um dado guardado na transação; uma entrada aponta para uma saída que será gasta. Cada entrada tem nSequence. Um valor especial pode desativar o efeito de nLockTime, por isso preencher uma data não basta. nLockTime é um campo de 32 bits não negativo; zero desativa a condição temporal absoluta. Se todas as entradas estiverem definidas como SEQUENCE_FINAL, com o valor 0xffffffff, um nLockTime não satisfeito é ignorado. Para um bloqueio absoluto efetivo, pelo menos uma entrada precisa ter outro valor de nSequence. Avalia-se esta transação concreta, não um congelamento permanente das suas entradas. [5] [7]

O mesmo campo pode expressar duas coisas diferentes, separadas por um limite numérico. Um timestamp Unix representa o tempo em segundos desde o início de 1970 em UTC. O bloco candidato é aquele no qual a transação examinada seria incluída. LOCKTIME_THRESHOLD tem o valor 500000000. Um nLockTime inferior significa uma altura de bloco; um valor igual ou superior significa um timestamp Unix. Com a verificação absoluta ativa, nLockTime precisa ser estritamente menor do que a altura do bloco candidato ou o MTP relevante. A igualdade não basta; não se trata de uma quantia, de uma altura média ou da data de ativação do protocolo. [5] [8]

Operando é um valor entregue a uma instrução; opcode é a própria instrução de Script. CLTV compara a exigência guardada no ramo com a configuração da transação. Outra verificação determina se a cadeia avançou o suficiente. Isso vai além de comparar a data de hoje com um número. OP_CHECKLOCKTIMEVERIFY exige um operando não negativo, o mesmo tipo altura/tempo de nLockTime e um operando menor ou igual a nLockTime. A entrada que gasta a saída em questão não pode ter nSequence 0xffffffff. O opcode não lê diretamente o relógio nem a altura da cadeia; as configurações da transação são verificadas separadamente na verificação de sua validade temporal. As demais condições de Script continuam necessárias. [1] [6]

O número nSequence contém tanto uma espera quanto interruptores que determinam seu significado. Um bit é um zero ou um nessa representação; ativá-lo pode ligar uma opção. As posições de bits abaixo pertencem ao formato técnico, não são quantidades de confirmações. Para transações de versão 2 ou superior, o BIP68 ativa a condição relativa para entradas sem o bit 31 definido. Os 16 bits menos significativos determinam o atraso; o bit 22 seleciona unidades de 512 segundos e, caso contrário, são usados blocos. O atraso em blocos é contado a partir da a altura de confirmação da saída gasta. O atraso temporal vai do MTP do bloco anterior à sua confirmação até o MTP anterior ao bloco candidato. Não é o tempo desde a criação da transação na carteira. [2] [5]

CSV faz uma verificação semelhante para a espera relativa. Uma máscara seleciona os bits relevantes de nSequence; disable flag é um interruptor de desativação. Lightning Network é uma rede de canais de pagamento: os participantes atualizam a divisão acordada dos fundos bloqueados em conjunto. A espera dá à outra parte tempo para reagir se alguém publicar um estado antigo já revogado. Uma commitment transaction registra a divisão dos fundos; uma chave de revogação permite que a outra parte gaste a saída correspondente da versão revogada por um ramo de penalização. OP_CHECKSEQUENCEVERIFY com um operando ativo não negativo exige versão pelo menos 2, a flag de desativação da entrada desligada, o mesmo tipo de atraso e um valor de nSequence suficiente após a aplicação da máscara. O BIP68 impõe separadamente a idade real. CSV permite um ramo de recuperação adiado. Na saída Lightning to_local, o atraso to_self_delay limita o proprietário da transação de commitment; a outra parte, com a chave de revogação correta, pode utilizar o ramo de penalização sem esse atraso. [3] [9]

Dois números quase iguais podem ter efeitos diferentes. Os valores abaixo que começam com 0x estão em hexadecimal. NOP indica uma instrução que não acrescenta aqui uma restrição de tempo. Também importa se o interruptor está na entrada da transação ou no valor passado a CSV. O bit 31 é SEQUENCE_LOCKTIME_DISABLE_FLAG e desativa a interpretação relativa do BIP68 apenas para a entrada em questão. O valor 0xfffffffe contém esse bit, mas não é SEQUENCE_FINAL: permite nLockTime efetivo e CLTV. O valor 0xffffffff é final. Um operando CSV não negativo com a flag de desativação definida comporta-se como NOP; porém, a flag definida na entrada não satisfaz uma exigência CSV ativa. Estes dois casos não devem ser confundidos. [3] [7]

RPC é um comando para trabalhar com seu nó, o programa que verifica blocos e transações de Bitcoin. Decodificar apenas torna os dados armazenados legíveis; o comando de teste verifica se uma transação assinada específica passaria. Mempool é a lista local de transações pendentes do nó. A RPC decoderawtransaction no Core 31 mostra version, locktime e sequence de cada entrada. Para CLTV/CSV, verifique o Script realmente utilizado e a saída gasta; a simples decodificação não prova validade. A RPC testmempoolaccept testa um candidato assinado com base na cadeia atual, nas regras de validade do Bitcoin e nas regras locais do nó para aceitar transações, sem aceitar a transação no mempool nem transmiti-la. Verifique allowed e o motivo da rejeição; o sucesso não promete uma confirmação futura. [10] [11] [12]