El día en que se crearon 184 mil millones de bitcoins

La publicación de Garzik era breve y concreta. Mostraba el hash de la transacción y dos salidas enormes. Un listado posterior de printblock, en la misma conversación, daba su valor exacto: cada una contenía 92 233 720 368,54275808 BTC. El bloque incluía además una transacción coinbase independiente que pagaba 50,51 BTC al minero. Frente a la recompensa base habitual de cincuenta bitcoins, aquellas dos salidas parecían absurdas: alguien acababa de crear más de 184 mil millones de unidades.

Detrás de la transacción no había un nombre conocido ni una explicación pública. La cadena conservada dice qué sucedió, pero no quién explotó el error ni con qué objetivo. Calificar al autor como un hacker específico significaría agregar un dato que las fuentes no tienen. Lo único seguro es que la transacción se construyó para aprovechar un punto débil en la validación.

La red la aceptó porque el código antiguo controlaba las salidas individuales y luego su suma. Cada una de las salidas gigantes cabía en el tipo numérico utilizado, pero al sumarlas juntas, superaban su límite superior. El número se desbordó hacia el área negativa y la verificación posterior concluyó erróneamente que no se estaba creando un valor positivo no permitido.

No se trataba, por lo tanto, de falsificar una firma, alterar una transacción anterior ni apoderarse de la mayoría de la potencia de hash. El atacante aprovechó la forma en que una implementación específica manejaba los números enteros. La regla matemática "no emitir más de lo que entra" era correcta; el programa no la ejecutó como la gente lo había planeado debido al desbordamiento.

El bloque ya era parte de la cadena más larga. Cada nodo que utilizaba la versión defectuosa lo consideraba válido y los mineros podían construir sobre él. La simple revelación pública no era suficiente. La comunidad tuvo que reaccionar más rápido de lo que la historia defectuosa se extendiera y las salidas gigantes comenzaran a propagarse.

El límite de 21 millones se describe a menudo como una ley inmutable de Bitcoin. El incidente mostró una imagen más precisa. El límite es un conjunto de reglas de consenso que cada programa y cada nodo completo debe ejecutar sin errores. Si todas las versiones de nodos de uso generalizado comparten la misma implementación defectuosa, pueden aceptar temporalmente un estado que se opone al propósito.

El desbordamiento de números enteros es un problema antiguo de programación. Un registro de computadora no tiene un rango infinito; después de superar el valor límite, la aritmética posterior puede terminar en el lado completamente opuesto del eje numérico. En un sistema contable, tal detalle es crucial. La suma debe controlarse no solo después del cálculo, sino durante él, y cada cantidad debe permanecer dentro del rango permitido.

El Bitcoin Core de hoy en día realiza varias verificaciones separadas. La salida no puede ser negativa, no puede superar el suministro máximo de dinero y la suma en curso se vuelve a verificar después de cada adición. Estas líneas no surgieron como una precaución abstracta. Llevan el recuerdo del evento en el que una protección ausente permitió a la red grabar una transacción económicamente imposible.

El error también muestra la diferencia entre la especificación y la expectativa social. Nadie en el foro afirmó seriamente que las monedas gigantes eran legítimas solo porque el software antiguo las aceptó. Los participantes estuvieron de acuerdo en que se trataba de una violación de la regla pretendida. Este acuerdo necesitaba, sin embargo, un medio técnico: una nueva versión que rechazara el bloque defectuoso.

Es aquí donde se encuentran el código y las personas. El código decide determinísticamente qué bloque acepta un nodo. Las personas deciden qué código instalar cuando descubren una discrepancia con las reglas pretendidas. El incidente no fue una votación sobre una nueva emisión; fue una carrera para restaurar la regla que la comunidad ya consideraba la base del sistema.

El desbordamiento es traicionero precisamente porque la máquina no percibe lo absurdo que un ser humano reconoce de inmediato. El procesor opera con un número almacenado en un espacio limitado; si el cálculo supera su límite, el resultado puede rebasar a otra parte del rango. El código antiguo comprobaba las salidas individuales, pero al sumar no mantenía la suma parcial dentro de límites seguros. La transacción, por tanto, pasó por varias condiciones localmente razonables y, aun así, violó su sentido global. La corrección tuvo que ser concreta: no bastaba con escribir en un comentario que nunca habría más de 21 millones de bitcoins. Cada nodo necesitaba una regla que pudiera aplicar de verdad esa afirmación en cada cálculo.

