El parche que quiso arreglar una falla y terminó causando el hackeo de 4.000 BTC
Un parche de 2026 pensado para corregir un error de 2018 abrió la puerta real al robo de 4.000 BTC en Liquid: la corrección fue la falla.
Steven Roose, ex ingeniero del equipo de Liquid en Blockstream y actual director ejecutivo de Second, publicó un análisis técnico que reconstruye, transacción por transacción, cómo un atacante logró inflar casi 4.000 bitcoin (BTC) en la red Liquid el pasado 6 de septiembre.
Su conclusión central contradice la lectura más aceptada del incidente: la criptografía de las transacciones confidenciales de Liquid nunca falló. Lo que falló fue una decisión de ingeniería tomada ocho años antes, y el intento fallido de corregirla apenas días antes del robo.
El hallazgo tiene una particularidad incómoda para cualquier equipo que mantenga infraestructura crítica: el código que debía cerrar la vulnerabilidad fue, en la práctica, el que la abrió. Esto desplaza el eje de la discusión, centrada hasta ahora en la negociación con los atacantes y la devolución parcial de fondos tras el robo de 4.000 bitcoin reportado inicialmente, hacia una pregunta más incómoda sobre cómo se gestionan las correcciones de seguridad bajo presión de tiempo en sistemas que custodian miles de millones de dólares.
Vale la pena detenerse en el mecanismo, porque no es un error exótico ni depende de romper ninguna prueba criptográfica. Es un problema de diseño de una caché, algo que cualquier sistema de verificación de firmas o pruebas usa para evitar repetir cálculos costosos. Y es precisamente ahí, en la optimización de rendimiento, donde se coló el error que permitió imprimir dinero, según reconstruye el análisis de Roose.
$BTC #newscrypto
Un parche de 2026 pensado para corregir un error de 2018 abrió la puerta real al robo de 4.000 BTC en Liquid: la corrección fue la falla.
Steven Roose, ex ingeniero del equipo de Liquid en Blockstream y actual director ejecutivo de Second, publicó un análisis técnico que reconstruye, transacción por transacción, cómo un atacante logró inflar casi 4.000 bitcoin (BTC) en la red Liquid el pasado 6 de septiembre.
Su conclusión central contradice la lectura más aceptada del incidente: la criptografía de las transacciones confidenciales de Liquid nunca falló. Lo que falló fue una decisión de ingeniería tomada ocho años antes, y el intento fallido de corregirla apenas días antes del robo.
El hallazgo tiene una particularidad incómoda para cualquier equipo que mantenga infraestructura crítica: el código que debía cerrar la vulnerabilidad fue, en la práctica, el que la abrió. Esto desplaza el eje de la discusión, centrada hasta ahora en la negociación con los atacantes y la devolución parcial de fondos tras el robo de 4.000 bitcoin reportado inicialmente, hacia una pregunta más incómoda sobre cómo se gestionan las correcciones de seguridad bajo presión de tiempo en sistemas que custodian miles de millones de dólares.
Vale la pena detenerse en el mecanismo, porque no es un error exótico ni depende de romper ninguna prueba criptográfica. Es un problema de diseño de una caché, algo que cualquier sistema de verificación de firmas o pruebas usa para evitar repetir cálculos costosos. Y es precisamente ahí, en la optimización de rendimiento, donde se coló el error que permitió imprimir dinero, según reconstruye el análisis de Roose.
$BTC #newscrypto
