¿Qué pasará con la red Lightning si BIP-110 causa un fork de Bitcoin?

Bitcoin se acerca al bloque 961.632, cuya llegada está prevista para el próximo 8 de agosto, día en el que comenzaría una ventana de señalización minera obligatoria que podría forzar la entrada en vigor de BIP-110, una propuesta de soft fork temporal que apunta a restringir el uso de la red para guardar datos arbitrarios, como imágenes o archivos insertados dentro de las transacciones.

La propuesta no fue diseñada para afectar a Lightning Network (LN), la red que permite pagar con bitcoin (BTC) de forma instantánea y con comisiones mínimas respecto a la capa base, pero si BIP-110 termina dividiendo la cadena de Bitcoin, abre la posibilidad de intentos de robos a los canales de pago sin que la víctima llegue a enterarse a tiempo para evitarlo.

Ese es el escenario que describe Amboss, una empresa de infraestructura para Lightning Network, en un análisis publicado este 20 de julio y firmado por Anthony Potdevin, cofundador y director de tecnología de la compañía.

El riesgo de BIP-110 en Lightning: no ver a tiempo un robo en los canales

Lightning Network funciona mediante canales de pago. Un canal es un acuerdo entre dos participantes que bloquean una cantidad de bitcoin en una única transacción de apertura y, a partir de ahí, pueden intercambiarse pagos de forma instantánea y con comisiones mínimas, actualizando el saldo que le corresponde a cada uno sin registrar cada movimiento individual en la cadena de bloques de Bitcoin. La capa principal solo interviene cuando esos participantes abren el canal, lo cierran o necesitan resolver una disputa.

La seguridad de ese sistema depende de que cada nodo de Lightning Network pueda ver a tiempo cualquier intento de su contraparte de publicar un estado desactualizado del canal, una forma de intentar quedarse con fondos que ya no le corresponden. Si un participante detecta ese intento dentro de un plazo determinado, puede emitir una transacción de penalización que anula el intento de fraude y castiga a quien lo produjo.

El riesgo que describe Amboss aparece si la cadena de Bitcoin llega a dividirse durante la activación de BIP-110. Si eso ocurriera, convivirían temporalmente dos versiones distintas de la red, y cada nodo de Lightning Network no elegiría por sí mismo cuál seguir, sino que seguiría la versión de Bitcoin que utiliza para conectarse a la red.

El problema surge porque la seguridad de un canal de Lightning depende de que su nodo pueda ver, dentro de la cadena que sigue, cualquier intento de la contraparte de publicar un estado desactualizado del canal para quedarse con fondos que ya no le corresponden. Si esa contraparte publica ese intento de fraude en la otra cadena, la que el nodo de la víctima no está observando, la víctima no llegará a verlo y no podrá responder con la transacción de penalización que anularía el robo. El plazo para hacerlo podría vencer sin que nadie reaccione, y el atacante se quedaría con fondos que ya no le correspondían.

Si bien este riesgo no es exclusivo de BIP-110, sino de cualquier división de Bitcoin, la produzca la propuesta que la produzca, lo que sí distingue a BIP-110 es su método de activación, enfatizan desde Amboss.

Para activarse, BIP-110 exige que apenas el 55% de los bloques de un período de dificultad muestren el respaldo de los mineros (señalización), muy por debajo del 95% que fija como estándar BIP-9, el mecanismo que Bitcoin usa habitualmente para activar cambios de consenso. Además, si ese 55% nunca se alcanza de forma voluntaria, BIP-110 fuerza igualmente su aplicación mediante una ventana de señalización obligatoria entre los bloques 961.632 y 963.647, en la que cualquier bloque que no respalde la propuesta queda automáticamente invalidado.

Al tiempo de este artículo, la señalización minera se ubica en 1%, como se ve en el siguiente gráfico de BIP-110.org, por lo que el respaldo actual hacia esa iniciativa es casi nulo:

Una división más caótica que la de Bitcoin Cash en 2017

Las divisiones de cadena que se planean deliberadamente suelen incorporar un mecanismo adicional para evitar la ambigüedad que describe Amboss.

Cuando Bitcoin Cash se separó de Bitcoin en 2017, incorporó un mecanismo de protección contra la repetición de transacciones, que impide que una transacción confirmada en una de las cadenas resultantes también sea válida en la otra. BIP-110 no incorpora ese mecanismo porque no fue diseñado como una bifurcación deliberada para crear dos redes independientes, sino como una modificación temporal de las reglas de consenso dentro de Bitcoin.

Por eso, si la activación de BIP-110 terminara provocando una división de la cadena de todos modos, la coordinación entre los participantes de Lightning Network podría ser más caótica que en una separación preparada de antemano.

Al menos un actor del ecosistema de Lightning Network ya tomó una decisión operativa frente a este escenario. Lightning Network Liquidity, una empresa que opera nodos de enrutamiento (los que dirigen el tráfico de pagos entre distintos participantes de la red), publicó una declaración en la que informó haber migrado su infraestructura a una versión de Bitcoin compatible con BIP-110.