Después del anuncio, apareció en el foro una recomendación para detener la aceptación de transacciones y no minar temporalmente. Cada nuevo bloque sobre la transacción defectuosa aumentaría la cantidad de trabajo que sería necesario abandonar. En una red sin un interruptor central, Satoshi no podía detener la minería. Solo podía emitir una reparación y convencer a los operadores para que la ejecutaran.

La versión 0.3.10 introdujo las verificaciones de cantidad correctas y rechazó el bloque 74,638. Los nodos reparados regresaron al último punto válido común y los mineros comenzaron a construir una rama alternativa sin la transacción inflacionaria. Las dos historias compitieron durante un tiempo según el trabajo acumulado.

Satoshi anunció posteriormente que la cadena buena había superado a la mala. El software actualizado realizó una reorganización de la cadena y el bloque defectuoso desapareció de la historia activa. Las transacciones de la rama que no eran inherentemente inválidas podían regresar a la cola y ser incluidas nuevamente; las salidas gigantes, sin embargo, no podían existir según las nuevas verificaciones.

Esta reparación tuvo un costo. Los mineros en la rama abandonada perdieron sus recompensas y los usuarios tuvieron que aceptar que varias horas de historia no continuarían. En 2010, la red era pequeña y la coordinación fue rápida. La misma intervención en un ecosistema mucho más grande habría significado más participantes económicos, variantes de software y disputas sobre dónde exactamente se encontraba el límite de la reparación.

La rapidez de la respuesta suele presentarse como una intervención milagrosa de Satoshi. En realidad, la componían pasos observables: Garzik hizo público el problema, otras personas analizaron el desbordamiento, los desarrolladores prepararon el cambio, los operadores instalaron una nueva versión del cliente de Bitcoin y los mineros aportaron trabajo a la rama correcta. El autor podía proponer la reparación, pero la red tenía que adoptarla de verdad.

Tras la corrección, la cantidad de bitcoins válidos volvió al límite previsto y los miles de millones creados por el fallo ya no podían gastarse en la cadena que siguió adelante. Por tanto, el incidente no causó una inflación permanente. Aun así, no es una mera curiosidad de una versión beta. Recuerda que la confianza en las reglas monetarias se apoya en un programa verificado una y otra vez, no en un eslogan.

A menudo se presenta a Bitcoin como opuesto a los sistemas en los que una autoridad central cambia el suministro por decisión. Sin embargo, aquí las personas no desaparecen. Los desarrolladores escriben implementaciones, los revisores buscan errores, los operadores eligen versiones y los mineros crean el orden de los bloques. La diferencia está en que la intervención es pública y cada nodo puede rechazar las reglas con las que no está de acuerdo.

El evento también explica la precaución con la que se cambia el código de consenso hoy en día. Una pequeña optimización de la aritmética puede tener consecuencias monetarias. Las pruebas, las verificaciones de implementación múltiple y la revisión lenta no son burocracia adicional; son una defensa contra la repetición del momento en que unos pocos bits convirtieron miles de millones de un número no permitido en uno aparentemente válido.

Jeff Garzik no hizo que la red fuera segura con una sola publicación en el foro, pero mostró la ventaja de un libro contable público. Cualquiera podía ver el bloque extraño, volver a calcular sus salidas y verificar la reparación. El error no estaba oculto en una base de datos interna del operador. Estaba frente a toda la comunidad, junto con la prueba de que los nodos antiguos lo habían aceptado.

El límite de suministro, por lo tanto, sobrevivió al incidente de una manera diferente a lo que sugiere la palabra "inmutable". No porque el software no pudiera fallar, sino porque el fallo era visible, había una regla compartida a la que regresar, y suficientes participantes realizaron la reparación. La historia de los 184 mil millones de bitcoins no es una negación de la oferta fija. Es la historia de lo que realmente se requiere para mantenerla.

El episodio recuerda también que la naturaleza pública del código no elimina por sí sola el error. El código abierto permitió a las personas localizar, comparar y corregir el problema sin depender de un único proveedor, pero lo decisivo fue la atención de participantes concretos. Alguien tuvo que percatarse de los números imposibles, alguien tuvo que encontrar la condición defectuosa y los operadores tuvieron que adoptar la actualización. La transparencia creó la posibilidad de verificación; solo la acción la convirtió en defensa de la red. Por eso la historia sigue siendo importante incluso tras años: la seguridad de Bitcoin no reside en la idea de un programa original perfecto, sino en la combinación de reglas precisas, verificación independiente y capacidad de reaccionar ante un error sin ocultarlo.