La red Liquid, una sidechain federada de Bitcoin desarrollada y mantenida por Blockstream desde su lanzamiento en 2018 y utilizada por exchanges y firmas de trading para liquidaciones más rápidas entre plataformas de Bitcoin, hizo público un incidente de seguridad después de que aproximadamente 4,000 BTC —unos 320 millones de dólares en ese momento— salieran de una billetera controlada por su federación. Según Liquid, la retirada se ejecutó utilizando la Peg-Out Authorization Key (PAK) de SideSwap, pero la red insiste en que ni esta clave ni ninguna de sus otras claves de autorización fueron comprometidas. Liquid describió a los receptores como supuestos hackers de sombrero blanco, y Blockstream ha intentado contactarlos mediante mensajes firmados registrados en Bitcoin.

Como respuesta, la red desactivó sus nodos puente, lo que impide que se envíen nuevas transacciones. También se pidió a los exchanges que suspendieran los depósitos y retiros de L-BTC mientras los miembros de la federación investigan. Las implicaciones de esa pausa son significativas para los usuarios de la sidechain: dado que el L-BTC se mueve entre los exchanges participantes de forma mucho más rápida y barata que el Bitcoin onchain, una suspensión prolongada de los peg-outs y del soporte de los exchanges afecta directamente el flujo de liquidación del que dependen esas firmas.

SideSwap vincula el L-BTC a un error de Elements

Una declaración posterior de SideSwap describió cómo su servicio de peg-out recibió el L-BTC y liberó el Bitcoin correspondiente. Sin embargo, Blockstream aún no ha publicado un análisis técnico post mortem completo que identifique la vulnerabilidad y confirme cada etapa de este relato, por lo que la explicación de SideSwap debe considerarse preliminar.

Cómo unas claves seguras pudieron liberar el Bitcoin de todos modos

El diseño de Liquid separa la validez de un activo de la autorización de su destino. Según la documentación de Blockstream sobre L-BTC, cada unidad debe estar respaldada por una cantidad equivalente de Bitcoin en poder de la federación. Un peg-out normal quema el L-BTC antes de liberar el BTC correspondiente.

Una PAK cumple una función más acotada: autoriza la dirección de Bitcoin que puede recibir un peg-out. No es el mecanismo que determina si el L-BTC redimido fue emitido legítimamente en primer lugar.

El esquema de multifirma de la federación requiere que 11 de los 15 funcionarios autoricen el gasto desde la billetera de Bitcoin. Si se confirma el relato de SideSwap, esas firmas pudieron ser criptográficamente válidas aunque un fallo de validación anterior permitiera que L-BTC creados indebidamente llegaran al proceso de peg-out. Por lo tanto, una PAK segura no habría impedido una retirada si la red ya había aceptado como válido el L-BTC en disputa: la autorización podía aprobar el destino previsto mientras el proceso de validación de activos no identificaba un L-BTC que nunca debió existir.

Si se confirma el relato de SideSwap, los controles de oferta fallaron al no rechazar L-BTC creados sin un depósito de Bitcoin correspondiente. Eso explicaría cómo unas claves de autorización seguras y firmas federativas válidas pudieron, aun así, producir la pérdida de reservas reales.

Bitcoin en sí no fue comprometido

El incidente afecta a Liquid, una sidechain federada construida con Elements, la base de código de sidechain de código abierto que también sustenta otras implementaciones basadas en Liquid. No indica que las reglas de consenso de Bitcoin fueran vulneradas ni que un atacante eludiera la seguridad de la propia red de Bitcoin. Bitcoin simplemente procesó una transacción con las firmas necesarias para gastar desde la billetera de la federación. El aparente fallo ocurrió antes, dentro del sistema responsable de emitir, validar y redimir el L-BTC.

Llamar al evento un "hackeo de Bitcoin" oscurecería dónde ocurrió realmente el problema. El BTC transferido era real, pero la explicación preliminar de SideSwap apunta al software de la sidechain de Liquid y a sus controles de peg.

