La hash war de 2018 y lo que el hashrate no puede decidir

Dos cadenas comparten un bloque con el número 556.766, minado el 15 de noviembre de 2018 a las 17:52:01 UTC, con el hash 00000000000000000102d94fde9bd0807a2cc7582fe85dd6349b73ce4e8d9322. Todo lo anterior pertenece a las dos historias. Todo lo posterior pertenece a una o a la otra: el bloque 556.767 empieza con 0000000000000000004626ff en una cadena y con 000000000000000001d95671 en la otra, diez y veinticinco minutos después del bloque que comparten. Kraken, que tuvo que acreditar saldos de los dos lados, publicó ese mismo momento de la división, "2018-11-15 17:52 UTC" (18 de noviembre de 2018).

Quienes protagonizaron lo que vino después lo llamaron una guerra librada con poder de minado, y es el caso más claro que existe de una pregunta que se le pidió responder al poder de minado y no pudo. Este texto da por sabido, a grandes rasgos, qué hacen los mineros y qué hace un nodo.

Dos upgrades, escritos por separado

Bitcoin Cash tenía un upgrade programado que se disparaba cuando el median time past de los últimos once bloques llegaba al timestamp UNIX 1542300000, es decir las 16:40 UTC del 15 de noviembre de 2018. En la fecha había acuerdo. En el contenido, no.

La especificación publicada en bitcoincash.org, con fecha del 10 de octubre de 2018, enumeraba cinco cambios de consenso: imponer el orden canónico de transacciones y eliminar la restricción de orden topológico, habilitar OP_CHECKDATASIG y OP_CHECKDATASIGVERIFY, exigir un tamaño mínimo de transacción de 100 bytes, imponer la regla push-only en scriptSig e imponer la regla de clean stack (2018-nov-upgrade.md). Bitcoin ABC lo implementó punto por punto en sus notas de la versión 0.18.0.

La implementación rival se anunció el 16 de agosto de 2018, a cargo de nChain, con el nombre Bitcoin SV, por Satoshi Vision. El comunicado de lanzamiento cita a Calvin Ayre diciendo que CoinGeek y otros mineros le habían pedido a nChain una implementación "que restaure el protocolo original de Bitcoin" (nChain, 16 de agosto de 2018). Sus notas de la versión 0.1.0, etiquetadas el 15 de octubre de 2018, nombran tres cambios en el mismo punto de activación: rehabilitar OP_MUL, OP_INVERT, OP_LSHIFT y OP_RSHIFT, subir a 500 el límite de opcodes por script y fijar en 128 MB el tamaño máximo de bloque aceptado por defecto. También dejan constancia de que se eliminó la protección automática contra replay.

El choque está en la regla de orden. El orden canónico ordena las transacciones de un bloque por identificador de transacción. El orden topológico, que Bitcoin siempre había exigido y que Bitcoin SV mantuvo, coloca cada transacción después de cualquier transacción del mismo bloque de la que gasta. Los dos entran en conflicto cuando un bloque contiene una cadena de gastos, porque ordenar por identificador a veces pone al hijo primero. Desde las 16:40 UTC, un bloque producido por una implementación podía ser rechazado de plano por la otra, y ninguno de los dos bandos llevaba protección contra replay en el momento de la división.

La afirmación de que el poder de minado lo resolvería

El argumento público del lado SV era que el minado sostenido, y no un acuerdo sobre reglas, era el instrumento que decidía. CoinGeek publicó la posición de Ayre el 16 de noviembre, un día después de la división: "CoinGeek y nChain están en esta batalla a largo plazo. Vamos a minar BCH y a pelear el tiempo que haga falta para proteger el Bitcoin original de Bitmain, Jihan Wu y su grupo de desarrollo Bitcoin ABC", y agregó que "estamos preparados para pelear durante meses y meses" y que "Bitcoin se trata de prueba de trabajo (PoW), no de prueba de hash alquilado (PoRH)" (CoinGeek, 16 de noviembre de 2018). En una entrevista publicada tres días antes del fork, Craig Wright dijo sobre el otro lado: "Van a quebrar. Estoy muy contento de hacerlos quebrar. Los vamos a desangrar" (Decrypt, 12 de noviembre de 2018).

