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 confiscación, 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 contemporaneidad.
El desarrollador Rusty Russell divulgó en la tira 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 descomposición parcial que hizo con su propio nodo de Lightning, el desarrollador determinó que 449 nodos utilizan una traducción de cliente LND (Lightning Network Daemon) de hace 4 abriles que administran canales de más de 3 abriles. 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 mayor de un HTLC (Hashed TimeLock Contract) que se puede dirigir a través de un canal. Para cada canal, se puede explicar el tamaño leve y mayor de HTLC.
Como explica Russell, para remover las funciones innecesarias, que ya no son compatibles con ninguna traducción de software, baste hacerse cargo 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 propósito cuando gossip_queries no era compatible con alguna traducció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 ancho 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 fondeadero. Una transacción de fondeadero es una transacción que tiene una salida peculiar que puede ser utilizada para incentivar a los mineros a incluir la transacción en un piedra.
4 características de Lightning necesarias
Mensajes cebolla de tamaño variable (var_onion_optin): esta aclaración, que se introdujo en 2019, reemplazó el formato de enrutamiento de cebolla (.onion) encriptado que solo permitía dirigir mensajes de largo fija. Con el cambio, quedó detrás la condición de que cada brinco se ejecutara con un mensaje y que solo se pudieran hacer 20 saltos. El formato de tamaño variable asimismo 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 mayor de saltos.
Consultas de chismes (gossip_queries): esta aclaració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 dosificar encantado de cuadrilla y acelera el tiempo de procesamiento.
Protección contra pérdida de datos (option_data_loss_protect): esta aclaración se introdujo en 2017. Con esta función los nodos pueden dirigir información sobre el zaguero estado de su canal cuando se vuelven a conectar. Un nodo que ha perdido datos luego de una desconexión puede investigar que no está actualizado y solicitar que otro nodo, que no ha perdido datos, cerrojo su canal en su zaguero estado.
Llaves estáticas de partes remotas (option_static_remotekey): la aclaración, incluida en 2019, permite que un nodo solicite a sus pares que cada puesta al día de canal envíe los fondos que no son HTLC del nodo a una misma dirección. En el pasado, cada puesta al día 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.
