Causas de la inseguridad en Lightning Network
1. Channel jamming (saturación de canales)
Un atacante abre dos canales en posiciones opuestas de una ruta, envía HTLCs que nunca resuelve, y bloquea los 483 slots HTLC por canal disponibles en los nodos intermedios, o bien ocupa toda la liquidez de un canal con un único HTLC de monto alto. El costo para el atacante es cero: los HTLCs caducan y los fondos retornan. La víctima pierde tiempo de enrutamiento, fees de oportunidad, y reputación como nodo.
El límite de 483 slots HTLC por canal implica que un atacante con solo dos canales puede bloquear más de 10,000 slots honestos en la red simultáneamente, sin pagar fees.
Estado de mitigaciones (2026): El sistema de HTLC endorsement/accountability (BLIP-04) ya está implementado de forma experimental en Eclair (PR #2716, 2025) y LDK. Con este mecanismo, un nodo que ejecuta jamming acumula mala reputación, y sus HTLCs futuros reciben acceso reducido a slots y liquidez reservados para peers de alta reputación. La variante más reciente ("accountability") transfiere la decisión de reenvío al nodo downstream, que tiene información asimétrica mejor sobre su cliente.
Lo que sigue sin despliegue en producción: la propuesta de John Law (2025) de upfront fees + hold fees con "burnable outputs", que haría que el atacante pague un costo real por cada HTLC que mantiene abierto, escalando con el tiempo de retención. Esto convertiría el jamming en económicamente irracional, pero aún está en fase de propuesta.
Conclusión: el jamming es el vector abierto más grave de Lightning Network en 2026. Las mitigaciones reducen su escala, pero no lo eliminan.
2. Replacement cycling y pinning attacks
El ataque (CVE-2023-40231 al 40234) explota Replace-By-Fee: cuando un nodo routing necesita reclamar su HTLC-timeout on-chain, el atacante cicla su transacción HTLC-preimage en y fuera del mempool del nodo víctima mediante reemplazos RBF, impidiendo que éste obtenga el preimage. El objetivo es que la transacción de preimage del atacante se confirme en el bloque de los mineros mientras el nodo víctima mantiene una transacción de timeout incompatible en su mempool local. Si el ciclo se mantiene por suficientes bloques, el atacante retiene los fondos de ambos lados del HTLC.
A pesar de las mitigaciones adoptadas por las implementaciones principales de Lightning (rebroadcasting agresivo, fee escalation), el ataque sigue siendo práctico para atacantes avanzados.
En octubre 2025, Riard divulgó una variante adicional donde el atacante pina una transacción de la víctima y mina selectivamente la versión de mayor fee; este escenario requiere condiciones raras y es difícil de sostener sin ser detectado.
El costo del ataque escala con el valor del HTLC atacado: para micro-pagos (<$50), el beneficio potencial no justifica el costo acumulado de las transacciones de reemplazo. Para HTLCs grandes, el ataque es económicamente racional.
3. Dependencia de estar online y riesgo de watchtowers
Lightning usa un modelo de penalización: cada estado de canal revocado requiere guardar una "revocation secret". Si la contraparte publica un estado antiguo fraudulento, el nodo afectado tiene hasta el CSV timelock (típicamente 144-2016 bloques) para responder con una "justice transaction". Un nodo offline no puede hacerlo.
A marzo de 2026, todos los canales de Lightning dependen del modelo de penalización basado en revocation secrets, lo que crea el problema del "toxic waste": la necesidad de preservar revocation secrets de cada estado previo, que se acumula indefinidamente y complica los backups móviles, las watchtowers y los servicios de recuperación.
LN-Symmetry (Eltoo) resolvería esto permitiendo que cualquier estado posterior reemplace al anterior sin necesidad de justice transactions; bajo ese esquema, transmitir un estado viejo simplemente no surte efecto. Sin embargo, Eltoo requiere un cambio en el protocolo de Bitcoin (BIP446+BIP448, en Draft BIP status en 2026) que aún no ha sido activado.
Riesgo residual de watchtowers: las watchtowers altruistas son vulnerables a DoS (spam gratuito); las comerciales introducen un costo continuo y un punto de falla centralizado. Si todos los watchtowers de un usuario fallan durante el tiempo de disputa, sus fondos quedan expuestos.
4. Riesgos de routing: privacidad y nodos maliciosos
Probing de balances: usando pagos falsos (que siempre fallan sin costo para el atacante) y búsqueda binaria sobre los mensajes de error de fallo, un adversario puede inferir el balance exacto de cualquier canal. La privacidad de los balances mejora la privacidad pero perjudica la eficiencia del routing, creando un tradeoff estructural.
HTLC correlation: en el modelo HTLC actual, el mismo payment hash viaja visible por todos los nodos de la ruta. Un adversario que controla dos nodos no-adyacentes puede correlacionar pagos del mismo flujo.
Estado de mitigaciones (2026): BOLT12 con blinded paths (rutas ciegas) está implementado en CLN y LDK. El receptor construye y encripta los últimos hops de la ruta; ni el sender ni los nodos intermedios aprenden la identidad real del receptor. Es la mejora de privacidad más significativa del protocolo desde el onion routing original.
Los PTLCs (Point Time-Locked Contracts, que reemplazarían HTLCs por claves de curva elíptica únicas por hop) resolverían la correlación de pagos, pero no están desplegados en producción en ninguna implementación en 2026. Requieren Schnorr adaptor signatures y una actualización de las especificaciones BOLT aún pendiente.
5. Custodia parcial en LSPs
Los LSPs no son custodios en sentido estricto (no controlan las keys del usuario), pero tienen visibilidad completa de todos los pagos que pasan por sus canales: montos, hashes de pago y timing. Para un wallet móvil con un único LSP, esto destruye la privacidad del enrutamiento onion, porque el LSP actúa como intermediario único con visibilidad total. Además, un LSP offline implica que el usuario no puede enviar ni recibir pagos Lightning hasta resolver el canal.
Las wallets custodiales (Wallet of Satoshi, etc.) van más lejos: el proveedor tiene custodia directa de los fondos. En 2026, la mayoría de usuarios de Lightning usan wallets custodiales o semi-custodiales, lo que invierte el modelo de seguridad de Bitcoin.
6. Límites de capacidad y transferencias de alto valor
El canal promedio en la red pública tiene ~0.12–0.14 BTC de capacidad en 2026. La probabilidad de éxito de un pago multi-hop sigue la fórmula de Pickhardt (2021):
P(hop) = (capacidad - monto + 1) / (capacidad + 1)
P(ruta) = P(hop₁) × P(hop₂) × P(hopₙ)
Para un canal de 1,000,000 sat de capacidad, un pago de 500,000 sat tiene ~50% de probabilidad de éxito por hop. En una ruta de 3 hops, el éxito total es de apenas 12.5%. Este decaimiento exponencial es la razón matemática por la que los pagos grandes fallan de forma desproporcionada.
Para pagos por encima de $10,000 en rutas aleatorias de la red pública, la tasa de fallo es prácticamente total, incluso con MPP (Multipath Payments). La transferencia de $1 millón citada a veces como caso de éxito usó canales directos pre-acordados entre instituciones, no routing público.
Wumbo channels (sin límite de capacidad, disponibles desde LND v0.11) existen, pero la mayoría de canales de la red no son wumbo, y la concentración de capacidad en un Gini coefficient ~0.97 implica que la liquidez útil está concentrada en pocos nodos institucionales.
Solución propuesta: Three-Layer Hybrid Payment Stack (THPS)
La arquitectura converge en un motor de decisión automático que selecciona la capa de liquidación en función de cuatro parámetros evaluados en tiempo real: monto (M), existencia de canal directo con el receptor, urgencia declarada, y feerate actual del mempool. No es un menú de opciones para el usuario: es una decisión opaca del wallet que el usuario puede revisar pero no necesita gestionar.
El motor de decisión (Decision Engine)
función seleccionar_capa(M, canal_directo, urgente, feerate_mempool):
si M < UMBRAL_MICRO ($200):
retornar CAPA_1_LIGHTNING
si M < UMBRAL_MEDIO ($2,000):
si canal_directo:
retornar CAPA_1_LIGHTNING
si lightning_mpp_viable(M): # test probabilístico de rutas
retornar CAPA_1_LIGHTNING
si ark_disponible(receptor):
retornar CAPA_2_ARK
retornar CAPA_1_LIGHTNING_CON_AVISO # alta probabilidad de reintento
si M < UMBRAL_ALTO ($50,000):
si canal_directo_wumbo:
retornar CAPA_1_LIGHTNING
si ark_disponible(receptor):
retornar CAPA_2_ARK
retornar CAPA_3_ONCHAIN
retornar CAPA_3_ONCHAIN
Los umbrales no son fijos: son configurables por el usuario y ajustables según el estado actual de la red (feerate de mempool alto → subir umbral_alto; red Lightning congestionada → bajar umbral_medio).
Capa 1: Lightning Network (M < $200, o canal directo disponible)
Configuración técnica mínima necesaria para que sea segura:
- LSP no-custodial con JIT channels (el usuario retiene sus keys siempre)
- BOLT12 con blinded paths activo (privacidad del receptor)
- HTLC endorsement/accountability habilitado en el LSP (defensa contra jamming)
- Watchtowers redundantes (mínimo 2: una altruista + una comercial)
- Trampoline routing para pathfinding en wallets móviles (delega conocimiento de la red al nodo trampoline, mejora rutas)
Capa 2: Ark Protocol (M $200–$2,000 sin canal directo; fallback de Lightning)
Ark transfiere VTXOs (virtual transaction outputs) off-chain sin routing dependiente de liquidez de canal. No hay HTLCs en vuelo multi-hop: la transferencia es una permutación de ownership de VTXOs coordinada por el ASP (Ark Server Provider) en rondas periódicas.
Estado de producción verificado (2026):
- Arkade (Ark Labs) procesó sus primeros pagos mainnet en Baltic Honeybadger (agosto 2025) y abrió públicamente en octubre 2025. Second lanzó Bark en mainnet Bitcoin el 9 de junio de 2026, con SDK público, integración con Umbrel y plugin para BTCPay Server.
- Ark en 2025-2026 es nativo e interoperable con Lightning: puede enviar y recibir pagos Lightning desde un balance Ark sin necesidad de gestionar canales.
Limitación crítica de Ark (debe declararse explícitamente): En 2026, Ark sigue en fase de adopción temprana. La variante sin covenants (que es la única desplegable sin soft fork) requiere que el ASP esté online para transferencias instantáneas; sin cooperación del ASP, el usuario puede recuperar sus fondos esperando el timeout de la ronda on-chain, pero no puede gastar off-chain. El trust en el ASP es 1-of-n (el ASP no puede robar fondos pero puede censurar pagos). Ark debe tratarse como componente maduro-temprano, no como infraestructura de producción hardened equivalente a L1.
Capa 3: Bitcoin L1 (M > $2,000 sin canal directo; M > $50,000 siempre)
Transacción on-chain desde hardware wallet o cold storage. Seguridad máxima, latencia de 10–60 min para 1-6 confirmaciones. Es el único mecanismo que elimina completamente todos los vectores de ataque de Lightning.
Cómo resuelve cada riesgo
| Riesgo |
Mitigación en THPS |
Capa(s) donde aplica |
| Channel jamming |
Para M < $200 (Capa 1): el valor del HTLC es menor que el costo del ataque sostenido; HTLC endorsement reduce el impacto. Para M > $200 (Capa 2/3): Ark y L1 no usan HTLCs en tránsito multi-hop, eliminando el vector. |
L1 (Capa 1), Ark (Capa 2), L1 (Capa 3) |
| Replacement cycling |
Para Capa 1: el valor bajo del HTLC hace el ataque económicamente irracional; rebroadcasting + fee escalation como defensa activa. Para Capa 2 (Ark): las VTXOs no se liquidan vía HTLC multi-hop, el vector no aplica en el mismo modelo. Para Capa 3 (L1): el ataque apunta a HTLCs, no a transacciones simples, el vector no aplica. |
Reduce exposición en L1; elimina en Ark y L1 |
| Watchtower / online |
Capa 1: watchtowers redundantes (altruista + comercial); el valor en Capa 1 es bajo, el riesgo máximo es limitado. Capa 2 (Ark): las VTXOs no dependen del modelo de penalización de Lightning; el usuario puede recuperar fondos on-chain sin watchtower. Capa 3 (L1): sin dependencia de estar online post-confirmación. |
Reducido en L1; eliminado en Ark y L1 |
| Privacidad / probing |
Capa 1: BOLT12 con blinded paths oculta identidad del receptor. Trampoline routing reduce el footprint de gossip del nodo. PTLCs (cuando estén disponibles) eliminarán la correlación de hashes. Capa 2 (Ark): pagos off-chain dentro de rondas tienen mejor privacidad estructural que routing multi-hop. |
Mejorado en L1; estructuralmente mejor en Ark |
| LSP / custodia |
Arquitectura exige LSP no-custodial en Capa 1. Para montos que suben a Capa 2/3, se evita el routing mediante LSP único. La hot wallet en Capa 1 contiene solo el monto de gasto diario. |
Mitigado en L1 por diseño |
| Capacidad / alto valor |
El motor de decisión derivaba proactivamente a Ark o L1 antes de que el monto supere la zona de alta tasa de fallo de Lightning (>$200–$2,000 sin canal directo). MPP se usa solo dentro del rango donde la probabilidad de éxito es razonablemente alta. |
Ark y L1 eliminan el problema estructuralmente |
Causas sin mitigación completa en este stack:
- El jamming en Capa 1 no está completamente resuelto porque upfront fees aún no están en producción. La solución parcial (HTLC endorsement + montos bajos) es suficiente para micro-transacciones pero no para un routing node de alto volumen.
- La correlación de pagos (HTLC hash) no se resuelve hasta que PTLCs estén desplegados. En el ínterin, BOLT12 mejora la privacidad del receptor pero no la correlación inter-hop.
- El trust en el ASP de Ark no se elimina completamente sin covenants (soft fork pendiente). Es un trade-off explícito de la Capa 2.
Aplicación a los casos de uso
Caso 1: Compra de una lata de Coca-Cola (~$2)
Motor de decisión → Capa 1 (Lightning)
- M = $2 << umbral_micro ($200) → Lightning automático
- El wallet del usuario tiene un canal con su LSP no-custodial con $50–$100 de liquidez saliente (suficiente para esta compra y las siguientes sin abrir nuevo canal)
- El merchant usa BOLT12: el usuario escanea un QR estático y el wallet negocia automáticamente un invoice único via blinded path
- El HTLC de $2 se resuelve en <500ms
- Costo de jamming o cycling para un HTLC de $2: el atacante necesitaría mantener el ataque por múltiples bloques; el costo de las transacciones de reemplazo supera el valor del HTLC de inmediato. El attack surface es trivial.
- Comisión: ~1–5 sats (~$0.0001–$0.0005). Economicamente óptimo.
- ¿Se reintroduce el problema original (costo on-chain inviable)? No. El pago es completamente off-chain. No hay transacción on-chain asociada a esta compra individual.
Caso 2: Transferencia de 1 BTC (~$65,000 en agosto 2026)
Motor de decisión → Capa 3 (L1)
- M = ~$65,000 >> umbral_alto ($50,000) → L1 automático, independientemente de si existe canal directo
- El wallet inicia una transacción on-chain desde la hot wallet hacia la dirección destino (o hacia cold storage)
- Feerate estimado: 2–10 sat/vbyte, costo de transacción ~$1–$5 (despreciable sobre $65,000)
- Confirmación: 1 bloque (~10 min) para alta seguridad; 3–6 bloques para seguridad estándar
¿Por qué no Lightning para este caso?
- La red pública no puede rutear 1 BTC con probabilidad aceptable (no existen rutas multi-hop con suficiente liquidez; el canal promedio es 0.14 BTC)
- El riesgo de replacement cycling para un HTLC de $65,000 es económicamente significativo para un atacante sofisticado
- Mantener $65,000 en una hot wallet Lightning implica exposición continua a los vectores de ataque de Capa 1 durante toda la vida del canal
¿Por qué no Ark para este caso?
Ark en 2026 es una plataforma de adopción temprana con trust en el ASP. Para una transferencia de este valor, la garantía de seguridad de L1 es la única opciones prudente. Si el monto fuera $5,000–$10,000 y el usuario requiriera velocidad, Ark sería una alternativa intermedia viable con trust explícito en el ASP.
Limitaciones y trabajo futuro
Limitaciones actuales de THPS:
- La Capa 2 (Ark) es experimental en producción. Bark y Arkade existen en mainnet pero con volumen bajo, ASPs centralizados, y especificaciones aún en evolución. El THPS trata Ark como fallback mejorado, no como capa principal.
- PTLCs ausentes: la privacidad de pagos en Capa 1 sigue siendo incompleta. La correlación de payment hashes entre hops es un vector real hasta que PTLCs se desplieguen. No hay fecha estimada.
- LN-Symmetry (Eltoo) no activado: el riesgo de watchtower para Capa 1 no desaparece hasta que el modelo de penalización sea reemplazado. Requiere BIP446/BIP448 y el proceso de soft fork completo.
- Upfront fees sin desplegar: la mitigación definitiva para channel jamming (hacer costoso el ataque) sigue siendo experimental. HTLC endorsement reduce el impacto pero no lo elimina.
- Interoperabilidad Ark-Lightning: la conexión entre Capa 1 y Capa 2 (submarine swaps o integración directa) añade complejidad y un hop de confianza adicional. En 2026, wallets como Bark tienen integración Lightning nativa, pero no todos los wallets del ecosistema la soportan.
Trabajo futuro que cambiaría el stack:
| Desarrollo |
Impacto en THPS |
| PTLCs en producción |
Elimina correlación de hashes en Capa 1; mejora privacidad drásticamente |
| LN-Symmetry (soft fork activado) |
Simplifica watchtowers en Capa 1; habilita channel factories y reduce riesgo de backup |
| Ark con covenants (soft fork) |
Elimina trust en ASP; sube el umbral del THPS que envía a Capa 2 |
| Upfront/hold fees en producción |
Hace el jamming en Capa 1 económicamente irracional incluso para montos medios |
| Splicing generalizado |
Reduce la necesidad de cambiar de canal frecuentemente; mejora capital efficiency en Capa 1 |
La arquitectura propuesta es viable hoy con componentes existentes en producción o en adopción temprana verificada. Su valor no está en ningún componente individual (todos conocidos), sino en el motor de decisión automático que selecciona la capa correcta sin requerir conocimiento técnico del usuario, cubriendo los dos extremos del problema: la Coca-Cola y la transferencia de alto valor.