Ese argumento merece su versión más fuerte, porque no es un disparate. Un minero con suficiente hardware puede apuntarlo a la cadena que le disgusta y llenar bloques con nada, lo que le cuesta al atacante la recompensa en una moneda que no quiere y le cuesta a todos los demás el uso de la cadena. El minado sostenido también decide con qué rapidez confirma una cadena, y una cadena que nadie puede usar es una cadena que nadie valúa. Ninguna de las dos cosas necesita que el otro lado esté de acuerdo con nada.

Una cosa no jugaba a su favor, y suele contarse mal. Bitcoin Cash ya había reemplazado el reajuste de 2.016 bloques de Bitcoin: desde el 13 de noviembre de 2017 recalculaba el objetivo en cada bloque a partir de una ventana móvil de 144 bloques (nov-13-hardfork-spec.md). Ninguna de las dos cadenas quedó atrapada en un objetivo calibrado para la red anterior a la división, así que la trampa de dificultad que se cerró sobre BIP-110 en agosto de 2026 no existía acá. Esto fue una competencia de gasto sostenido, no una carrera contra el reloj.

Qué pasó en los once días siguientes

Kraken había dicho el 10 de noviembre que Bitcoin SV "no cumple actualmente con los requisitos de listado de Kraken y es improbable que sea soportado". Lo listó igual el 18 de noviembre, bajo un ticker separado y con una lista de advertencias que incluía "ninguna billetera conocida soporta protección contra replay" y "la supervivencia de la cadena puede ser mutuamente excluyente con la de otras cadenas".

El 20 de noviembre Bitcoin ABC publicó la versión 0.18.5. La primera línea de sus notas es la que importa: "Se agrega el concepto de bloque finalizado. Los bloques finalizados no se pueden reorganizar, lo que protege a la red frente a reorganizaciones profundas". Agregó un parámetro -maxreorgdepth con valor por defecto 10 y "una penalización a las cadenas alternativas basada en la profundidad de la bifurcación" (notas de la versión), y el anuncio de ABC ese mismo día decía que la publicación llegaba después de amenazas de reorganización por parte de "unos pocos mineros" (bitcoinabc.org). Haya hecho lo que haya hecho además, desde el 20 de noviembre un nodo ABC ya no cambiaba a una historia rival que reorganizara más de diez bloques, por mucho trabajo que esa historia acumulara.

Los relatos sobre quién iba adelante no coinciden, así que acá va una medición que cualquiera puede repetir. A las 00:00 UTC del 25 de noviembre de 2018, el primer bloque en ese momento o después era la altura 558.039 en una cadena y 558.067 en la otra: 1.273 y 1.301 bloques después del bloque que comparten. Decodificar el campo bits de cada uno da una dificultad de alrededor de 367,7 mil millones y 416,4 mil millones respectivamente. A los diez días, la cadena SV iba adelante en las dos medidas. No se quedó con el nombre, y para entonces tampoco podía habérselo llevado minando, porque cinco días antes el otro lado había cambiado la regla que hacía decisivo al minado.

El 26 de noviembre CoinGeek publicó que la pelea había terminado: "Esto pone fin a la hash war de BCH desatada por la actualización de red del 15 de noviembre de 2018". El mismo texto cita a Ayre diciendo que "aunque ABC se quede con el dañado ticker BCH, BSV está ganando en masa el ecosistema de aplicaciones nativas de BCH", y al director técnico de Bitcoin SV, Steve Shadders, sobre agregar protección contra replay "para restaurar la confianza de usuarios y empresas en ambas cadenas" (CoinGeek, 26 de noviembre de 2018).

Por qué el trabajo no podía decidirlo

