CLTV

Anna diseña una custodia en la que ella y Pedro autorizan juntos los pagos habituales. Para una ausencia prolongada, quiere además una vía de recuperación disponible solo a partir de un límite elegido. CLTV incorpora esa condición temporal al script, las reglas para gastar monedas recibidas anteriormente. El campo nLockTime por sí solo retrasaría únicamente una transacción concreta. CLTV impide eludir esa vía con otra transacción que use un límite inferior. Otras ramas pueden tener reglas distintas. [1] [5]

CLTV no identifica al propietario ni envía dinero. Si la vía de recuperación exige la firma de Anna, ella deberá aportarla incluso después de cumplirse la condición temporal. La clave privada es un valor numérico secreto con el que se crea esa firma. El tiempo no recupera una clave privada perdida. Tampoco traslada automáticamente las monedas a otra dirección: alguien debe preparar, firmar y difundir una transacción válida. Si otra rama permite gastar antes, el bloqueo de la vía de recuperación no restringe por sí mismo esa alternativa. [1]

Un bloque agrupa transacciones en un lote que se añade al historial compartido. CLTV sirve para una condición ligada a un punto predeterminado, no para exigir que se espere cierto número de bloques desde que se recibieron esas monedas. Esto último lo resuelve CSV junto con BIP 68, las reglas del bloqueo relativo. Depende de la confirmación de una salida concreta: una cantidad recibida con sus condiciones de gasto. Ninguna opción garantiza una fecha exacta del calendario. La minería varía y una reorganización puede cambiar el historial confirmado. En una reorganización, la red adopta otra rama válida de la cadena y sustituye parte del historial de bloques anterior. [1] [7] [8] [9]

CLTV distingue dos tipos de valor. Por debajo de 500000000 representa la altura del bloque, su posición en la cadena. A partir de ese límite representa una marca de tiempo expresada numéricamente. La condición del script y el nLockTime de la transacción que gasta deben usar el mismo tipo. No basta con comparar qué número es mayor: la posición de un bloque y una hora no significan lo mismo. [1] [3] [5]

Un Full Node verifica las reglas por sí mismo. Compara el límite no negativo del script con el nLockTime absoluto de la transacción. Ese límite no puede superar nLockTime; para esta comprobación se permite la igualdad. También deben cumplirse las reglas que determinan si la transacción puede entrar en un bloque concreto. CLTV no consulta el reloj de tu ordenador ni pausa un programa hasta mañana. Si la comprobación falla, ese intento de usar la vía de gasto es inválido. [1] [3] [4]

Una entrada de transacción identifica las monedas recibidas anteriormente que se quieren gastar. Incluye el campo nSequence. En la entrada comprobada por CLTV, no puede valer 0xffffffff, el valor especial de secuencia final. Si todas las entradas lo usaran, se podría desactivar nLockTime. CLTV lo evita exigiendo una secuencia no final en esa entrada. Esto no establece automáticamente una espera relativa concreta; esa cuestión corresponde a otras reglas. [1] [3] [4]

Supongamos una transacción con nLockTime igual a 900000 y una entrada no final. Para esta condición temporal, el primer bloque posible es 900001. La inclusión exige que nLockTime sea estrictamente menor que la altura del bloque candidato. El bloque 900000 no basta, aunque la comparación interna de CLTV admitiera la igualdad. Aquí «finalidad» significa poder incluirse en un bloque, no que el pago sea irreversible. Las comisiones, otras condiciones y la decisión del minero pueden retrasar aún más la confirmación. [4]

Para una marca de tiempo, BIP 113 utiliza el Median Time Past del bloque anterior: el valor central al ordenar los tiempos de los últimos hasta 11 bloques. No utiliza tu reloj ni la hora del bloque que se está minando. El nLockTime temporal debe ser estrictamente menor que ese valor. Por tanto, no se puede prometer que las monedas sean gastables exactamente al mediodía local. Es una condición verificable por la red, no un horario preciso de pagos. [2] [4]

Al evaluarse, el script usa una pila, un espacio de trabajo donde apila datos. CLTV comprueba su argumento temporal, pero no lo retira. En un esquema sencillo, OP_CHECKLOCKTIMEVERIFY va seguido de OP_DROP para retirarlo; después se introduce una clave pública y OP_CHECKSIG verifica la firma. La clave pública sirve para verificar firmas y no tiene que mantenerse en secreto. Esto explica el papel de las instrucciones, no constituye una receta lista para bloquear dinero. También deben ser correctos la versión del script, los datos iniciales y todas las demás vías de gasto. [1] [3]

BIP 65 introdujo CLTV mediante un soft fork, un endurecimiento de las reglas que sustituyó al antiguo OP_NOP2. No es solo una propuesta de función futura. Aun así, hay que revisar el diseño completo: tipo de límite, nLockTime, nSequence, firmas y ramas alternativas. Bitcoin Core v29.0 y las especificaciones enlazadas permiten comprobar los detalles. Para el usuario, lo esencial es entender quién puede gastar antes y después del límite y qué opciones de recuperación existen. [1] [3] [6] [10]