Nodos rezagados del fork de la BIP-110 podrían tener dificultades al volver a Bitcoin

Tres días después de que Bitcoin se dividiera en dos cadenas por la activación de BIP-110, todavía hay operadores de nodos con Bitcoin Knots que no saben con certeza si su nodo quedó aislado de la red principal, y menos aún, qué hacer para volver. La respuesta corta es que sí pueden reconectar, pero el trámite no se resuelve con una simple actualización de software.

El origen del problema no es una cuestión de versiones desactualizadas. El bloque 961.632 marcó el quiebre en el que los nodos que corrían Knots con las reglas de BIP-110 rechazaron como inválido un bloque que el resto de la red validó sin inconvenientes. Esa decisión no fue un error de sincronización, sino el resultado esperado del diseño de la bifurcación suave (soft fork) que propone BIP-110.

Un nodo de Bitcoin guarda en su disco qué bloques considera válidos e inválidos. Cuando Knots con BIP-110 rechazó el bloque 961.632, esa marca quedó escrita en la base de datos local del nodo, no en el programa que lo ejecuta. Por eso, instalar una versión de Knots sin BIP-110 no borra ese veredicto de forma automática en todos los casos.

La diferencia está en quién administra esa base de datos. Programas como StartOS, Umbrel o myNode son sistemas operativos pensados para correr un nodo propio sin necesitar conocimientos avanzados de administración de servidores, muy usados por quienes operan un nodo desde su casa. Docker, en cambio, es una herramienta más general que empaqueta y ejecuta programas de forma aislada, y muchos operadores la usan para correr Bitcoin Knots en un servidor propio.

En la versión 0.4 de StartOS, el sistema detecta el cambio de software, borra las marcas guardadas y muestra un aviso propio de reinicio de esos veredictos, según documentó Start9Labs en las instrucciones de su paquete de Knots. En instalaciones con Docker, Umbrel o myNode, esa limpieza no ocurre sola, y el nodo puede quedarse anclado en el bloque 961.633 de la rama de BIP-110 aunque el operador ya haya instalado el software correcto.

Cómo saber si tu nodo quedó atrapado y los pasos para reconectar

Para confirmar en qué cadena quedó un nodo alcanzan dos comandos de la consola del cliente Bitcoin Knots: getblockhash 961632 y getblockchaininfo. Si el primero devuelve un hash distinto al de la cadena principal, o si los valores de blocks y headers no coinciden, el nodo sigue anclado en la rama minoritaria.

El campo blocks indica hasta qué altura el nodo validó y conectó bloques completos, mientras que headers muestra la altura más alta de la que el nodo tiene noticia a través de otros nodos, aunque todavía no haya descargado ni validado esos bloques. Si headers supera a blocks, es una señal de que el nodo ya sabe que existe una cadena más larga, pero algo (como la marca de bloque inválido) le impide conectarse a ella.

El desarrollador Jameson Lopp había anticipado este escenario meses antes de la bifurcación, cuando advirtió que cualquier nodo que corriera BIP-110 quedaría fuera de la red de forma involuntaria si la propuesta no lograba un respaldo suficiente del resto de la comunidad.

El propio autor de BIP-110, que firma como Dathon Ohm, publicó una guía con los pasos técnicos para abandonar esa rama. El procedimiento indica instalar la versión de Knots anterior a BIP-110, identificada como v29.3.knots20260507, conservar el mismo directorio de datos y quitar del archivo de configuración la línea consensusrules=rdts, el parámetro literal que activa las reglas de BIP-110 en el software y que debe escribirse exactamente así para que el cambio tenga efecto.

Si después de ese cambio el nodo sigue mostrando el bloque 961.633 como el más reciente, la guía recomienda invalidar manualmente el primer bloque de la rama de BIP-110 con el comando invalidateblock. Esa acción invalida también a su bloque siguiente. Una vez que el nodo termine de sincronizar con la cadena principal, conviene ejecutar reconsiderblock sobre el mismo bloque para retirar esa marca manual y dejar que las reglas normales de validación sigan su curso.

La guía de Dathon Ohm resume estos pasos de verificación final, como se ve en la siguiente imagen:

El estado actual de la bifurcación de BIP-110

Al momento de escribir esta nota, la brecha entre ambas cadenas seguía ampliándose. Bitcoin llegó al bloque 962.002, mientras que la rama de BIP-110 permanecía detenida en el 961.633, una diferencia de 369 bloques, como reportó CriptoNoticias hoy 11 de agosto.

El 9 de agosto, el propio repositorio de propuestas de mejora de Bitcoin marcó a BIP-110 como cerrada. La nota de cambios atribuye ese cierre a la bifurcación de la red y a la falta de nuevos bloques en la rama disidente, apenas un día después del quiebre en el bloque 961.632.

La resistencia a esa cadena, sin embargo, no desapareció del todo. Luke Dashjr, principal promotor de BIP-110, sostiene que la propuesta no fracasó, pese a que la producción de bloques en esa rama se mantiene prácticamente nula desde la bifurcación y con apenas fracciones del poder de minería que respalda a la cadena principal.

Un operador de nodo de Bitcoin puede elegir libremente qué reglas de consenso sigue, y nada le impide seguir usando una versión de Knots con BIP-110 activo. Pero mientras esa cadena reúna una fracción mínima del respaldo que sostiene a la red principal, volver no va a ocurrir con el simple paso del tiempo: exige una decisión técnica activa por parte de cada operador.