Hechos clave:
-
Algunas facturas de Lightning dejan pistas de “dónde” están ubicados los nodos
-
Las “rutas ciegas” ocultan cuál fue el camino seguido por tus bitcoins en la red Lightning.
Imagina enviar un pago a través de la red Lightning y que en último momento se oculte el camino que recorrieron tus satoshis (bitcoins o BTC) para llegar a su destino final.
Esta es la propuesta de la «ruta ciega» (blinded path), que consiste en ocultar criptográficamente la ruta que recorren los satoshis de un pago en la red Lightning para llegar a su destinatario o receptor.
Los «blinded paths» fueron explicados brevemente por el desarrollador Olaoluwa Osuntokun, en la lista de correos de desarrolladores de Bitcoin de la fundación Linux.
El desarrollador hizo un resumen de una conferencia de desarrolladores de Lightning que tuvo lugar en la ciudad de Oakland, Estados Unidos, a finales del mes pasado. Al evento asistieron más de 30 especialistas para proponer y discutir nuevos desarrollos sobre la red Lightning de Bitcoin.
«Las rutas ciegas [blinded paths] son una nueva propuesta para resolver el problema de privacidad de la ‘última milla’ al recibir pagos en LN«, escribió Osuntokun. Esto hace referencia a cómo el receptor de un pago puede saber exactamente cuáles nodos transmitieron la transacción.
Eventualmente, el receptor de un pago en Lightning podría descubrir incluso la dirección on-chain desde la cuál una wallet o monedero de Bitcoin se conectó a un nodo de Lightning, señala.
El desarrollador comenta que en la actualidad, las facturas de Lightning, que indican la ruta de pagos o saltos [hop hints] que deben seguir los satoshis, y el monto transferible, revelan un camino de nodos a seguir en la red y con ello, pueden revelar los canales que tienen abiertos y «dónde» está ubicado el nodo respecto al resto de la red Lightning.
“Las rutas ciegas solucionan este problema de privacidad a nivel de nodos al reemplazar los ‘hop hints’ con una ruta criptográficamente ofuscada. A un alto nivel, el receptor puede construir una ruta de 1 o más saltos [hop hints, saltos entre nodos], reunir las llaves públicas de cada nodo, y luego ofuscarlas de manera que el emisor del pago la use para encontrar su ruta, pero no sepa realmente cuántos nodos o saltos hacen parte de ella”
Olaoluwa Osuntukun, desarrollador de Lightning.
Sin embargo, el desarrollador comenta que esta propuesta tiene varios retos por delante. En primer lugar, explica que «las rutas ciegas» son compatibles por el momento solo con el estándar de facturas de Lightning BOLT 11, por lo que solamente se puede almacenar un número limitado de rutas en una factura.
Esto podría obstaculizar un pago ya que una factura abstraída en un código QR podría no incluir toda la información necesaria para llevar los satoshis a su destino final.
Por otra parte, señala que un cambio en alguna política de un nodo o un canal podría invalidar una ruta por completo, haciendo que una factura de blinded path no sea efectiva durante mucho tiempo.
«Una solución propuesta es que los nodos podrían dar un periodo de gracia para sus políticas y que las rutas ciegas tengan una fecha de expiración explícitamente definida», señala el desarrollador.
Asimismo, indica que si no se envía un conjunto lo suficientemente amplio de rutas, el emisor del pago pudiera perder el rastro del camino que debe seguir para entregar unos bitcoins en Lightning.
Canales de Lightning en crecimiento aunque su privacidad es mejorable
Aunque la privacidad de la red Lightning es mejorable, la liquidez (capacidad para enviar bitcoins) ha estado en crecimiento, como también el número de canales abiertos y las herramientas para manejarlos.
CriptoNoticias ha reportado cómo con herramientas como Umbrel ahora es más fácil correr un nodo de Lightning en dispositivos que no sean una computadora Raspberry Pi.
Del mismo modo, los más de 88 mil canales existentes de Lightning ahora pueden enviar hasta 4000 BTC. Incluso existe un mercado donde estos canales pueden ser intercambiados entre sus diferentes dueños, y que ha crecido un 600% en el último mes.
