(OroyFinanzas.com) – Los canales de pago están a punto de convertirse en una realidad en Bitcoin. Y es que, desde ayer, los CheckLockTimeVerify (CLTV) que ya se habían implementado en el Bitcoin Core en noviembre han obtenido el apoyo de más del 95% de los mineros y con ello se posibilita su uso.

El concepto de CheckLockTimeVerify (CLTV) se introdujo en el BIP 65 por el desarrollador Peter Todd y, a pesar de ser un concepto bastante simple, abre un nuevo horizonte a Bitcoin, ya que, al facilitar los canales de pago, y con esa posibilidad abierta a las transacciones más baratas y rápidas, también se favorece una mayor capacidad de volumen a la red, a la vez que se mantienen todas las ventajas de seguridad ofrecidas por la cadena de bloques (blockchian). Adicionalmente, también se propician otras características para las transacciones como, por ejemplo, el reembolso de fondos, una característica intrínseca de Bitcoin que con CLTV puede ser modificada cuando interese a las partes involucradas.

¿Qué es CheckLockTimeVerify (CLTV)?

El CheckLockTimeVerify (CLTV) esencialmente permite a los usuarios crear una transacción Bitcoin en la que los outputs de dicha transacción quedan activados en algún momento futuro y no en el momento de efectuar la transacción. Para determinar ese momento en el futuro, los bitcoins transferidos quedan ‘bloqueados en el tiempo’ (time-locked, en inglés) con una fecha específica o hasta que se hayan minado cierta cantidad de bloques (teniendo en cuenta que los bloques Bitcoin se minan en un lapso de tiempo de aproximadamente diez minutos).

De esta forma, será posible que unos padres, por ejemplo, decidan enviar unos bitcoins a sus hijos, pero que éstos solo puedan disponer de ellos cuando cumplan 18 años, o también podría utilizarse para, por ejemplo, programar los pagos mensuales de un alquiler.

CLTV facilita la creación de canales de pago en Bitcoin

Pero realmente el mayor potencial de CLTV es cuando se combina con otras características adicionales de Bitcoin. La función más importante de CLTV, y que más repercusión puede tener en el desarrollo de Bitcoin, es que se trata de una característica necesaria para poder implementar correctamente los canales de pago. Como ya explicamos en OroyFinanzas.com cuando profundizamos en proyectos como Lightning Networks, los canales de pago son canales en los que se ejecutan una serie de transacciones fuera de la cadena de bloques (off-chain), pero que a su vez, poseen toda la seguridad de las transacciones comunes registradas en la cadena de bloques. Además de manera adicional, los canales de pago ofrecen ventajas adicionales.

Para entenderlo pongamos un ejemplo: Imaginemos que Bob publica un vídeo por el que hay que pagar una pequeña cantidad de bitcoins por segundo (1 satoshi) para poder visualizarlo. Alicia está interesada en ver ese vídeo. En este contexto, utilizar las transacciones Bitcoin regulares no tiene sentido, ya que los costos normales de transacción se elevarían para todas esas transacciones consecutivas, y también es importante tener en cuenta el hecho de que las transacciones son confirmadas cada 10 minutos de promedio, por lo que el tiempo que se tarda en confirmar las transacciones no haría ver el vídeo cuando se desea. Además se une el inconveniente de las limitaciones que tiene la red Bitcoin actualmente, que solo permite una media de 7 transacciones por segundo, lo que significa que el puñado de transacciones que Alicia tendría que hacer para poder ver el vídeo de dos minutos completo sería una enorme carga para la red Bitcoin. Si además de Alicia, muchos otros usuarios quisieran ver el mismo vídeo publicado por Bob, la red Bitcoin quedaría obstruida con las transacciones de todos ellos rápidamente.

Por lo tanto, Alicia y Bob tienen la posibilidad de abrir un canal de pago. Antes de empezar a ver el vídeo, Alicia envía una cantidad de bitcoins suficiente para poder visualizarlo (digamos 1 bitcoin) a una dirección multifirma (multisign en inglés). Alicia y Bob tienen cada uno el acceso a una de las claves necesarias para enviar los fondos desde esa dirección multifirma. Una vez hecho esto, Alicia empieza a ver el vídeo. Ella firma una transacción desde la dirección multifirma en la que se envía 99,999,999 satoshis a sí misma, y un satoshi a Bob. Bob en ese momento podría firmar la transacción y reclamar el satoshi que se le atribuye. Sin embargo, Bob no reclama su satoshi de inmediato, porque cree que Alice va a querer ver más de un segundo de su vídeo. Y aquí es donde llega lo importante: Alicia efectivamente quiere seguir viéndolo y firma una nueva transacción de la misma dirección multifirma, esta vez se envía a sí misma 99,999,998 satoshis, y envía a Bob de 2 satoshis. Una vez más, Bob podría firmar esta transacción en cualquier momento, y reclamar los dos satoshis que le correspoden. Pero no podría firmar ambas transacciones (la de 1 satoshi y la de dos sahosis), ya que ello constituiría un doble gasto. Por lo tanto, tendría que elegir. Y a menos que Bob esté muy interesado en perder dinero, él siempre firmará la transacción más grande. Si lo hace, recibirá efectivamente un satoshi por segundo – a pesar de que en realidad no ha recibido una nueva transacción por valor de un solo satoshi cada segundo.

