Los canales de Lightning que no cerraron antes del fork BIP-110 siguen en riesgo

Luego de la bifurcación de Bitcoin provocada por la activación de BIP-110, cualquier canal de Lightning Network (LN) que siguiera abierto en el momento de la división corre riesgo de robo, porque el nodo que lo administra queda ciego a todo lo que ocurra en la cadena que no sigue y no puede notar si su contraparte usa ahí una versión vieja del canal para quedarse con fondos que ya no le pertenecen.

El problema tiene un origen puntual: la red Lightning Network no distingue entre las dos cadenas porque ambas comparten el mismo campo que identifica a cada cadena conocido comochain_hash, el hash del bloque génesis, idéntico en los dos lados de la división.

En Lightning Network, cada pago revoca el estado anterior del canal, es decir, la última transferencia que actualiza los saldos de cada una de las partes. Asimismo, cada parte intercambia un secreto que, si alguna intenta publicar esa versión vieja, le permite a la otra reclamar todos los fondos del canal mediante una transacción de penalización.

Ese mecanismo solo funciona si el nodo afectado ve la transacción a tiempo, y ahí aparece el problema de la división: cada nodo de Lightning Network sigue una sola cadena, la que su software de Bitcoin considera válida, y no puede detectar nada de lo que ocurra en la otra.

Por ejemplo, si dos usuarios abrieron un canal antes del 8 de agosto y cada uno terminó siguiendo una cadena distinta, cualquiera de los dos puede publicar en la cadena que el otro no vigila un estado ya revocado del canal, sin que la víctima llegue a verlo ni pueda castigarlo a tiempo.

La congelación de la cadena de BIP-110 no elimina ese riesgo, sino que lo posterga de forma indefinida. Cada estado de canal que un usuario firmó y luego revocó sigue siendo, técnicamente, una transacción válida en esa rama. Si esa cadena alguna vez recupera un ritmo normal de bloques, esos estados revocados volverían a ser publicables como el primer día, y quien estuviera vigilando esa cadena en ese momento podría quedarse con los fondos de quien no lo estuviera.

La amenaza de que un canal viejo vuelva a ser publicable no es una hipótesis. Start9, un proveedor de infraestructura para correr nodos propios de Bitcoin y Lightning Network, cerró preventivamente todos sus canales antes del bloque 961.632. La compañía documentó el mecanismo de riesgo paso a paso y recomendó a cualquier operador con un canal abierto cerrarlo cuanto antes, en lugar de esperar a ver cómo se resolvía la división.

¿Cómo saber si tu canal quedó expuesto?

Para diagnosticar si un nodo quedó atrapado en la cadena de BIP-110, hay que verificar dos comandos de la consola del cliente de Bitcoin: getblockchaininfo, que muestra la altura del último bloque validado, y getdeploymentinfo, que indica el estado de la regla reduced_data que activa BIP-110. Si la altura no avanza o la marca de tiempo del último bloque tiene varias horas de atraso, el nodo probablemente sigue conectado a la rama minoritaria.

La trampa es que un nodo estancado no se ve roto. Sigue reportando que está sincronizado, mantiene sus conexiones con otros pares y no muestra ningún error visible; simplemente deja de recibir bloques nuevos. Por esto la señal confiable no es el estado de sincronización que muestra el software, sino si la altura de bloque sigue creciendo con el paso de las horas.

¿Qué hacer si tu canal sigue abierto?

La opción más segura es cerrar el canal ya, sin esperar a que la contraparte esté conectada. Este tipo de cierre se llama cierre forzoso: lo puede activar una sola de las dos partes, sin necesitar la colaboración de la otra.

Cerrar de esta manera no tiene riesgo de perder fondos por penalización. Cada vez que dos personas usan un canal para pagarse, acuerdan una nueva versión del canal y descartan la anterior; si alguien intenta usar esa versión vieja más adelante, la otra parte puede reclamar todo el dinero del canal como castigo. Como el cierre forzoso usa la versión más reciente y no una vieja, no hay nada que la contraparte pueda castigar.

Después de un cierre forzoso hay que esperar un tiempo antes de poder retirar los fondos, un plazo que cada canal define al abrirse y que suele ir de un día a dos semanas (entre 144 y 2.016 bloques). Quien quiera consultarlo en su propio nodo puede hacerlo con listchannels en LND o listpeerchannels en Core Lightning, los dos programas más usados para correr un nodo de Lightning Network.

Para quienes no puedan cerrar el canal, por ejemplo porque la aplicación que usan no lo permite, existe una alternativa parcial: un servicio externo llamado watchtower, que vigila una cadena en nombre del usuario y reacciona automáticamente si detecta que la contraparte intenta usar una versión vieja del canal.

El problema es que, en una cadena casi sin actividad como la de BIP-110, la watchtower firma su reacción con una comisión fija desde el momento en que se configuró, y no hay forma de subirla si los pocos bloques que se minan ahí se llenan y las comisiones suben. Eso puede dejar esa reacción sin confirmar a tiempo.

Adicionalmente, la exposición cambia según el tipo de usuario:

• Quien opera su propio nodo con LND o Core Lightning puede aplicar todo lo anterior directamente.

• Quien usa una aplicación no custodial que depende de un único proveedor de liquidez, como Phoenix, tiene en los hechos un canal más para cerrar, con ese proveedor como única contraparte.

• Quien usa una wallet custodial, es decir, una wallet cuyo proveedor guarda los fondos en su nombre, no tiene ningún canal propio que cerrar. Pero tampoco decide en qué cadena queda reconocido su saldo después de una división: esa decisión la toma el proveedor del servicio.

La cadena de BIP-110 procesó dos bloques y no avanzó más

La cadena que impuso las reglas de BIP-110 produjo apenas dos bloques tras la ruptura, ocurrida el 8 de agosto en el bloque 961.632, y desde entonces no sumó ninguno más.

El repositorio de BIP-110 marcó a esta propuesta como cerrada el 9 de agosto, un día después del quiebre, y le atribuyó ese cierre a la división de la red y a la falta de nuevos bloques en la rama disidente.

Mientras tanto, el desarrollador Luke Dashjr, principal impulsor de BIP-110 y a quien solicitaron remover como editor de propuestas de mejoras de Bitcoin (BIP), consideró que no fracasó, aunque la producción de bloques en esa cadena se mantiene en cero desde entonces, como reportó CriptoNoticias.

El episodio deja una lección que trasciende a esta propuesta puntual: en cualquier división de cadena futura, cerrar los canales antes del quiebre sigue siendo la única estrategia que no le cuesta nada al usuario. Un canal de Lightning cerrado a tiempo se reduce a un simple pago que ambas cadenas heredan por igual; un canal que sigue abierto, en cambio, se convierte en una responsabilidad indefinida que no desaparece aunque la cadena minoritaria deje de producir bloques.