No fue una disputa sobre una regla nueva, sino una dependencia oculta de la validación respecto de la implementación de la base de datos: LevelDB procesó un bloque con una cantidad inusual de entradas, mientras las versiones anteriores agotaron el número predeterminado de bloqueos de Berkeley DB; los mineros coordinaron el regreso a la rama compatible y la posterior versión 0.8.1 preparó una transición controlada.
El 11 de marzo de 2013, un nodo con Bitcoin 0.8 minó el bloque 225 430. La versión nueva lo aceptó, mientras parte de los nodos con 0.7.2 y anteriores lo rechazó; desde el mismo padre crecieron por ello una rama con ese bloque y otra sin él. La diferencia no estaba en el hash ni en el proof of work, sino en si el software local consideraba válido el bloque. [2]
El detonante no fue simplemente el tamaño del bloque en bytes. El bloque contenía una cantidad de entradas de transacción nunca vista y los nodos antiguos agotaron al escribirlas el número predeterminado de bloqueos de Berkeley DB. Los bloqueos necesarios también dependían de la disposición de las páginas de la base de datos de cada nodo, por lo que un bloque menor pero válido podía fallar donde antes habían pasado bloques de prueba de tamaño máximo. [1]
Bitcoin 0.8 trasladó los índices de bloques y transacciones de Berkeley DB a LevelDB, que no tenía el mismo límite de bloqueos. Al principio, aproximadamente el 60 % del hashrate construía sobre la rama 0.8, pero los nodos antiguos no contaban su trabajo porque rechazaban el bloque inicial. La regla de la cadena más pesada elige solo entre historias que el nodo ha validado primero, así que no podía resolver sola el desacuerdo. [1]
Pieter Wuille publicó el aviso de emergencia y recomendó a los comercios suspender el procesamiento de pagos. Tras debatirlo desarrolladores y operadores, BTCGuild, dirigido por Michael Marsee, conocido como Eleuthria, y Slush Pool de Marek Palatinus volvieron a Bitcoin 0.7. El objetivo no era declarar errónea para siempre la rama técnicamente más nueva, sino concentrar pronto el trabajo en una historia que ambas versiones ampliamente desplegadas pudieran validar. [3]
Cuando la rama compatible tomó la delantera en trabajo acumulado, los nodos 0.8 se reorganizaron hacia ella y los bloques minados solo en la rama 0.8 original quedaron obsoletos. BIP 50 documenta al menos un double spend grande durante la división; según el post-mortem fue un experimento, no un robo intencional. Aun así, el episodio mostró por qué bolsas y comercios pausan depósitos y esperan más confirmaciones cuando la punta de la cadena es incierta. [1]
Bitcoin Core 0.8.1 se publicó el 18 de marzo de 2013. Introdujo una regla temporal de aceptación de bloques aplicada del 21 de marzo al 15 de mayo para impedir aceptar bloques que los pares antiguos no podían procesar, y añadió un checkpoint integrado en el bloque 225 430. El post-mortem también especifica un límite estimado de 10 000 bloqueos, un límite de minería de 500 000 bytes y backports con un límite de 537 000 bloqueos de Berkeley DB. [4]
La compatibilidad temporal no era el estado final. Los operadores de nodos antiguos tenían hasta el 15 de mayo para pasar a 0.8.1, a un backport actualizado o aumentar explícitamente el límite de bloqueos; los mineros no debían elevarlo antes de la fecha coordinada para no crear otra vez un bloque rechazado por el resto de la red. El 16 de agosto de 2013 la red aceptó el bloque 252 451 y dejó atrás definitivamente a los nodos sin parchear. [5]
El incidente mostró que el consenso es más que una descripción del formato de bloque. Incluye el comportamiento exacto del código de validación, bibliotecas, transacciones de base de datos, rutas de error y pruebas de límites. Por eso las medidas posteriores incluyeron generar transacciones de estrés en testnet, mejores alertas para servicios, vigilancia de ramas laterales largas y coordinación más cauta de los cambios; la rápida recuperación también expuso la dependencia de entonces de unos pocos desarrolladores localizables y grandes pools. [1]
Para obtener la imagen más completa, lee esta entrada junto con Bitcoin Core, Reglas de consenso, Hard Fork, Reorg, Full Node, Mining Pool. También enlazan con esta entrada Schelling Point.
01¿Decidió un solo grupo cuál era la cadena real?+
Los desarrolladores y grandes pools coordinaron la emergencia, pero no podían reescribir nodos a distancia. BTCGuild y Slush cambiaron el software con el que minaban, mientras los usuarios ejecutaban versiones con sus propias reglas de validación. La rama compatible se impuso solo cuando suficientes nodos la aceptaron y acumuló más trabajo para los nodos Bitcoin 0.8.
02¿Eran válidas ambas ramas al mismo tiempo?+
Dependía de la versión validadora. Bitcoin 0.8 consideraba válidos el bloque 225 430 y su rama, mientras algunos nodos antiguos rechazaban el bloque por el límite de Berkeley DB y solo conocían la otra rama. Dar respuestas distintas a los mismos datos es precisamente un fallo de consenso; la historia activa actual continúa desde la rama compatible elegida de forma coordinada.