Locktime y Sequence

Bloquear transacciones en el tiempo. La base de contratos inteligentes temporales en Bitcoin.

Timelocks: control temporal

Bitcoin permite restringir cuándo una transacción o UTXO puede gastarse. Hay dos dimensiones:

Absoluto vs relativo: ¿La restricción es una fecha/altura fija, o un período desde otro evento?

Nivel de transacción vs nivel de script: ¿La restricción se aplica a toda la transacción, o es una condición dentro del script?

nLocktime (transacción)

Cada transacción tiene un campo nLocktime de 4 bytes que especifica cuándo puede incluirse en un bloque.

Interpretación

• Si nLocktime < 500.000.000: se interpreta como altura de bloque
• Si nLocktime ≥ 500.000.000: se interpreta como timestamp Unix

Comportamiento

Si nLocktime = 0 (el default): la transacción puede incluirse en cualquier bloque.

Si nLocktime = 800000: la transacción no puede incluirse hasta el bloque 800.000 o posterior.

Si nLocktime = 1700000000 (timestamp): la transacción no puede incluirse hasta ese momento Unix (~noviembre 2023).

Limitación

El nLocktime solo se respeta si al menos un input tiene nSequence < 0xFFFFFFFF. Si todos los inputs tienen sequence máximo, el locktime se ignora (comportamiento legacy).

nSequence (input)

Cada input tiene un campo nSequence de 4 bytes. Históricamente era para un mecanismo de reemplazo que nunca funcionó bien. Hoy tiene múltiples funciones:

Señal de RBF

Si nSequence < 0xFFFFFFFE (cualquier valor menor que el máximo menos uno), la transacción señala que acepta Replace-By-Fee.

Timelock relativo (BIP 68)

Si el bit más significativo (bit 31) es 0, los bits 0-15 especifican un timelock relativo:

• Si el bit 22 es 0: el valor es en bloques
• Si el bit 22 es 1: el valor es en unidades de 512 segundos

El input no puede incluirse hasta que el UTXO que gasta tenga esa "edad" en bloques o tiempo.

Ejemplo: nSequence = 0x0000000A (10 en decimal, bit 31 = 0, bit 22 = 0) El input no puede gastarse hasta 10 bloques después de que el UTXO fue confirmado.

Desactivar locktime

Si nSequence = 0xFFFFFFFF: el locktime de la transacción se ignora y no hay timelock relativo.

OP_CHECKLOCKTIMEVERIFY (CLTV)

BIP 65. Un opcode de script que verifica timelocks absolutos. <locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP

La transacción solo es válida si su nLocktime es ≥ al valor especificado. Esto bloquea un UTXO hasta una fecha/altura específica dentro del propio script.

Ejemplo de uso: fondos que no pueden moverse hasta 2025: 1735689600 OP_CHECKLOCKTIMEVERIFY OP_DROP <pubKey> OP_CHECKSIG

OP_CHECKSEQUENCEVERIFY (CSV)

BIP 112. Verifica timelocks relativos dentro del script. <sequence> OP_CHECKSEQUENCEVERIFY OP_DROP

La transacción solo es válida si el nSequence del input correspondiente indica un timelock relativo ≥ al especificado.

Ejemplo: fondos que no pueden moverse hasta 144 bloques (~1 día) después de ser recibidos: 144 OP_CHECKSEQUENCEVERIFY OP_DROP <pubKey> OP_CHECKSIG

Casos de uso

Lightning Network

Los canales Lightning usan CSV extensivamente. Cuando se cierra un canal de forma no cooperativa, hay un período de disputa (típicamente 144-2016 bloques) durante el cual la otra parte puede publicar una transacción de penalización si el cierre intentaba hacer trampa.

Herencia (Dead man's switch)

Una transacción pre-firmada con un locktime de 1 año en el futuro. Si el propietario sigue activo, crea una nueva transacción con locktime extendido. Si deja de renovar, el locktime expira y los herederos pueden broadcast la transacción.

Vault

Un esquema donde los fondos pasan por una dirección intermedia con un CSV. Durante el período de espera, el propietario puede "cancelar" enviando a una dirección de recuperación. Esto da tiempo para reaccionar ante un robo.

Escrow temporal

Fondos que se liberan automáticamente si no hay disputa después de X tiempo.

Interacción entre mecanismos

Los diferentes timelocks se aplican acumulativamente:

• nLocktime de la transacción debe satisfacerse
• nSequence de cada input debe satisfacerse (si tiene timelock relativo)
• CLTV dentro del script debe satisfacerse
• CSV dentro del script debe satisfacerse

Una transacción debe cumplir TODAS las condiciones aplicables.