-
Dos de las especificaciones que más se utilizan se enfocan en la protección de los datos.
-
Una serie de funciones podrían eliminarse, de acuerdo con el desarrollador Rusty Rusell.
Los administradores de nodos de la red Lightning de Bitcoin constantemente están probando las mejoras que los desarrolladores implementan. Sin embargo, desde su surgimiento como propuesta en 2015, Lightning ha experimentado numerosos cambios. Varios de estos cambios se volvieron indispensables para el manejo de las transacciones; otros parecen obsoletos en la actualidad.
El desarrollador Rusty Russell divulgó en la lista de correos de desarrolladores de Lightning una solicitud de integración para que los administradores de nodos empiecen a ignorar varias características basadas en versiones de software antiguas y anuncios de nodos de escaneo.
De acuerdo con un análisis parcial que hizo con su propio nodo de Lightning, el desarrollador determinó que 449 nodos utilizan una versión de cliente LND (Lightning Network Daemon) de hace 4 años que administran canales de más de 3 años. Según Olaoluwa Osuntokun, CTO de Lightning Labs y desarrollador de Lightning, estos canales ya no podrán ser actualizados porque requieren la variable htlc_maximun-msat (al menos en LND y Core Lightning).
La variable htlc_maximum_msat en Lightning Network se refiere al tamaño máximo de un HTLC (Hashed TimeLock Contract) que se puede enviar a través de un canal. Para cada canal, se puede definir el tamaño mínimo y máximo de HTLC.
Como explica Russell, para remover las funciones innecesarias, que ya no son compatibles con ninguna versión de software, basta asumir 4 funciones que siempre serán compatibles.
Características que deben removerse
Las dos características que Rusell sugiere que deben eliminarse son initial_routing_sync, que solo tuvo efecto cuando gossip_queries no era compatible con alguna versión de Lightning que estuviese utilizando el nodo y option_anchor_outputs, que solo es compatible con compilaciones Core Lightning (CLN) experimentales anteriores.
Initial_routing_sync es una característica de Lightning que permitía a los nodos sincronizar la información de enrutamiento de la red. Cuando un nodo se conectaba a la red por primera vez, necesitaba descargar toda la información de enrutamiento para poder enrutar pagos. Esta descarga puede ser muy grande y lleva mucho tiempo. Esta característica fue sustituida por gossip_queries.
Option_anchor_outputs es una característica de Lightning que permitía a los nodos crear transacciones de anclaje. Una transacción de anclaje es una transacción que tiene una salida especial que puede ser utilizada para incentivar a los mineros a incluir la transacción en un bloque.
4 características de Lightning necesarias
Mensajes cebolla de tamaño variable (var_onion_optin): esta especificación, que se introdujo en 2019, reemplazó el formato de enrutamiento de cebolla (.onion) encriptado que solo permitía enviar mensajes de longitud fija. Con el cambio, quedó atrás la condición de que cada salto se ejecutara con un mensaje y que solo se pudieran hacer 20 saltos. El formato de tamaño variable también permite transmitir datos arbitrarios a saltos específicos. Aunque el tamaño del mensaje permanece constante, por lo que cualquier aumento en la cantidad de datos enviados disminuye el número máximo de saltos.
Consultas de chismes (gossip_queries): esta especificación, que surgió en 2018, permite que un nodo solicite a sus pares solo un subconjunto de mensajes enviados por otros nodos en la red. Uno de los casos de uso consiste solicitar solo actualizaciones de chismes recientes. Por lo tanto, el nodo puede ignorar actualizaciones antiguas, un procedimiento que ahorrar ancho de banda y acelera el tiempo de procesamiento.
Protección contra pérdida de datos (option_data_loss_protect): esta especificación se introdujo en 2017. Con esta función los nodos pueden enviar información sobre el último estado de su canal cuando se vuelven a conectar. Un nodo que ha perdido datos luego de una desconexión puede reconocer que no está actualizado y solicitar que otro nodo, que no ha perdido datos, cierre su canal en su último estado.
Llaves estáticas de partes remotas (option_static_remotekey): la especificación, incluida en 2019, permite que un nodo solicite a sus pares que cada actualización de canal envíe los fondos que no son HTLC del nodo a una misma dirección. En el pasado, cada actualización de canal requería una dirección diferente. Por ejemplo, un nodo que perdió recibe al menos algunos de sus fondos en la dirección elegida.
Russell indica que probablemente aún sería necesario que los operadores de nodos desactualizados deban configurar estas características, por ahora, pero pueden dejar de verificarlas.
