Glossário / Transações e taxas
Bloqueio temporal relativo
- O que é um bloqueio temporal relativo?
- Um bloqueio temporal relativo torna inválida uma entrada de transação até que a saída que ela gasta tenha envelhecido um número definido de blocos ou de intervalos de 512 segundos desde a própria confirmação.
Especificação no BIP-68.
O BIP-68 deu ao campo de número de sequência de quatro bytes de cada entrada um significado de consenso, mas apenas para transações que declaram a versão 2 ou superior. A regra chegou à rede por meio de uma implantação versionbits do BIP-9 no bit 0, que foi aberta em 1º de maio de 2016 e lançada junto com o BIP-112 e o BIP-113. Se você guarda bitcoins atrás de um script de recuperação ou de canal, a contagem regressiva recomeça toda vez que esses bitcoins se movem.
Como funciona
Os bloqueios temporais relativos são codificados no campo de número de sequência, e o bit mais alto decide se algo acontece.
Com o bit 31 definido, o campo não tem significado de consenso e a entrada pode entrar em qualquer bloco. Com o bit 31 limpo, os nós aplicam ao campo a máscara 0x0000ffff e leem os 16 bits restantes como um período de espera. O bit 22 escolhe a unidade. Limpo, o número conta blocos, e o BIP-68 dá o intervalo como de 0 a 65.535 blocos, que ele chama de 1,25 anos. Definido, o número conta períodos de 512 segundos, um intervalo que o BIP declara como abaixo de 33.554.431 segundos, cerca de 1,06 anos. O curioso 512 foi escolhido porque os blocos chegam mais ou menos a cada 600 segundos, então as duas unidades cobrem um período parecido nos mesmos 16 bits.
Uma entrada com um valor n baseado em blocos pode ser incluída n blocos depois do bloco que minerou a saída que ela gasta, então um valor de 1 se cumpre já no bloco imediatamente seguinte, e não no bloco depois desse. Valores baseados em tempo nunca são comparados com um relógio. O BIP-68 mede a partir da mediana do tempo passado do bloco anterior ao que minerou a saída, e em relação à mediana do tempo passado do bloco anterior ao que está sendo construído, e o BIP-113 define esse número como a mediana dos últimos 11 carimbos de data e hora de blocos. Usam-se medianas em vez de carimbos de data e hora brutos porque as regras de consenso garantem que a mediana avança de forma monotônica, o que impede um minerador de cobrar taxas extras mentindo sobre o horário de um bloco.
Duas exceções importam. As regras nunca se aplicam ao campo de número de sequência da entrada de uma transação coinbase. E seis posições, da 16 à 21, ficaram indefinidas para que um soft fork posterior possa aumentar a granularidade ou o teto sem um campo novo.
Onde você o encontra
O BIP-112 aplica um bloqueio temporal relativo por meio de um contrato de depósito em garantia que expira 30 dias depois de receber os fundos.
Alice, Bob e um agente de depósito em garantia compartilham um script 2 de 3. Quaisquer dois podem gastar a qualquer momento; depois do atraso, Alice assina sozinha. O BIP é direto sobre o gatilho: o relógio não começa a correr até que o pagamento para o endereço de depósito em garantia seja confirmado. Essa é toda a diferença em relação a um prazo de calendário, e é por isso que um único script serve cada novo depósito em garantia sem reescrita.
A regra também molda o comportamento das mempools. A verificação de bloqueio por sequência do Bitcoin Core roda em relação à altura do próximo bloco, e não à ponta atual da cadeia, e trata um pai não confirmado como se fosse se confirmar naquele bloco, então um gasto cuja espera expira com o bloco que vem é retransmitido um pouco antes de poder ser gasto. Fora dessa folga não há fila: um gasto imaturo é inválido, não pendente.
Bloqueio temporal relativo vs OP_CHECKSEQUENCEVERIFY
Um bloqueio temporal relativo fica na entrada da transação, enquanto o OP_CHECKSEQUENCEVERIFY fica no script da saída e verifica que uma entrada que a gasta respeite um.
O BIP-68 sozinho não obriga ninguém. Quem constrói o gasto escolhe o valor de sequência, então um atraso escrito ali é uma preferência, não uma regra com que uma contraparte possa contar. O BIP-112 fecha essa lacuna ao tornar o campo legível a partir do script: o opcode falha se a versão da transação for inferior a 2, se a sequência da entrada tiver o sinalizador de desativação definido, se os dois valores discordarem quanto à unidade, ou se o número na pilha exceder a sequência mascarada. Um valor na pilha que traga o próprio sinalizador de desativação faz o opcode se comportar como um NOP, espaço deixado de propósito para um soft fork futuro. Só com essas verificações em vigor a espera se torna algo com que um agente de depósito em garantia ou um par da Lightning Network pode contar.