La noche en que Bitcoin tuvo dos historias válidas

El bloque 225 430 no fue creado con la intención de dividir la red. Sin embargo, contenía más entradas de transacciones que los bloques anteriores, y así sobrecargó la base de datos de una manera que reveló la diferencia entre las versiones. Bitcoin 0.8 utilizaba LevelDB y procesó el bloque. La versión 0.7 con Berkeley DB se encontró con el número de bloqueos y terminó con un error.

El resultado fue peligrosamente sutil. Ambos grupos de nodos seguían las reglas como su programa podía ejecutarlas. La rama más nueva no era fraudulenta según las reglas de consenso pretendidas, y los nodos más antiguos no fueron atacados. La red se dividió debido a un límite práctico no documentado de una tecnología de base de datos.

Los mineros con la versión 0.8 construyeron sobre el nuevo bloque. Los mineros con versiones más antiguas continuaron desde su predecesor. Una vez que ambas ramas obtuvieron bloques adicionales, un pago confirmado en una no necesariamente existía en la otra. Un usuario no podía confiar seguramente en el número habitual de confirmaciones hasta que no estuviera claro qué historia aceptaría la mayoría económica.

La rama más nueva inicialmente llevaba aproximadamente el sesenta por ciento del poder de procesamiento. En circunstancias normales, la cadena con más trabajo acumulado habría ganado ventaja. Sin embargo, los nodos más antiguos no podían aceptar el nuevo bloque sin importar su trabajo. La reorganización en sí misma no puede superar un bloque que el software de validación local considera inválido.

El incidente así reveló el límite de la simple regla 'la cadena más larga gana'. Más precisamente, gana la cadena con más trabajo entre aquellas que el nodo reconoce como válidas primero. Cuando los nodos no están de acuerdo sobre la validez, el hashrate solo no es suficiente para una unificación inmediata.

Los desarrolladores detectaron el problema cuando las alturas y los hashes de los nodos que vigilaban empezaron a divergir. La coordinación se concentró en IRC: allí podían comparar registros, la potencia que respaldaba cada rama y las respuestas de los grandes pools de minería. Gavin Andresen recogió después en el BIP 50 la cronología y las decisiones de aquella noche.

No había una elección entre una rama puramente correcta y otra obviamente mala. Apoyar la versión 0.8 habría mantenido la cadena con más trabajo, pero habría cortado una cantidad de nodos más antiguos. Regresar a la rama 0.7 significaba convencer a los nuevos mineros de que abandonaran los bloques que ya habían extraído legítimamente y por los que esperaban una recompensa.

La razón práctica para regresar fue la compatibilidad. La versión 0.8 podía aceptar bloques más pequeños creados para la rama más antigua, mientras que los nodos 0.7 no podían aceptar el bloque problemático de la nueva rama. Si el poder de procesamiento se mueve a la rama que ambos grupos pueden aceptar, la red puede volver a unirse sin un upgrade forzado inmediato de todos los nodos más antiguos.

La decisión no era una orden que Andresen pudiera enviar a través del protocolo. Los desarrolladores contactaron a los operadores de pools y les explicaron la situación. A las casas de cambio se les recomendó suspender los depósitos. Bitcoin.org publicó una advertencia y pidió a los grandes pools que volvieran a la versión anterior del software para reunir la red en una rama compatible.

Esta coordinación fue rápida precisamente porque el círculo de participantes clave era aún relativamente pequeño y la gente se conocía de los canales públicos. La velocidad ayudó a salvar la red de una división más larga, pero también mostró las conexiones sociales sobre las que dependía el funcionamiento temprano. Bitcoin no tenía un jefe; tenía personas cuya llamada o mensaje podían mover una gran parte del poder de procesamiento.

La conversación en IRC no tenía fuerza legal ni una clave administrativa secreta. Su importancia radicaba en que reunía en un solo lugar a personas con distintas capacidades de intervención. Los desarrolladores podían explicar la causa, los grupos de minería podían redirigir la potencia de hash, las casas de cambio podían suspender los depósitos y los operadores de nodos podían cambiar de versión. Cada paso conllevaba su propio riesgo y nadie podía garantizar que los demás obedecieran. La decisión de respaldar la rama compatible con la versión 0.7 no fue, por tanto, una orden técnica emanada del centro de la red, sino una apuesta coordinada de que ese camino restauraría la historia común lo antes posible con el menor impacto en los usuarios. El éxito no puede separarse del pequeño tamaño de la comunidad en aquel momento ni presentarse como un procedimiento universal de crisis.

