CLTV o bien CheckLockTimeVerify es una interesante funcionalidad de bloque de tiempo que existe en Bitcoin desarrollada para dejar que sus script puedan efectuar avanzadas programaciones temporales en sus transacciones. Una función que deja programar scripts avanzados ceñidos a la poco a poco más creciente demanda de funciones en Bitcoin.

La llegada de Bitcoin, al lado de la renovadora tecnología Blockchain, ha abierto un planeta de posibilidades; entre ellas el dinero programable. Sí, como se escucha, dinero programable. Bitcoin integra muchas funciones, y una de esas funcionalidad es la famosa como Check Lock Time Verify (CLTV), que vuelve posible que las salidas no gastadas (UTXO) de Bitcoin sean bloqueadas y no puedan gastarse hasta llegado un instante anteriormente determinado.

La función CLTV fue integrada en Bitcoin Core por medio de la bifurcación blanda BIP-0065, en la que su desarrollador Peter Todd describe el nuevo código de operación (OP_CODE) OP_CHECKLOCKTIMEVERIFY. Esta función deja que una transacción efectuada en Bitcoin continúe bloqueada en el tiempo y no se haga eficaz hasta el momento en que no se llegue a una data, tiempo o bien altura de bloque determinado.

Así puesto que, la función CLTV es realmente útil y positiva para múltiples casos de empleo en el sistema Bitcoin. Por servirnos de un ejemplo, para el ahorro en un largo plazo de fondos destinados para el pago de la universidad o bien graduación de un familiar. Asimismo es posible programar pagos futuros para datas concretas, como alquileres, servicios, citas médicas, o bien aun una herencia inteligente entre otros muchos.

Así mismo, esta función es en especial esencial para la apertura de nuevas opciones alternativas de pago. Por servirnos de un ejemplo la creación de canales de pago estilo CLTV. Estos canales de pago dejan efectuar transacciones fuera de la blockchain sosteniendo toda la seguridad y beneficios de una transacción usual ocurrida en la cadena. Además de esto, la función CLTV asimismo deja el establecimiento de otras opciones alternativas como reembolsos por un tiempo limitado o bien de fideicomisos. Verdaderamente las aplicaciones y casos de empleo que tiene esta función son infinitas.

¿De qué forma marcha CLTV?

Cuando un usuario establece y efectúa una transacción con el código OP_CHECKLOCKTIMEVERIFY, las salidas de dicha transacción van a ser activadas solo en el instante en que se cumpla la condición establecida, y no en el instante en que se efectúa la transacción. Lo que desea decir que la transacción se realiza adecuadamente mas las criptomonedas continuarán bloqueadas en el tiempo hasta un instante futuro.

El código OP_CHECKLOCKTIMEVERIFY se ejecuta como una parte de un script de Bitcoin, y su programación está basado en el empleo de los tiempos UNIX (Unix Timestamp) o en las alturas de bloques en la blockchain. O sea, es preciso establecer una condición en alguno de estos factores para efectuar una comparación con el tiempo actual. Entonces el OP_CHECKLOCKTIMEVERIFY comprueba el factor superior de la pila con el bloqueo de tiempo (nLockTime) que se estableció en la transacción. Si al hacer esta comparación, se verifica que la condición se ha cumplido, el script puede ejecutarse, de lo contrario el script va a fallar.

Las condiciones a fin de que el script falle en una transacción CLTV son las siguientes:

  1. Que la pila esté vacía y no exista un tiempo definido a fin de que el código realice la comparación y verificación.
  2. Que, como ya se mentó, el factor superior de la pila sea menor que el de la condición establecida para el desbloqueo de las salidas no gastadas. Lo que señala que no  ha trascurrido el tiempo preciso para desbloquear la transacción.
  3. Otra condición de fallo se va a dar si el bloqueo de tiempo establecido es medido en altura de bloques y el factor superior de la pila usa medidas en tiempo (en segundos) o bien a la inversa.
  4. El campo nSequence de esta entrada está establecido en 0xFFFFFFFF.

Entonces, una transacción CLTV solo puede incluirse en la blockchain cuando ha superado el tiempo o bien la condición establecida. En el momento en que sucede esto, las transacciones CLTV son verificadas y añadidas de manera inmediata a la blockchain, y se consideran como gastadas.

Relación de CLTV y nLockTime

Tanto CLTV como nLockTime son 2 funciones que dejan a Bitcoin programar acciones que dependen del tiempo o bien altura de bloque para su adecuada ejecución. Mas la relación y alcance de las dos va considerablemente más allí. Por una parte, nLockTime garantiza que Bitcoin pueda programar transacciones que se ejecuten en una determinada altura de bloque (bloqueo de tiempo en bloque) o bien por marca de tiempo o bien timestamp (bloqueo de tiempo concreto). Con esto Bitcoin habilita la capacidad de poder programar pagos utilizando estos factores.

