OP_CHECKLOCKTIMEVERIFY

Un bloqueo temporal (timelock) escrito en la moneda y no en la transacción que la gasta. Peter Todd lo especificó en BIP65, donde ocupó el hueco del antiguo opcode NOP2, una operación nula, y la regla se hace cumplir desde el bloque 388.381, en diciembre de 2015. Si alguna vez ha configurado un plan de herencia o una ruta de recuperación, este opcode es lo que mantiene la puerta cerrada.

Cómo funciona

OP_CHECKLOCKTIMEVERIFY lee un número de la pila del script, lo compara con el campo locktime de la transacción que intenta gastar la moneda y aborta todo el script si el gasto llega antes de tiempo.

BIP65 enumera cinco maneras en que falla la comprobación: la pila está vacía, el elemento de la cima de la pila es negativo, el elemento y el locktime de la transacción no coinciden en si cuentan bloques o cuentan segundos, el elemento es mayor que el locktime de la transacción, o el número de secuencia de la entrada tiene el valor 0xffffffff. Esa última condición cierra un agujero evidente. Un locktime se ignora por completo cuando todas las entradas están marcadas como finales, así que, sin ella, quien gasta podría simplemente desactivar el plazo y llevarse el dinero.

Dos detalles sorprenden a quien lee un script así por primera vez. El opcode no consume el número que comprueba, así que los scripts reales colocan detrás el opcode OP_DROP para ordenar la pila. Y acepta un operando de cinco bytes en lugar de los cuatro habituales, porque el mayor valor con el que puede tener que compararse es 2**32-1, el rango completo del campo que comprueba.

La mecánica de la bifurcación blanda (soft fork) fue la de siempre. Redefinir una operación nula es invisible para el software que no se ha actualizado: un nodo antiguo ejecuta el opcode, no hace nada y acepta el bloque de todos modos. La activación usó los umbrales de señalización de los mineros de la época: 750 bloques de cada 1.000 para empezar a hacer cumplir la regla y 950 de cada 1.000 para hacerla obligatoria.

Dónde aparece

OP_CHECKLOCKTIMEVERIFY aparece allí donde el dinero tiene que quedarse quieto hasta que llegue una fecha.

Las billeteras de herencia y de recuperación son el caso más claro. Un descriptor puede indicar que su propia clave gasta en cualquier momento, mientras que una clave de respaldo solo gasta después de una altura indicada, lo que da a un heredero una ruta que no necesita la cooperación de nadie ni un abogado que guarde un sobre sellado. Miniscript lo escribe como el fragmento after(), y las billeteras que lo admiten le muestran la altura en lenguaje llano en lugar de script en bruto.

Lightning lo usa para el plazo absoluto de un pago que se enruta. Una factura BOLT11 lleva una delta de expiración final, de 18 bloques por defecto, y los contratos con hash a lo largo de la ruta se escalonan por encima de esa cifra para que cada salto pueda recuperar sus fondos en un orden fijo si el pago nunca se completa.

El escrow (depósito en garantía) y los reembolsos sin confianza siguen la misma forma: pagar ahora a un script y, si la contraparte nunca firma, recuperar el dinero una vez pasado el plazo. El opcode es también la respuesta honesta a cualquiera que venda una "bóveda con bloqueo temporal" como producto, porque eso es todo lo que puede ser un producto así.

OP_CHECKLOCKTIMEVERIFY frente a OP_CHECKSEQUENCEVERIFY

OP_CHECKLOCKTIMEVERIFY nombra un momento; el opcode OP_CHECKSEQUENCEVERIFY nombra una duración. Uno dice "no antes de diciembre", el otro dice "no hasta 144 bloques después de que esta moneda concreta se confirmara", y solo el segundo pone en marcha su reloj cuando llega la moneda. BIP112 definió la forma relativa, que se activó en el bloque 419.328 en julio de 2016, aproximadamente siete meses después de su hermano absoluto. Los protocolos de contratos usan los dos, a menudo en un mismo script: un plazo absoluto para acotar todo el acuerdo y un retraso relativo para garantizar a una de las partes una ventana en la que reaccionar.