Este proceso se puede repetir siempre que Bob no firme su parte de las transacciones. Así, por cada segundo que Alicia vea el video, Bob puede reclamar un satoshi adicional, sin necesidad de esperar a las confirmaciones en la cadena de bloques. Y puesto que solo una transacción – la última que Bob finalmente reclame- queda registrada en la cadena de bloques, Alicia y Bob no obstruyen la red Bitcoin con micro-transacciones, y únicamente tienen que pagar una tasa de minería para que se procese.

Pero, ¿por qué los canales de pago requieren CLTV?

Para entenderlo imaginemos que por alguna razon imprevisible, Bob no puede o no transmite la transacción final, es decir, no firma la transacción que le corresponde una vez que Alicia haya terminado de ver el vídeo. En ese caso, Alicia podría perder el bitcoin que había dejado comprometido en esa dirección multifirma. Y es en este punto en el que CLTV entra en juego. Si a la hora de hacer la transacción inicial de 1 bitcoin a la dirección multifirma, Alicia añade el CLTV para que todo el bitcoin sea reenviado a su dirección después de un tiempo determinado, por ejemplo al día siguiente, y esto ocurrirá únicamente si ambas partes no firmaron la operación antes de ese momento. De esta manera si Bob no firma la transacción en ese periodo de tiempo, Alicia puede firmarla y se asegura de que puede recuperar su dinero.

En este ejemplo, el peor escenario para Alicia es que tiene que esperar un día para poder recuperar su dinero, pero no lo perderá. Y de esta manera, todo el proceso se ha realizado completamente sin la necesidad de confianza entre las partes, ni la participación de un tercero de confianza.

El CLTV no es un concepto nuevo en Bitcoin, pero varía de la opción que le precedía, que es conocida como el concepto bloque en el tiempo (time-lock en inglés). Con esta opción las transacciones que quedaban bloqueadas en el tiempo no eran transmitidas a la cadena de bloques hasta un momento determinado en el tiempo. Hasta que llegase ese momento, ambas partes, es decir Alicia y Bob, no la transmitían a la cadena de bloques, sino que lo hacían una vez que expirase la fecha señalada. Sin embargo, el hecho de que queden registradas en el protocolo como CLTV, convierte el proceso de los canales de pago en un sistema más dinámico y mucho más robusto, y lo que es más importante, elimina los fallos en los canales de pagos causados por la maleabilidad de las transacciones.

CLTV: una implementación consensuada por la comunidad Bitcoin

El CLTV se implementó como una bifurcación blanda (soft fork) en la actualización de Bitcoin Core 0.11.2 que se lanzó el 13 de noviembre. Desde ese momento, una mayoría de los mineros Bitcoin, concretamente el 75 por ciento de la potencia de hash, tenía que actualizar su software para que se pudiese comenzar a permitir los CLTV. A pesar de que la propuesta de Todd había encontrado el consenso de la comunidad y se esperaba que la actualización de los nodos no costituyese ningún problema, el proceso se ha dilatado poco más de un mes, dado que la mayoría de los mineros no había actualizado su software hasta recientemente.

En este sentido, Peter Todd hace unos días, concretamente el 8 de diciembre, pedía en Twitter que un mayor número de mineros actualizase su software, ya que era necesario el 95% de la potencia de hash para que la implementación fuese segura.

FYI: When people say BIP65 has "activated" they mean the 75% threshold is reached; need 95% *enforcement* to use CHECKLOCKTIMEVERIFY safely.

— Peter Todd (@petertoddbtc) December 8, 2015

Y unos días más tarde, el día 11, cuando la cantidad de pools que actualizaban iba en aumento, volvía a recordar: “Parece que AntPool está produciendo bloques v4, por lo que el BIP65 CLTV será obligatorio en pocos días. Si aún no lo has hecho, ¡actualiza ahora!

Looks like AntPool is now producing v4 blocks, so BIP65 CLTV will be mandatory in just a few days. If you haven't already, upgrade now!

— Peter Todd (@petertoddbtc) December 11, 2015

Finalmente, desde ayer, con el bloque Bitcoin número 388.380, se han activado los CLTV. Y ahora todo un mundo de nuevas opciones se abre para los usuarios de Bitcoin.

EPL

Fuente: Bitcoin Magazine

© OroyFinanzas.com

© OroyFinanzas.com