-
La red Lightning establece que, para enviar y recibir BTC, ambos nodos deben estar en línea.
-
Algunas wallets, como es el caso de Phoenix, funcionan como un nodo independiente.
Una propuesta realizada por el exdesarrollador de Bitcoin Core, Matt Corallo, intenta dar con una solución real a lo que sería un sistema de envío de BTC en la red Lightning, sin que exista la necesidad de que el receptor tenga su nodo conectado a la red y que, sobre todas las cosas, no utilice servicios custodios.
El protocolo actual de la red de micropagos de Bitcoin, o red Lightning, establece que, al enviar fondos, ambos nodos (receptor y emisor) deben estar en línea. Según destaca Matt, en la lista de correos de Lightning-dev, existen múltiples desarrollos que intentan mitigar esta problemática, pero tal parece no intentan dar con una solución real.
Al enviar un pago, el nodo receptor debe estar en línea, o bien, si es desde su teléfono móvil, este debe tener la aplicación de su móvil abierta para recibir el pago. Esto en un escenario donde el usuario no utilice servicios de terceros, como es el caso de los servicios de WatchTower, que vigila los estados del canal sin la necesidad de que el usuario esté conectado a la wallet.
Matt enumera algunas de las «soluciones» que actualmente están presentes en Lightning hoy en día que sí han mejorado la experiencia de usuario, pero no han dado con una respuesta real ante esta problemática.
Entre las soluciones se encuentran, por ejemplo, servicios como LNURL, que permite a los usuarios generar automáticamente múltiples facturas de pago (similar a una dirección de pago en Bitcoin), sin la necesidad de que se cree una por una de forma manual. El cual, si bien es un servicio que mejora la experiencia de uso en la red Lightning, sigue siendo un servicio tercerizado, que podría ser considerado, incluso, custodio, ya que el mantenimiento del servidor LNURL —que generará las facturas de pago a partir de la clave pública del usuario— lo realiza un tercero.
Otras de las soluciones enumeradas se encuentran las facturas AMP, que generan una factura de pago nueva de forma aleatoria cada que el usuario lo requiere, las cuales ya se encuentran disponibles en algunos clientes de la red Lightning, según lo reseñó CriptoNoticias en su momento.
La solución al problema
Corallo, en primer lugar, no establece una solución definitiva a la problemática. En su lugar plantea dos cosas: hacer una lluvia de ideas o brain storming, basada en una posible solución, y que esta puede considerarse como una falacia de «hombre de paja», la cual se refiere a que la solución planteada puede que se oriente solo a una parte del problema real, minimizando así el tamaño real de problemática en cuestión. Esta aclaratoria sirve a Corallo como descargo de responsabilidad sobre lo que se pueda interpretar de su propuesta.
La solución básica que cita Corallo está en la utilización de CLTV, que son transacciones en Bitcoin condicionadas por tiempo, es decir, se ejecutan bajo la condición de que haya transcurrido cierta cantidad de tiempo o se haya alcanzado cierta altura de bloque en la cadena.
Una CLTV, en este caso, para intercambios en la modalidad de que el nodo receptor estará desconectado, establecería un tiempo de espera más tardado. El porqué de esto, es para darle oportunidad al receptor a conectarse y verificar que efectivamente ha recibido los fondos y poder reclamarlos.
No obstante, esta solución puede ser un poco arcaica, así que, como mejora, podrían utilizarse lo que vendrían a ser las PTLC, una mejora de lo que serían las HTLC, transacciones sobre las cuales está construida toda la red Lightning. En este caso las PTLC llegarían a Lightning una vez Taproot se encuentre activo a mediados de noviembre.
Las PTLC podrían permitirle al usuario utilizar servicios de terceros sin confianza de forma segura. En este caso, Corallo pidió sugerencias para la utilización de PTLC en Lightning, una vez que esté disponible en Bitcoin.
