El estándar de facturas BOLT11 ahora exige exactamente un hash de pago y un secreto de pago. La ausencia o repetición de cualquiera de estos campos debe provocar el fallo del pago. Los desarrolladores de Lightning introdujeron el cambio el 19 de octubre, después de que un ataque denunciado mostrara cómo unos analizadores de facturas en conflicto podían hacer que retiros de Bitcoin ya completados parecieran impagados. El informe del incidente no incluía una fecha ni una cifra de pérdidas.
Por qué es importante
La vulnerabilidad tenía su origen en componentes de software que interpretaban de forma distinta la misma solicitud de pago firmada. Un analizador podía seleccionar el primer campo de hash de pago, mientras otro seleccionaba el último. Por tanto, un servicio podía registrar un retiro con un hash mientras su nodo ejecutaba el pago con otro, lo que llevaba al sistema contable a tratar un retiro completado como impagado y podía provocar otro desembolso.
La nueva regla abarca tanto los hashes de pago como los secretos de pago. Las implementaciones deben contabilizar las apariciones de los campos, incluidos los valores idénticos repetidos, en lugar de agruparlos en una sola entrada. Una factura con dos hashes distintos y otra que repita el mismo hash son inválidas según la especificación actualizada.
Impacto en el mercado
El impacto inmediato es operativo, no una señal directa sobre el precio de Bitcoin. Los operadores de pagos deben rechazar las facturas ambiguas y asegurarse de que la contabilidad de retiros siga el mismo hash de pago utilizado por el nodo. El cambio también pone de relieve un riesgo más amplio de la infraestructura cripto: los datos firmados aún pueden provocar fallos cuando distintos programas interpretan sus campos de manera incoherente.
El software de nodos lnd incorporó el rechazo de hashes duplicados el 23 de septiembre. Sus versiones v0.20.5-beta y v0.21.4-beta incluyen esa corrección. Una propuesta independiente sobre la validación de secretos de pago y otras comprobaciones del decodificador seguía abierta el 27 de octubre, y una decodificación correcta por sí sola no garantiza que el pago llegue a completarse.
Preguntas frecuentes
-
¿Qué cambió en el estándar de facturas BOLT11?
BOLT11 exige ahora exactamente un hash de pago y un secreto de pago. La ausencia o repetición de campos debe provocar el rechazo de la factura.
-
¿Cómo podían unos analizadores en conflicto hacer que un retiro de Bitcoin pareciera impagado?
Un analizador podía usar el primer hash de pago y otro, el último. Así, un servicio podía registrar un hash distinto del utilizado por su nodo para ejecutar el pago.
-
¿Qué tipo de ataque provocó el cambio de las reglas de BOLT11?
Un ataque denunciado contra un bot de Telegram entre pares aprovechó las diferencias entre bibliotecas de facturas. Esto hizo que retiros de Bitcoin completados parecieran impagados y abrió la posibilidad de realizar nuevos desembolsos.
-
¿Qué versiones de lnd incluyen el rechazo de hashes duplicados?
La corrección para rechazar hashes duplicados se incorporó el 23 de septiembre y está incluida en lnd v0.20.5-beta y v0.21.4-beta.
-
¿Ya están completas las comprobaciones de secretos de pago en lnd?
No. Una propuesta independiente de lnd sobre la validación de secretos de pago y otras comprobaciones del decodificador seguía abierta el 27 de octubre.
CoinDesk
CZ Binance
TheBlock
WatcherGuru
Lookonchain