Timelock

nLockTime e CLTV formam o par absoluto, BIP68 e CSV o relativo. nLockTime limita uma transação específica por inteiro; por si só, não bloqueia um UTXO contra outra transação com configurações diferentes. CLTV ou CSV no ramo de Script executado impõem os campos correspondentes da transação que gasta a saída. Outro ramo permitido pode ter condições diferentes. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 68 — Relative lock-time] [BIP 112 — CHECKSEQUENCEVERIFY]

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 tem de ter outro nSequence. Avalia-se esta transação concreta, não um congelamento permanente das suas entradas. [Bitcoin Core v31.0 — Transaction finality] [Bitcoin Core v31.0 — Sequence constants]

LOCKTIME_THRESHOLD tem o valor 500000000. Um nLockTime inferior significa uma altura de bloco; um valor igual ou superior significa um timestamp Unix. Com o controlo absoluto ativo, nLockTime tem de ser estritamente menor do que a altura do bloco candidato ou o MTP relevante. A igualdade não basta; não se trata de um montante, de uma altura média ou da data de ativação do protocolo. [Bitcoin Core v31.0 — Transaction finality] [Bitcoin Core v31.0 — Locktime threshold]

O BIP113 utiliza para a finalidade temporal o MTP do bloco anterior: a mediana dos timestamps dos últimos 11 blocos, terminando nesse bloco. Não é a média aritmética, a hora atual do utilizador nem o timestamp do bloco candidato. O Bitcoin Core utiliza GetMedianTimePast; chegar a uma data do calendário não garante, por si só, que o bloqueio esteja satisfeito. [BIP 113 — Median time-past]

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 efetua o gasto em causa 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 no controlo da sua validade temporal. As restantes condições de Script continuam a ser necessárias. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v31.0 — Script interpreter]

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, utilizam-se blocos. O atraso em blocos conta-se desde a altura de confirmação da saída gasta. O atraso temporal vai do MTP do bloco anterior à sua confirmação até ao MTP anterior ao bloco candidato. Não é o tempo desde a criação da transação na carteira. [BIP 68 — Relative lock-time] [Bitcoin Core v31.0 — Transaction finality]

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 nSequence mascarado suficiente. 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. [BIP 112 — CHECKSEQUENCEVERIFY] [BOLT 3 — Commitment transaction outputs]

O bit 31 é SEQUENCE_LOCKTIME_DISABLE_FLAG e desativa a interpretação relativa do BIP68 apenas para a entrada em causa. 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. [BIP 112 — CHECKSEQUENCEVERIFY] [Bitcoin Core v31.0 — Sequence constants]

Um bloqueio temporal define uma condição de elegibilidade, não um agendador de envio. A carteira tem de guardar ou criar a transação, fornecer assinaturas e outros dados, cumprir todas as condições e assegurar a taxa e a propagação. A política local e a seleção do minerador continuam a influenciar a confirmação. Uma reorganização pode alterar a altura de confirmação da entrada e a sua idade relativa; o tempo decorrido não garante um resultado irreversível. [BIP 68 — Relative lock-time] [Bitcoin Core v31.0 — Transaction finality]

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 descodificação não prova validade. A RPC testmempoolaccept testa um candidato assinado face à cadeia atual e à avaliação local de consenso e de política, sem aceitação no mempool nem difusão. Verifique allowed e o motivo da rejeição; o sucesso não promete uma confirmação futura. [Bitcoin Core 31.0 — decoderawtransaction RPC] [Bitcoin Core 31.0 — testmempoolaccept RPC] [Bitcoin Core v31.0 — Mempool RPC implementation]