Los mensajes onchain muestran contacto, no recuperación

Mensajes adjuntos a transacciones de Bitcoin muestran un intercambio entre Blockstream y la dirección que controla los fondos retirados. Blockstream proporcionó una dirección de devolución, y el receptor indicó más tarde que el Bitcoin sería devuelto una vez corregida la vulnerabilidad. Los lectores pueden seguir las transacciones relacionadas con la dirección de devolución indicada en Mempool.

La comunicación es consistente con la afirmación del receptor de ser un sombrero blanco, pero no verifica la identidad ni las intenciones de la persona. Una promesa de devolver el Bitcoin no equivale a una recuperación completada: la confirmación requiere una transacción de devolución identificable y el reconocimiento de Liquid o Blockstream de que se recibieron los fondos esperados.

Liquid dice que otros activos no fueron afectados, pero el acceso se vio interrumpido

Liquid señaló que otros activos emitidos, incluidos USDT, DePix y activos del mundo real tokenizados, no fueron afectados por el incidente de seguridad. En este contexto, "no afectados" significa que Liquid no había identificado que esos activos fueran creados o retirados indebidamente.

Sin embargo, la interrupción operativa fue más amplia. La desactivación de los nodos puente pausó efectivamente la sidechain, mientras que los exchanges suspendieron o se preparaban para suspender las transferencias de L-BTC. Un activo puede permanecer intacto en el libro mayor mientras su propietario pierde temporalmente la capacidad de moverlo o redimirlo: la integridad del activo y su disponibilidad son riesgos distintos.

El caso Coldcard expuso una capa distinta de la seguridad de Bitcoin

El evento sigue a un incidente de seguridad de Bitcoin aparte que involucró dispositivos Coldcard afectados. Los casos no están relacionados, pero ilustran fallos en capas diferentes: el problema de Coldcard concernía al manejo de transacciones de la billetera, mientras que el relato preliminar de Liquid atañe a la validación y redención de un activo de sidechain respaldado por Bitcoin.

Lo que Liquid debe demostrar antes de reiniciarse

Restaurar el procesamiento de transacciones no resolvería todas las preguntas planteadas por la retirada. Antes de que los usuarios puedan evaluar de forma independiente un reinicio, Liquid debería proporcionar información suficiente para verificar lo siguiente:

• Un análisis técnico post mortem que identifique la vulnerabilidad de Elements.
• Las versiones de software afectadas y la corrección exacta aplicada.
• La confirmación de que el software corregido se desplegó en toda la infraestructura de los funcionarios.
• Una conciliación del L-BTC legítimo en circulación frente al Bitcoin en poder de la federación.
• La confirmación de si los aproximadamente 3,996 BTC fueron devueltos.
• Una explicación de por qué el proceso de peg-out aceptó el L-BTC en disputa.
• El aviso de que los nodos puente y el procesamiento normal de transacciones se han reanudado.
• La confirmación de los exchanges de que se restablecieron los depósitos y retiros de L-BTC.

Un parche de software abordaría la vulnerabilidad, pero por sí solo no demostraría que la contabilidad de Liquid quedó restaurada. Los usuarios también necesitan evidencia de que las reservas restantes de Bitcoin cubren todo el L-BTC legítimo que sigue en circulación.

Lo que Liquid todavía necesita explicar

La pregunta pendiente es por qué el L-BTC en disputa superó las verificaciones que precedieron a las firmas de la federación. Hasta que Blockstream identifique la vulnerabilidad, concilie el L-BTC legítimo en circulación con las reservas restantes y confirme si los aproximadamente 3,996 BTC fueron devueltos, el desenlace técnico y financiero del incidente no puede evaluarse de forma independiente.

Este artículo tiene fines informativos y no constituye asesoramiento financiero, legal ni de inversión.