Qué pasó
El 13 de agosto de 2026, LND - la implementación de Lightning más desplegada - publicó
v0.21.2-beta y v0.20.3-beta. Ambas traen la
misma corrección en la capa de gossip. Según las
notas de la versión:
"Un peer que respondía a nuestro query_channel_range podía antes hacernos almacenar en
memoria una cantidad impredecible de short channel IDs, ya que el único límite era un tope
grueso de 67MB sobre los bytes a los que podía descomprimirse una única respuesta zlib".
Qué cambia
Cuando un nodo Lightning arranca o se reconecta, pregunta a los peers a los que está conectado qué canales conocen dentro de un rango de bloques. Las respuestas llegan como listas de identificadores cortos de canal, opcionalmente comprimidas, y una sola pregunta puede responderse a lo largo de muchos mensajes.
El límite anterior estaba medido en la unidad equivocada. Acotaba los bytes a los que podía expandirse una respuesta comprimida, no cuántos identificadores podía acumular una consulta entera y, según el pull request, una respuesta comprimida transporta muchos más identificadores que una sin comprimir, así que los dos conjuntos de trabajo nunca coincidían. Un peer podía entonces responder una sola pregunta con todos los datos que quisiera, repartidos en suficientes mensajes. Peor aún: una respuesta que fallaba la validación dejaba en su lugar lo ya acumulado, de modo que un atacante podía fijar memoria provocando un error a propósito.
Las nuevas versiones limitan los identificadores decodificados a 100.000 por conjunto de mensajes y a 100.000 en el total de una misma consulta de rango, contabilizan cada respuesta según su codificación real y descartan el estado acumulado apenas una respuesta falla la validación. El peer que hace esto no necesita ningún canal con el nodo al que le habla. El gossip es la parte de un nodo Lightning que habla con desconocidos, así que sus límites son una propiedad de seguridad y no un parámetro de ajuste.
Qué no cambia
Aquí no interviene ninguna clave, firma ni saldo de canal, y las notas de la versión no reportan pérdidas. Es un límite de recursos, y que un nodo sin actualizar se cayera o no dependía de cuánta memoria tuviera.
Pero un nodo que no está corriendo no está mirando, y en Lightning eso importa de una forma en que no importa en cadena. Si una contraparte publica un estado viejo del canal, el lado honesto tiene que notarlo y gastar la salida de revocación dentro del plazo que ambos acordaron: eso es BOLT 5, la regla del protocolo frente a las trampas, no la política de un proveedor. Una watchtower existe precisamente porque el nodo puede estar caído. Esta es la parte de operar Lightning que una seed phrase no cubre: el self-custody de una wallet en cadena es un problema de respaldo, mientras que un canal es además un problema de disponibilidad.
Contexto
Las mismas dos versiones corrigen dos problemas de base de datos con la misma forma: una migración de pagos que fallaba con rutas históricas que llevaban un total blinded sin los datos cifrados que deberían acompañarlo, y bases de datos de canales inicializadas sin una clave de versión persistida, que podían saltarse migraciones obligatorias y luego fallar al arrancar. Las claves son la parte de un nodo Lightning que un respaldo restaura. El estado es la parte que tiene que sobrevivir a cada actualización posterior.