-
La recuperación de los fondos no elimina las pérdidas derivadas de una interrupción del servicio.
-
El caso muestra que sumar participantes a una federación no garantiza una mayor seguridad.
El hack de Liquid dejó una pregunta que va más allá de la vulnerabilidad que permitió crear L-BTC sin respaldo: ¿quién responde cuando falla un sistema vinculado a Bitcoin que promete mantener sus activos respaldados 1:1? El incidente también pone bajo la lupa los controles de retiro, la centralización de la infraestructura y los riesgos de combinar privacidad criptográfica con mecanismos de seguridad insuficientes.
Liquid, una cadena lateral federada desarrollada por Blockstream, sufrió un ataque que permitió acuñar aproximadamente 4.000 L-BTC y utilizarlos para retirar cerca de 4.000 BTC de la reserva que respalda el sistema. El incidente no comprometió Bitcoin ni las claves de los miembros de la federación.
El problema estuvo en una vulnerabilidad de Liquid que permitió que activos creados de forma indebida superaran los controles necesarios para su retiro. Los hackers éticos posteriormente indicaron que devolverían los fondos y, según la última actualización incluida en el análisis, hackers de sombrero blanco habían recuperado 3.400 BTC, reteniendo 598,5 BTC que podría ser una recompensa autoasignada, como explicó CriptoNoticias.
¿Quién responde cuando los fondos no están disponibles?
Ante la situación narrada anteriormente, aparece el principal debate: la responsabilidad. Neha Narula, directora de la Digital Currency Initiative del MIT Media Lab e investigadora especializada en sistemas distribuidos, plantea dudas sobre quién debería responder si los usuarios no reciben una compensación completa. Entre las posibilidades menciona a los miembros de la federación, Blockstream o incluso a servicios regulados que permitan operar con L-BTC.
La cuestión no depende únicamente de si los fondos son recuperados. Una interrupción también impide que los usuarios dispongan de sus activos o generar pérdidas para quienes necesitaban operar durante ese período. El caso, por tanto, obliga a revisar qué garantías entiende que recibe un usuario cuando utiliza una infraestructura que asegura mantener sus activos respaldados por BTC.
Las consecuencias del incidente también ponen el foco en la estructura que lo sostiene. Liquid depende de una federación de 15 participantes, con 11 firmas necesarias para mover los BTC que respaldan los L-BTC. En este sentido, la analista asegura que aumentar drásticamente ese número no habría solucionado este ataque, porque la vulnerabilidad estaba en la lógica del sistema.
La observación cuestiona la idea de que sumar participantes sea suficiente para elevar la seguridad: también importa dónde están concentrados el código, las reglas de validación y los mecanismos que autorizan los retiros.
El incidente también reabre el debate sobre privacidad y seguridad. Liquid utiliza transacciones confidenciales que ocultan los montos, pero necesitan pruebas criptográficas para demostrar que las operaciones son válidas y que no se crean activos de la nada. La privacidad no debería depender únicamente de esas garantías: necesita controles adicionales, como restricciones de retiro y mecanismos capaces de detectar operaciones anómalas.
