La red Lightning de Bitcoin incorpora canales de pago con financiamiento diferido

El financiamiento compartido, o dual funding, es una implementación en la red Lightning de Bitcoin que permite a los usuarios abrir canales de pago compartiendo el costo de apertura entre ambos extremos del canal (usuario y nodo de red). La función ha sido lanzada en la versión del cliente c-lightning 0.10.0 y se pone en marcha, en esta primera fase, de forma experimental.

El objetivo de esta función es dar acceso a los usuarios a canales de pago sin la necesidad de ver comprometida su privacidad o ser vulnerables a ataques de doble gasto. Con el dual funding, los usuarios podrán financiar una parte del tamaño total del canal, mientras que la contraparte, podrá financiar el resto dentro de la red Lightning.

La puesta en marcha de esta función fue subida al repositorio en GitHub del proyecto, junto al lanzamiento de la versión 0.10.0 de c-lightning, la cual es una implementación ligera y personalizable de Lightning Network.

El funcionamiento, en esta primera etapa, es en modo de prueba y orientado a desarrolladores, quienes pueden realizar las configuraciones correspondientes con nodos compatibles. Junto a ello, también cuentan con la posibilidad de utilizar RBF (“reemplazo por comisión”, por sus siglas en ingles) para la creación de nuevos canales de pago.

Apertura de canales de pago

Abrir un canal de pago con financiamiento individual requiere que el usuario cuente con el total de BTC equivalente a la capacidad seleccionada del canal. Una vez que la transacción de creación es confirmada en la cadena de bloques, el usuario cuenta con un nuevo canal, pero, este estará full, o con su capacidad a tope.

Como ejemplo, puede pensarse en el caso de que un usuario decidiera abrir un canal con financiamiento individual de 1 millón de satoshis. Al abrirlo, confirmada la transacción de apertura, la capacidad del canal será de 1 millón de satoshis, como lo dispuso el usuario inicialmente. Si bien el usuario contaría con fondos para ser transferidos a través de la red Lightning, le será imposible recibir pagos en caso de que no libere parte de la capacidad del canal.

Una solución a esta problemática fueron los canales Turbo, promocionados, en un principio, por Bitrefill, tal como lo reportó CriptoNoticias en su momento. Estos permitían obtener canales de pago inmediatos, financiados completamente por un tercero.

A nivel de experiencia de usuario parecía la solución definitiva, pero presentaban una grave problemática: los canales Turbo pueden ser vulnerables a ataques de doble gasto, dado que el nodo proveedor puede crear una transacción de cierre de canal unilateral sin que el usuario pudiera hacer nada en lo absoluto.

En busca de una solución definitiva, nacen los dual funding, donde tanto el nodo proveedor y el usuario pueden crear un canal de pago, con financiamiento compartido, sin que alguno se encuentre vulnerable ante un ataque malicioso de la contraparte.

La implementación definitiva de dual funding en pequeños pasos

La razón por la que no se ha implementado inmediatamente este sistema, aunque se viene hablando del tema desde 2018, se debe a que, los canales de financiamiento dual requieren que cada parte revele que es propietario de una UTXO a su contraparte. Esto presenta un problema, ya que los atacantes pueden obtener información acerca quién es el dueño de cada UTXO, y colocar a los usuarios en situaciones vulnerables. Sin embargo, frente a esta problemática, ya se han presentado varios escenarios como solución al problema.

Uno de estos escenarios para solucionar la problemática se basa en establecer un algoritmo llamado PoDLE, que sería una prueba de compromiso de creación. Cuando dos usuarios se comprometen a crear un canal, las UTXO reveladas crean un compromiso de creación. Esto quiere decir que, si uno de los usuarios cancelase el proceso de generación del canal con doble financiamiento, este se vería obligado a gastar sus UTXO, lo que lo llevaría a perder dinero.

Debido a todo ello, el uso de dual funding requiere que se tome con cuidado cada una de las implementaciones futuras que se vayan agregando al código fuente de la red Lightning de Bitcoin.