Lightning Network endurece las reglas de BOLT11: las facturas solo podrán llevar un hash y un secreto de pago tras un ataque a retiros de bitcoin

La Lightning Network ajustó la especificación BOLT11, el estándar que define el formato de las facturas de pago de la red, para exigir que cada factura contenga exactamente un hash de pago y un secreto de pago. El cambio llega después de que se reportara un ataque que lograba que retiros de bitcoin ya liquidados aparecieran como impagos en los sistemas de algunos operadores. El riesgo de fondo es concreto: un servicio que cree que no pagó puede terminar pagando dos veces.

La modificación quedó incorporada en el repositorio de especificaciones de Lightning mediante un cambio fusionado en GitHub, y ya forma parte de la especificación vigente de BOLT11. El boletín técnico Bitcoin Optech también destacó la nueva regla en su edición del 23 de octubre.

Publicidad

Estabilidad respaldada en Bitcoin

Descubre Dollar on Chain →

Qué cambia en las facturas de Lightning Network

Una factura BOLT11 es la cadena de texto, o el código QR, que un usuario comparte para recibir un pago en Lightning, la red de segunda capa construida sobre Bitcoin para transacciones rápidas y de bajo costo. Dentro de esa cadena viajan varios campos. Dos de ellos son críticos: el hash de pago, que identifica el pago y permite comprobar que se completó, y el secreto de pago, un dato que protege al receptor frente a ciertos intentos de sondeo o interceptación.

Hasta ahora, la especificación no cerraba del todo la puerta a facturas con más de uno de esos campos. Esa ambigüedad es justamente la que habría aprovechado el ataque reportado. Si una billetera lee un hash de pago y el software contable del operador registra otro, ambos sistemas pueden discrepar sobre si el retiro se pagó o no.

Con la nueva redacción, una factura que traiga hashes o secretos duplicados deja de ser válida. El software que siga el estándar debe rechazarla en lugar de elegir uno de los valores por su cuenta.

Un ataque dirigido a los retiros

El escenario de mayor exposición son los servicios que procesan retiros por Lightning a gran escala: exchanges, billeteras custodiales y plataformas que pagan a usuarios de forma automática. En esos casos, el cliente entrega una factura y el servicio la paga desde su nodo.

Según la descripción del problema, el atacante podría entregar una factura manipulada de modo que el pago se ejecutara, pero el registro interno del operador lo mostrara como pendiente o fallido. Si el sistema reintenta el pago o el soporte lo reembolsa manualmente, el atacante cobraría más de una vez. No se han divulgado públicamente cifras de pérdidas asociadas a este vector.

Es un tipo de falla que no rompe la criptografía de Bitcoin ni de Lightning. Explota la distancia entre lo que hace el nodo y lo que interpreta la capa de contabilidad que lo rodea. Episodios recientes, como la falla crítica que corrigió la billetera Electrum, muestran que buena parte del riesgo práctico para los usuarios está en el software de aplicación y no en el protocolo base.

Lo que ya hicieron las implementaciones

En lnd, la implementación de Lightning desarrollada por Lightning Labs y una de las más usadas por empresas, se fusionó el rechazo de facturas con hashes duplicados. Los operadores que usen esta implementación pueden revisar las notas de las versiones v0.20.5-beta y v0.21.4-beta para verificar qué cambios aplican a su despliegue.

Además existe una propuesta separada en lnd vinculada al mismo frente, lo que sugiere que el trabajo de endurecimiento no está cerrado del todo.

Actualizar el nodo no basta por sí solo. El mensaje para los operadores es que deben auditar cómo su propio software registra los retiros: de dónde toma el hash de pago, cómo confirma que un pago se liquidó y qué ocurre cuando un pago queda en estado ambiguo. Un sistema de contabilidad que extraiga los datos de la factura con un analizador propio, en vez de usar la respuesta del nodo, podría seguir siendo vulnerable aunque el nodo esté al día.

Recomendaciones que se desprenden del cambio

• Actualizar la implementación de Lightning a una versión que rechace facturas con campos duplicados.
• Conciliar los retiros usando el resultado devuelto por el nodo, no una lectura independiente de la factura.
• Revisar la lógica de reintentos y reembolsos manuales, que es donde un pago mal registrado se convierte en pérdida.

Por qué importa para el uso de Lightning

La Lightning Network depende de que exchanges y billeteras la integren para mover bitcoin de forma barata. Cada incidente en la capa de retiros erosiona la confianza de esas empresas, que son las que concentran el volumen. Que la corrección haya llegado primero a la especificación y luego a las implementaciones indica un proceso de respuesta coordinado, aunque la responsabilidad final recae en cada operador.

El ajuste es pequeño en apariencia: una regla sobre cuántas veces puede aparecer un campo en una factura. Su alcance real se medirá en cuántos servicios revisen ahora sus sistemas internos antes de que alguien vuelva a probar suerte con el mismo truco.