Pero por otra parte, CLTV deja añadir una capa de verificación y de programación auxiliar a los nLockTime. Esto es por el hecho de que CLTV toma el nLockTime y comprueba que un conjunto agregado de condiciones programadas para su activación están dadas, una situación que era considerablemente más directa con el nLockTime original.  Aun, CLTV deja trastocar ciertas condiciones originales de la transacción si se dan determinadas condiciones.

Por ejemplo, una dirección de multifirmas dos de tres, que no se haya movilizado en un determinado periodo de tiempo, puede mudar sus factores de autentificación a 1 de tres, a fin de que de este modo ciertas personas autorizadas en un inicio pueda movilizar los fondos que están allá contenidos.  Esta es una funcionalidad única que CLTV puede ofrecer y nLockTime por sí misma no puede.

¿Cuánto sabes, criptonauta?

¿CLTV es capaz de alterar las propiedades de los scripts transcurrido un tiempo y bajo determinadas condiciones?

Implementación de CLTV

Uno de los mayores y más esenciales potenciales de la función CLTV es permitir la creación de canales de pagos y que estos puedan incorporarse con corrección. Mediante los canales de pago se pueden crear micro-transacciones fuera de la blockchain. Todo ello sin precisar abonar tantas tarifas de comisión por cada una y sin colapsar la blockchain.

En los canales de pago, un usuario puede efectuar una transacción a otro depositando una cierta cantidad de criptomonedas en una dirección multifirma (MultiSig). Los dos usuarios van a tener acceso a dicha dirección. Y  el usuario que efectúa la transacción puede ir firmando pequeñas transacciones que van a ser efectuadas al otro usuario desde esos fondos. Esto  hasta el momento en que consiga el producto deseado. El sobrante de los fondos le van a ser devueltos a sí mismo en una transacción de retorno por cada micro-transacción que realice. Al paso que el mercader va a poder demandar el pago final amontonado, que se va a haber efectuado sin colapsar la blockchain y por el que María pagó solo una tarifa de comisión.

Ejemplo de de qué manera marcha CLTV

Si María quiere ver un vídeo, mas por él debe abonar 1 sat por segundo visualizado. A María no le es conveniente efectuar estas transacciones de 1 sat por segundo por medio de una transacción usual en Bitcoin. En tanto que para ello va a deber abonar la tarifa de comisión por cada transacción que realice. Además de esto debe aguardar que dicha transacción se confirme en un bloque; lo que pasa cada diez min en Bitcoin.

Al ver que no es recomendable, María decide crear un canal de pago. En este canal va a hacer un depósito en una dirección multifirma de 0.5 BTC, que equivale a 50.000.000 de satoshis. Tanto el mercader como María van a tener acceso a la dirección multifirma. Entonces cuando María empieza a visualizar el vídeo, firmará una transacción donde mandará 1 sat al mercader por el primer segundo visualizado. Y 49.999.999 sats a una dirección de cambio de su pertenencia.

Este proceso se va a repetir múltiples veces siempre que María siga viendo el vídeo. Esto es, proseguirá firmando micro-transacciones y pagando la cantidad de satoshis equivalente a los segundos que visualice del vídeo, y depositando sus vueltas en una dirección de retorno. Si María solo visualizó dos segundos de vídeo, entonces firmará una nueva transacción, mas esta vez de dos sat para el mercader y 49.999.998 sat para su dirección de retorno. Si visualizó solo tres segundos, firmará otra transacción, mas esta vez de tres sat para el mercader y 49.999.997 sat para su dirección de retorno.

Durante este proceso, el mercader no demandará ni firmará las transacciones de 1 sat o bien dos sat recibidas. Sino aguardará a que María visualice todo cuanto desee del vídeo y demandará el pago final. Esto es, la transacción más grande. El resto de transacciones efectuadas al comienzo no van a ser firmadas en tanto que implicaría un doble gasto. Con lo que el mercader debe decantarse por la transacción más grande que contiene todos y cada uno de los satoshis recibidos, en este caso de ejemplo la transacción de tres satoshis.

Además al final el mercader firma solo una transacción, esta es la que va a ser añadida en la blockchain y va a ser la única por la que se deba anular la tarifa de comisión pertinente a los mineros. Además de esto, María puede incorporar una transacción CLTV al comienzo para asegurar la retornabilidad de sus fondos depositados en la dirección multifirma. Si establece un tiempo determinado a fin de que los dos firmen la transacción y por cualquier motivo, uno o bien ninguno de los 2 puede firmarla ya antes de ese tiempo. De este modo María puede recobrar su dinero. Puesto que si no se firma la transacción ya antes de la condición establecida, María puede firmar la transacción y tener su dinero de vuelta después de trascurrido el tiempo establecido.

Entonces, para resumir, el código OP_CHECKLOCKTIMEVERIFY ofrece una ventaja positiva para la implementación de contratos inteligentes. Esto puesto que garantiza la integridad de los fondos hasta haber alcanzado la marca de tiempo o bien altura de bloque establecida. Al paso que evita las fallas del sistema por la maleabilidad de las transacciones.