11.1: Compreendendo As Opções de Timelock

Na seção §8.1: Enviando uma transação com Locktime, o nLocktime ofereceu uma ótima opção inicial para bloquear as transações para que não pudessem ser gastas até algum ponto no futuro, com base no tempo (data/hora) ou na altura do bloco. Mas, essa não é a única maneira de colocar um timelock em uma transação.

Compreendendo as Limitações do nLockTime

O nLockTime é uma maneira simples e poderosa de bloquear uma transação, mas possui algumas limitações:

Sem divisões. O nLocktime bloqueia toda a transação;
Sem rede. A maioria dos nodes modernos não aceita um nLockTime na mempool até que esteja na hora ou próximo para ser finalizada;
Sem Scripts. O uso simples e original do nLockTime não permitia que fosse usado em Scripts;
Sem proteção. O nLockTime permite que os fundos sejam gastos com uma transação diferente e não bloqueada.

O último item costumava ser o dealbreaker para o nLockTime. Isso evitou que uma transação fosse gasta, mas não impediu que os fundos fossem usados em uma transação diferente. Então, havia certos usos, mas todos dependiam de confiança.

Compreendendo as Possibilidades dos Scripts de Timelock

Nos últimos anos, o Bitcoin Core foi expandido para permitir a manipulação dos timelocks no nível do opcode com os OP_CHECKLOCKTIMEVERIFY (CLTV) e OP_CHECKSEQUENCEVERIFY (CSV). Ambos trabalham sob uma nova metodologia que fortalece ainda mais o Bitcoin.

Eles são opcodes. Por serem opcodes, o CLTV e o CSV podem ser usados como parte de condições de resgate mais complexas. Na maioria das vezes, eles estão vinculados às condicionais que ireimos descrever no próximo capítulo.

Eles bloqueiam as saídas. Por serem opcodes incluídos nas transações como parte de uma sigPubKey, eles apenas bloqueiam aquela saída única. Isso significa que as transações são aceitas na rede Bitcoin e que as UTXOs usadas para financiar essas transações são gastos. Não há como voltar atrás em uma transação bloqueada por tempo com o CLTV ou o CSV como acontece com um nLockTime vazio. Gastar novamente a UTXO resultante requer que as condições do timelock sejam atendidas.

Aqui está um ponto importante sobre a utilização dos timelocks: Eles são bloqueios de mão única. Os bloqueios de tempo são projetados para desbloquear fundos em um determinado momento. Eles não podem bloquear novamente um fundo: Uma vez que um fundo bloqueado por tempo está disponível, ele ficará disponível para ser gasto.

Compreendendo as Possibilidades do CLTV

O OP_CHECKLOCKTIMEVERIFY ou CLTV é compativel com o clássico recurso nLockTime, mas no novo paradigma baseado em opcode. Ele permite que uma UTXO se torne acessível em um determinado momento ou em uma determinada altura de bloco.

O CLTV foi detalhado pela primeira vez no BIP 65.

Compreendendo as Possibilidades do CSV

O OP_CHECKSEQUENCEVERIFY ou CSV depende de um novo tipo de "locktime relativo", que é definido no campo nSequence da transação. Como de costume, ele pode ser definido como uma data/hora ou uma altura de bloco. Se for definido como um tempo "n", então uma transação bloqueada em um tempo relativo pode ser gasta "n x 512" segundos depois que a UTXO foi minerada, e se for definido como um bloco "n", então uma transação bloqueada em tempo relativo pode ser gasta em "n" blocos depois que a UTXO foi minerada.

O uso do nSequence para um bloqueio de tempo relativo foi detalhado primeiramente no BIP 68, e o opcode CSV foi adicionado no BIP 112.

Resumo: Compreendendo As Opções de Timelock

Agora possuímos quatro opções de Timelocks:

nLockTime para manter uma transação fora do blockchain até um dado momento específico;
nSequence para manter uma transação fora do blockchain até um dado momento relativo;
CLTV para tornar uma UTXO impossível de ser gasto até uma data/hora específica;
CSV para tornar uma UTXO impossível de ser gasto até uma data/hora ou altura do bloco relativa.

O Que Vem Depois?

Vamos continuar "Aumentando o poder do timelock com scripts do Bitcoin" na seção §11.2: Usando CLTV em Scripts.

4.5 KiB Raw Blame History Unescape Escape