El paso decisivo lo dieron BTCGuild, dirigido por Michael Marsee, conocido como Eleuthria, y Slush Pool, de Marek Palatinus. Ambos operadores volvieron de la versión 0.8 a la 0.7 y dirigieron su potencia de minería hacia la rama antigua. Con ello ayudaron a cambiar el equilibrio de trabajo acumulado entre las dos historias.

La decisión tenía un coste real. Al reorganizarse la cadena, los bloques de la rama abandonada dejaron de formar parte de la cadena principal y sus recompensas ya no podían gastarse en ella. El BIP 50 señala expresamente que los pools sacrificaron ingresos importantes para devolver la red a una cadena común.

Una vez que la rama más antigua tomó la delantera, los nodos actualizados 0.8 pudieron aceptarla y reorganizar su historia. Los nodos más antiguos ya estaban en ella. La división se cerró no porque una versión sobrescribiera a la otra a distancia, sino porque suficientes mineros crearon más trabajo sobre el punto que ambos podían verificar.

Durante el incidente, hubo al menos un gran doble gasto, descrito como un experimento, no como un ataque planeado. El evento mostró sin embargo un riesgo real: una transacción podría haber sido confirmada en una rama que más tarde sería abandonada. La recomendación de detener los depósitos no fue una medida de pánico; protegió a los servicios de los saldos contables basados en una historia temporal.

Los pools no eran dueños de la red. Con la potencia que les habían confiado los mineros podían influir en los bloques que prevalecían, pero no obligar a cada nodo completo a aceptar reglas arbitrarias. Su éxito dependía de un objetivo concreto: construir una rama que tanto los nodos antiguos como los nuevos considerasen válida y acumular en ella más trabajo que en la otra.

Gavin Andresen documentó después el incidente en el BIP 50. El texto no afirma que la red funcionara a la perfección. Explica la causa, el desarrollo de los hechos, los bloques perdidos, el doble gasto y las medidas para detectar antes desacuerdos similares. Al publicarse el análisis, la experiencia de aquella noche dejó de depender solo de la memoria de sus participantes. Otros desarrolladores también pudieron aprender de ella.

Una de las lecciones aprendidas fue que el consenso no incluye solo las reglas escritas en los comentarios o la documentación. El comportamiento práctico de un programa ampliamente desplegado puede convertirse en una limitación de la red, incluso si nadie pretendía que tuviera un significado monetario. La migración de la base de datos, por lo tanto, no debe considerarse como un cambio puramente interno si puede alterar la aceptación de un bloque.

Otra lección fue la necesidad de coordinar los upgrades más cuidadosamente y probar bloques cerca de los límites operativos. La versión 0.8 trajo mejoras de rendimiento, pero la diferencia se manifestó solo en la cadena real. Después del incidente, los desarrolladores introdujeron límites temporales y prepararon un camino que permitiría a las dependencias más antiguas abandonarlas más tarde de manera segura.

A veces se cuenta este episodio como prueba de que unos pocos desarrolladores controlan Bitcoin; otras, como prueba de que la red es indestructible por sí sola. Ninguna lectura hace justicia a lo ocurrido. Fue posible coordinar una reparación urgente, pero hizo falta la cooperación de los pools, las casas de cambio y los operadores de nodos. Cada ordenador validaba por separado. El resultado común solo llegó cuando esas decisiones coincidieron.

La noche del 11 al 12 de marzo terminó con una sola cadena principal, pero las diferencias no desaparecieron por sí solas. Algunos participantes detectaron el problema, otros suspendieron servicios y los mineros renunciaron al trabajo realizado para recuperar una historia compatible. Bitcoin superó sus dos pasados en conflicto gracias a las reglas, los costes económicos asumidos y las personas dispuestas a admitir que, esta vez, el software nuevo debía ceder.

El valor del BIP 50 está en que no cierra el incidente proclamando una victoria de la descentralización. Registra la causa concreta, la cronología, el trabajo perdido y los pasos previstos para evitar otra sorpresa semejante. Un fallo incómodo se convierte así en material para nuevas pruebas. Queda, además, una pregunta abierta: ¿cuántos supuestos no escritos separan dos versiones de un programa que consideramos compatibles? El consenso es más que una lista de reglas sobre el papel. Las implementaciones y los nodos independientes deben llegar al mismo resultado incluso en los casos límite. La importancia de ese acuerdo se hace más evidente cuando se rompe.