La prueba de trabajo ordena bloques dentro de un conjunto de reglas de consenso. No elige cuál conjunto es el correcto, porque un nodo revisa las reglas antes de mirar siquiera el trabajo. El white paper deja el orden explícito en la sección 5: los nodos aceptan un bloque "solo si todas las transacciones que contiene son válidas y no fueron gastadas antes", y recién entonces trabajan en extenderlo (Nakamoto 2008, recorrido acá).

En el código la secuencia es explícita. Bitcoin Core mantiene un conjunto llamado setBlockIndexCandidates, y Chainstate::FindMostWorkChain elige la entrada más pesada de ese conjunto (src/validation.cpp, v31.1). Un bloque que falla la validación queda marcado con BLOCK_FAILED_VALID y se borra de ese conjunto (mismo archivo), y la búsqueda de candidatos descarta una rama entera si algún ancestro lleva la marca, bajo el comentario "Candidate chain is not usable (either invalid or missing data)", es decir que la cadena candidata no sirve por ser inválida o por faltar datos. Una cadena inválida no es un competidor más pesado. No es un competidor. Las dos implementaciones de 2018 derivaban de esa misma base de código, así que los bloques de cada lado sencillamente no aparecían en el conjunto de candidatos del otro.

De ahí se siguen dos consecuencias.

• Un "voto de hashrate" es un error de categoría. Votar presupone una pregunta compartida y una regla compartida para contar. Dos grupos que aplican reglas de validez distintas no están contando las mismas boletas, porque cada nodo descartó los bloques del otro lado antes de cualquier comparación de trabajo. Más trabajo del otro lado de esa línea no mueve nada.
• Una cadena más larga bajo otras reglas no es una reorganización. Es un libro contable aparte que comparte un prefijo. Llamarlo una toma de control supone que las dos cadenas eran candidatas al mismo lugar. Para un nodo, nunca lo fueron.

Minar bloques vacíos en la cadena contraria es una amenaza real y distinta. No cambia las reglas de nadie; degrada el servicio de una cadena mientras el atacante siga pagando.

Qué sí deciden los mineros, que no es poco

Leer lo anterior como "los mineros no tienen poder" es el error opuesto, y es frecuente.

Los mineros eligen qué cadena válida extender, y ningún nodo puede anular esa elección. Eso decide con qué rapidez confirma cada cadena y, por lo tanto, si una cadena es usable. En Bitcoin, donde el objetivo solo se mueve cada 2.016 bloques, una cadena que pierde a sus mineros no tiene salida rápida (cómo funciona el reajuste). Los mineros también eligen qué transacciones entran en los bloques y en qué orden, que es el tema del mercado de comisiones.

La formulación honesta es angosta. Los mineros deciden el orden y la disponibilidad de una cadena. Los nodos deciden qué cuenta como cadena.

Dónde están hoy las dos cadenas

Las dos sobrevivieron. La cadena que siguió la especificación de bitcoincash.org se quedó con el nombre Bitcoin Cash y el ticker BCH, y estaba en la altura 965.015 a las 09:34 UTC del 21 de agosto de 2026. La cadena que siguió la especificación de nChain es Bitcoin SV, ticker BSV, y estaba en 963.261 esa misma mañana (Bitcore, WhatsOnChain). El lado de Bitcoin Cash lo volvió a hacer en noviembre de 2020, por una regla que exigía que "al menos el 8% de la recompensa del bloque se gaste como una única salida" hacia una dirección determinada (especificación); la cadena que la aplicó se separó como Bitcoin Cash ABC y el 1 de julio de 2021 pasó a llamarse eCash, ticker XEC (e.cash).

Nada de eso es Bitcoin y nada de eso movió una regla de consenso de Bitcoin. Es la demostración más limpia disponible de lo único que trata este texto: cuando quienes discrepan sobre las reglas siguen validando cada uno por su cuenta, no hay ganador. Hay dos libros contables, y la aritmética que supuestamente iba a elegir entre ellos estaba respondiendo otra pregunta.