12 de septiembre de 2026
El Manual del Gato Ninja para Perder Millones (Sin Escribir Mal Código)
En agosto de 2026, el bot P2P de Lightning más antiguo del ecosistema dijo basta. Un mes después, Liquid perdió casi 4.000 BTC en una tarde. Ninguno de los dos episodios fue un “hack” en el sentido clásico: no hubo una primitiva criptográfica rota ni una clave mágica. Hubo algo más aburrido —y mucho más letal—: un parche que arregló el código sin avisarle a nadie, y alertas que se perdieron en la burocracia.
Este es el manual del gato ninja para perder millones sin escribir mal código: la autopsia de dos desastres de comunicación en el ecosistema de código abierto, contada paso a paso.
Un mes, dos tragedias (y cero hacks mágicos)
El 10 de agosto de 2026, LNp2pBot —el mercado P2P de Bitcoin sobre Lightning que operaba en Telegram desde hacía casi cinco años, sin KYC y sin custodia— anunció su cierre indefinido. Su creador, el desarrollador venezolano Francisco Calderón (Grunch), venía absorbiendo ataques constantes; en las últimas semanas, un “ejército de script kiddies armados con IA” volvió imposible sostener el servicio.
Un mes después, el 6 de septiembre, la red Liquid de Blockstream vivió el mayor incidente cripto del año: aproximadamente 3.998 L-BTC (~USD 318 millones) salieron de la billetera de la federación a través del peg-out, acuñadas sin respaldo por una vulnerabilidad en el código de Elements.
Lo peor no fue el robo: fue que el ladrón usó la puerta principal, porque nadie avisó que venía sin seguro.
Paso 1: confiar ciegamente en una librería antigua
La primera tragedia no estaba en el código del bot. Estaba en una dependencia: invoices, la librería BOLT11 de la que depende buena parte del ecosistema Lightning JS. Creada por Alex Bosworth a fines de enero de 2020, el defecto vivió ahí durante 2.380 días (2.381 contando el día inicial) hasta el parche del 7 de agosto de 2026.
Paso 2: una factura, dos interpretaciones
El fallo era una ambigüedad de parsing: si una factura (payment request) contenía el payment hash dos veces, el parser de invoices se quedaba con el último, mientras que el nodo de Lightning usaba el primero. La misma cadena de texto, dos IDs distintos: el bot creía que estaba siguiendo un pago, y el nodo liquidaba otro.
Paso 3: pagar dos veces por el mismo recibo
Con esa divergencia, un atacante podía enviar una factura manipulada y hacer que el sistema pagara dos veces por el mismo recibo. La diferencia se convierte en dinero gratis: el bot sigue el rastro de un pago, el nodo liquida otro, y nadie ve una alarma.
Paso 4: la hemorragia silenciosa
En cada ronda de transacciones, el bot se comía la diferencia. No hubo un único golpe: fue una hemorragia silenciosa e incesante, durante días, sin logs que gritaran, sin métricas que se salieran de rango. El sistema “funcionaba”.
Paso 5: arreglar el error y esconderlo en la burocracia
El 7 de agosto de 2026 salió el parche. El commit que cambió la librería para siempre fue escueto: “use first payment hash and require node v22”, publicado como versión mayor (v6.0.0). El único anuncio fue el salto de versión y el nuevo requisito de Node 22. Ni una palabra sobre el pago duplicado. Sin CVE. Sin advisory.
El fix era correcto y salió rápido. La comunicación, en cambio, lo convirtió en una trampa: tres días después, los atacantes ya operaban con la técnica que el parche describía en voz baja —y nadie lo había leído.
Para cualquier desarrollador, migrar de Node 20 a Node 22 es una tarea burocrática que se deja “para cuando las cosas se calmen”. La única señal pública del parche incitaba a esperar, no a actualizar de urgencia. La bomba de tiempo quedó armada.
No es un caso aislado: Liquid y los 600 BTC
El 6 de septiembre, la vulnerabilidad de Liquid no fue un descuido antiguo: fue un parche incorrecto. El commit c26d719 buscaba atar la clave de caché de la verificación de rangeproofs a todo el contexto criptográfico, pero concatenó los campos variables sin delimitar sus longitudes: moviendo bytes de un campo a otro, dos entradas distintas producen la misma clave de caché. Con la caché “cebada” a propósito, una prueba inválida pasó como válida y se acuñaron L-BTC sin respaldo.
El atacante devolvió 3.400 BTC al día siguiente y retuvo 598,5 BTC (~USD 47 millones) como supuesta recompensa. En paralelo, un debate público sacudió al ecosistema: el Bitcoin Red Team afirmó haber advertido a Blockstream antes del incidente; la empresa lo negó. Lo que no se discute es el costo de no comunicarse con claridad: astronómico.
(Nota de verificación: en la matriz, la celda de “Costo” de Inp2pBot aparece parcialmente cubierta por la ilustración; el valor se conserva aquí como robo de fondos, sin cifra pública confirmada.)
El mito mortal: “simplemente leé los changelogs”
En una ventana de tres días donde los atacantes ya están operando activamente, una revisión semanal de repositorios es una batalla perdida. El humano no escala: nadie audita cada release de cada dependencia, todos los días, en cada proyecto. Y este caso lo prueba: el parche estaba disponible, era público y era correcto — y aun así llegó tarde.
Paso 6: que los bots vigilen a los bots
La respuesta que propone este manual es monitoreo impulsado por eventos: cuando cae una nueva versión de una dependencia crítica, un agente compara el código al instante y responde una sola pregunta — ¿esto arregla algo de seguridad en silencio? Si la respuesta es sí, lo que sigue no es un changelog: es un aviso, un CVE y ruido suficiente para que el resto del ecosistema reaccione antes de que los atacantes lo hagan.
Un parche de seguridad no puede viajar como pasajero clandestino en un cambio de infraestructura.
Cypherpunks escriben código, pero alguien debe leer los diffs
El código de estas dos historias era abierto. El problema es que la comunicación no lo era. Un cambio de una línea puede sostener una economía entera; esconderlo entre “Breaking Changes” no es una decisión técnica, es una decisión de riesgo.
La próxima puerta principal quedará abierta en algún repo, en algún release, en algún commit sin título. La diferencia entre leerlo a tiempo o no puede valer cientos de millones.
Fuentes verificadas
alexbosworth/invoices— commitb30a012cdel 7-ago-2026 (“use first payment hash and require node v22”), publicado como v6.0.0; sin CVE ni advisory de seguridad en el repositorio.- Nota forense de Francisco Calderón (negrunch) sobre LNp2pBot: el bug explotado estaba en la dependencia
invoicesy el fix llevaba 3 días publicado (Nostr, septiembre de 2026). - Cointelegraph ES — LNP2P cerró operaciones tras sufrir ataques constantes (13-ago-2026) · Observatorio Blockchain — La venezolana lnp2pBot cierra ante un ejército de atacantes con IA (11-ago-2026).
- CertiK — Liquid Network Incident Analysis: colisión de clave de caché en la verificación de rangeproofs introducida por el commit
c26d719; 3.998,5 L-BTC afectados (~USD 318,7 M). - The Hacker News — Liquid Hackers Return 3400 Bitcoin Taken via Elements · Chainalysis / Decrypt — cobertura del exploit de USD 320 M.
- Bitcoin.com News — Bitcoin Red Team Claims Blockstream Ignored Warnings Before Hack (debate público, negado por Blockstream).
- Mostro (mostro.network) — referencia del modelo de agentes y eventos sobre Nostr para monitoreo continuo.