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.
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!
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.
