-
LND modifica dos funciones internas para resistir reorganizaciones de cadena.
-
Antes, las reservas de monedas expiraban por tiempo o primera confirmación.
LND, la implementación más utilizada de la red Lightning, modificó la manera en que su wallet interna aparta monedas para pagos en curso. Esas reservas ya no dependen únicamente de un temporizador y pueden mantenerse activas hasta que la cadena confirme un número determinado de bloques.
Antes de entender la corrección, conviene aclarar qué hacen las dos piezas que se modificaron. Ninguna es visible para un usuario común, pero ambas sostienen operaciones cotidianas de la red Lightning.
- LeaseOutput: le dice a la wallet «aparta esta moneda y no la uses para nada más» mientras se prepara un pago o se abre un canal. Sin esa reserva, la misma moneda podría ofrecerse por error para dos operaciones a la vez.
- FundPsbt: construye una transacción parcialmente firmada (PSBT) seleccionando qué monedas disponibles se usarán para pagarla. Cuando arma esa transacción, también debe reservar las monedas elegidas hasta que el proceso termine.
Ambas funciones comparten el mismo problema de fondo: necesitan saber cuánto tiempo debe durar esa reserva para evitar que la moneda se reutilice antes de tiempo, o que quede bloqueada más de lo necesario.
El problema: una reserva medida en minutos, no en bloques
Hasta ahora, la reserva de una moneda terminaba por una de estas dos vías:
- Por tiempo: la wallet liberaba la moneda automáticamente al vencer un plazo fijo, sin importar si la transacción ya se había confirmado o no.
- Por primera confirmación: la wallet daba la reserva por cumplida en cuanto veía un solo bloque confirmando la transacción, y dejaba de vigilarla.
Ambos mecanismos ignoran algo central en Bitcoin: una confirmación no es garantía definitiva de nada. La cadena puede reorganizarse —es decir, descartar uno o varios bloques recientes y reemplazarlos por otros—, algo poco frecuente pero posible, en especial en redes con menos poder de cómputo dedicado a la minería.
El resultado eran dos fallas posibles:
- Si la transacción tardaba más de lo previsto en confirmarse, el temporizador vencía primero y la moneda quedaba libre para usarse en otro pago, generando un conflicto.
- Si la reserva se liberaba tras la primera confirmación y luego esa transacción se revertía por una reorganización, la wallet ya no tenía registro de que esa moneda seguía comprometida.
La corrección propuesta en el código de LND
La solución, publicada como una modificación al repositorio de código de LND, permite que tanto LeaseOutput como FundPsbt acepten un número de confirmaciones como condición para liberar la reserva, en lugar de depender solo del reloj.
El desarrollador ya no está limitado a un único mecanismo de expiración. Puede pedirle a la wallet que mantenga una moneda reservada hasta que la transacción acumule, por ejemplo, seis confirmaciones, sin importar cuánto tiempo tome llegar a ese número.
La reserva también puede liberarse de forma manual en cualquier momento, algo necesario cuando una operación se cancela o se abandona antes de completarse.
Por qué esto le importa especialmente a Lightning
En una wallet común, un error de este tipo suele traducirse en una selección de monedas fallida y un reintento manual, sin mayores consecuencias. En Lightning, el riesgo es más alto porque estas reservas suelen sostener la apertura o el cierre de canales de pago, que pueden permanecer activos durante meses.
Si el sistema de reservas falla justo en ese momento, las consecuencias posibles incluyen:
- Un canal que queda atascado sin poder completarse.
- Fondos temporalmente inaccesibles para el usuario.
- Una misma moneda reutilizada por error en dos operaciones distintas.
No es un riesgo hipotético. En 2025 se reveló una vulnerabilidad real relacionada con reorganizaciones de cadena en el cierre colaborativo de canales de LND. Un nodo olvidaba un canal apenas veía la primera confirmación de su cierre, perdiendo la capacidad de defenderse si esa transacción se revertía y un adversario publicaba un estado de canal revocado.
La corrección de aquel caso obligó a esperar un mínimo de seis confirmaciones antes de dar por definitivo un cierre de canal, siguiendo las recomendaciones del estándar BOLT5. La modificación actual en LeaseOutput y FundPsbt aplica esa misma filosofía a un problema distinto: la gestión de monedas reservadas, no el cierre de canales.
Cómo cambia el mecanismo en la práctica
La tabla siguiente resume la diferencia entre el comportamiento anterior y el actual:
| Aspecto | Antes | Ahora |
|---|---|---|
| Condición de expiración | Tiempo fijo o primera confirmación | Número de confirmaciones configurable |
| Comportamiento ante una reorganización | La reserva podía perderse | La reserva permanece activa |
| Liberación manual | Disponible | Sigue disponible |
| Configuración predeterminada | Por tiempo | Por tiempo (sin cambios) |
El punto más relevante para operadores de nodos es que el cambio es opcional. Nadie está obligado a modificar su configuración actual para seguir operando exactamente como antes. Entre quienes podrían adoptar el nuevo parámetro cuando lo necesiten están:
- Proveedores de servicios de apertura de canales.
- Exchanges con infraestructura Lightning propia.
- Herramientas de gestión de liquidez para operadores de nodos.
Esa decisión de diseño es coherente con una práctica habitual en el desarrollo de Bitcoin: introducir mejoras de seguridad sin imponer cambios de comportamiento a quienes no los solicitan explícitamente.
Un patrón que se repite en la infraestructura de Bitcoin
Lo ocurrido con LeaseOutput y FundPsbt no es un caso aislado. Es parte de una tendencia visible en distintas actualizaciones recientes de wallet y nodos: reemplazar reglas basadas en tiempo o en eventos únicos por reglas basadas en profundidad de confirmación como medida de finalidad económica.
Esa lógica es, en esencia, una expresión práctica de cómo funciona realmente la seguridad en Bitcoin: no existe un momento exacto en el que una transacción se vuelve «segura», sino una probabilidad creciente de irreversibilidad a medida que se acumulan bloques.
El límite de esta mejora también merece mencionarse. Ningún número de confirmaciones elimina por completo el riesgo de reorganización; solo lo reduce a niveles considerados aceptables según el contexto de uso. Seis confirmaciones no ofrecen la misma garantía en una red con poco poder de cómputo que en Bitcoin.
Lo que este cambio deja claro es que gestionar una wallet de Lightning no es solo llevar la cuenta de saldos. Es sincronizar, bloque a bloque, la certeza interna del software con la certeza real que ofrece la cadena, sin atajos de reloj que terminen traicionando esa promesa.