La empresa aclaró que esa decisión responde a un cálculo económico y no a un respaldo ideológico a la propuesta: «Como nodo de enrutamiento, no estamos votando; estamos posicionándonos donde creemos que está la mayor gravedad económica». Conviene remarcar que se trata de la posición de un solo operador de enrutamiento, no de una implementación de referencia para nodos de Lightning Network como LND, Core Lightning o Eclair.

¿BIP-110 podría frenar el crecimiento de la red Lightning?

Los canales clásicos de Lightning Network no chocan con los límites que impone BIP-110: la transacción que abre un canal (la salida de financiamiento) y la transacción que fija el saldo de cada participante (la transacción de compromiso) ocupan 34 bytes, exactamente el límite máximo que permite la propuesta.

Las condiciones de gasto más grandes que utiliza la LN, las que protegen los pagos en tránsito mediante contratos con bloqueo por huella criptográfica y por tiempo, conocidos por su sigla en inglés HTLC, ocupan menos de 150 bytes, muy por debajo del límite de 256 bytes que fija BIP-110 para ese tipo de datos. El repositorio de BIP-110 sostiene que todos los demás usos conocidos de Bitcoin no se ven afectados por la propuesta.

Sin embargo, Lightning Network está evolucionando hacia un formato de canal más nuevo basado en Taproot, la actualización de Bitcoin de 2021 que permite condiciones de gasto más flexibles y compactas y BIP-110 introduce las siguientes cuatro restricciones en el entorno de programación que usa Taproot, conocido como Tapscript:

• Invalida el uso del anexo de Taproot (un campo que hoy no tiene ningún uso definido).

• Limita a 257 bytes el bloque de control que prueba que una condición de gasto pertenece al árbol de Taproot.

• Invalida los códigos de operación reservados para futuras actualizaciones (conocidos como OP_SUCCESS).

• Invalida el uso de las instrucciones condicionales OP_IF y OP_NOTIF.

Esas cuatro restricciones de BIP-110 no bloquean las condiciones de gasto que Lightning Network necesita para funcionar, porque los canales Taproot que la red ya tiene desplegados dividen cada camino posible de un pago (el del cobro cumplido, el del reembolso por tiempo vencido, el de la penalización por fraude) en ramas separadas, en lugar de escribirlos como una única condición con bifurcaciones internas, que es justamente el recurso que BIP-110 restringe dentro de Tapscript.

En ese sentido, el sitio bip110.org sostiene en su sección de preguntas frecuentes que BIP-110 no afecta a Lightning Network. Asimismo, Luke de Wolf, cofundador del evento bitcoiner BTCHEL y promotor de BIP-110, defendió la misma postura en una discusión pública en la red social X: «Lightning es una maravilla de la innovación. Un diseño único y robusto. No nos abrimos necesariamente a la ola de spam con las funciones que habilitaron Lightning. Y Lightning no se verá afectado ni limitado por 110«.

No obstante, esas mismas cuatro restricciones de Tapscript afectadas por BIP-110 sí inciden sobre el camino de desarrollo más activo para dotar a Lightning Network de una arquitectura distinta, conocida como LN-Symmetry (también llamada eltoo), pensada para simplificar los canales y eliminar la necesidad de penalizar estados antiguos.

La implementación más concreta para llevar LN-Symmetry a producción, denominada LNHANCE y formalizada en marzo de 2026 como BIP-446 y BIP-448, según reportó el equipo de la plataforma HyperSinc, plantea reutilizar precisamente códigos de operación OP_SUCCESS, la misma categoría que BIP-110 invalida durante su año de vigencia. Por lo tanto, mientras BIP-110 esté activo, cualquier condición de gasto que dependa de redefinir un código OP_SUCCESS quedaría inválida, lo que en los hechos pausaría ese camino de desarrollo durante ese período.

Otro desarrollo que podría verse afectado por las restricciones de BIP-110 son las fábricas de canales, una construcción que permitiría abrir varios canales de Lightning Network a partir de una sola transacción en la cadena de Bitcoin y que, al involucrar a más participantes, podría requerir árboles de condiciones de gasto más grandes que los que usan los canales actuales. En este caso, su vínculo con BIP-110 es más especulativo que el de LN-Symmetry, ya que ninguna implementación pública de fábricas de canales depende hoy de superar el límite de 257 bytes que la propuesta impone al bloque de control, por lo que ese impacto sigue siendo una posibilidad teórica antes que una limitación documentada, algo que confirma Bitcoin Optech al describir el estado actual de esta construcción.

Ambos desarrollos están aún en producción y el efecto de BIP-110 sobre ellos sería, como máximo, una pausa de un año en su avance, no una interrupción de fondos ya comprometidos en algún canal existente. Además, cualquier fondo creado antes de la activación de BIP-110 queda exento de todas las reglas nuevas, por lo que un canal abierto antes de esa fecha podría cerrarse sin toparse con ninguna restricción.

De modo tal, BIP-110 no interrumpiría el funcionamiento actual de Lightning Network, pero si su activación divide la cadena de Bitcoin, la seguridad de sus canales dependerá de que todos los participantes observen la misma cadena. La ventana de señalización obligatoria arranca en el bloque 961.632, previsto para el 8 de agosto de 2026, con un respaldo de los mineros que, según BIP-110 Monitor, está en torno al 1%. El debate sigue dividido entre quienes defienden la propuesta y quienes cuestionan el riesgo de su método de activación.