El fallo estaba en la implementación de una regla de validación, no en la criptografía ni en el calendario de emisión. Cada salida era positiva, pero su suma se desbordaba hasta un valor negativo. La diferencia entre la entrada y ese total negativo parecía entonces una comisión. La versión 0.3.10 añadió límites superiores a cada salida y al total acumulado; tras reorganizarse hacia la rama corregida, el bloque defectuoso quedó fuera del historial activo.
El 15 de agosto de 2010, el desarrollador Jeff Garzik llamó la atención sobre el extraño bloque 74 638. La transacción 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9 gastó una única entrada de 0,50 BTC y creó dos salidas enormes. El volcado printblock de la época muestra 92 233 720 368,54275808 BTC en cada una. No se ha identificado de forma fiable al autor de la transacción: el registro público documenta sus datos, no la identidad ni la motivación de quien la creó. [1]
Bitcoin representaba las cantidades como enteros con signo de 64 bits en satoshis. El valor entero de cada salida, documentado también en hexadecimal como 0x7ffffffffff85ee0, era positivo y estaba justo por debajo del máximo int64. La suma de 18 446 744 073 708 551 616 satoshis superó el rango y se convirtió en −1 000 000 satoshis. La validación antigua aceptaba ese total negativo al compararlo con la entrada. Era un fallo aritmético, no una ruptura de las firmas. El primer listado JSON de la discusión tiene otras cifras decimales finales; para calcular con exactitud, aquí usamos el valor entero confirmado tanto por printblock como por la notación hexadecimal. [1]
El total negativo de las salidas, −0,01 BTC, frente a una entrada de 0,50 BTC produjo una comisión aparente de 0,51 BTC. El minero cobró así 50,51 BTC en la coinbase en lugar de la recompensa base de 50 BTC. Tras restar la entrada gastada e incluir el exceso de coinbase, las dos salidas enormes aumentaron la oferta de la rama defectuosa exactamente en 18 446 744 073 709 551 616 satoshis: 2^64 satoshis, o 184 467 440 737,09551616 BTC. Esa cifra no es, por tanto, la simple suma de ambas salidas. [2]
La comunidad reaccionó públicamente y bajo presión. Lfm calificó el error de grave, Gavin Andresen propuso comparar rápidamente cada salida con 21 millones de BTC y Satoshi Nakamoto publicó una solución más amplia: rechazar salidas negativas o excesivas y también el total acumulado excesivo tras cada suma. Satoshi pidió además detener temporalmente la minería, para que una nueva rama válida pudiera alcanzar y sustituir antes a la rama defectuosa. [2]
Satoshi anunció la versión 0.3.10 el 15 de agosto de 2010 a las 23:48 según el foro, unas cinco horas y cuarenta minutos después del aviso de Garzik. Los nodos actualizados consideraron inválidos la transacción que aprovechaba la vulnerabilidad y el bloque 74 638 y construyeron sobre el último bloque válido común. El anuncio contemporáneo indicó después que la rama buena había superado a la mala, de modo que el cliente actualizado podía reorganizarse sin borrar manualmente los archivos de la blockchain. [3]
No se editó un bloque antiguo en una base de datos central. Existieron dos historias rivales: los nodos antiguos aceptaban el bloque según las reglas originales, mientras los corregidos lo rechazaban y solo aceptaban trabajo sobre el antepasado válido. Cuando la rama reparada acumuló más Proof of Work, la red la siguió y el bloque inflacionario salió de la historia activa; decidieron la instalación de las nuevas reglas por usuarios y mineros y el trabajo posterior, no una orden de un administrador. [3]
La protección introducida entonces sigue visible hoy en Bitcoin Core. CheckTransaction rechaza una salida negativa, una salida superior a MAX_MONEY y un total acumulado fuera de MoneyRange; comprobar después de cada suma impide que el total peligroso se desborde antes de compararlo. Un comentario del código cita expresamente CVE-2010-5139, mientras que la comprobación separada de entradas duplicadas recuerda el incidente distinto CVE-2018-17144. [4]
El incidente demuestra que el límite de 21 millones no es una constante mágica protegida solo por hashes: lo aplican reglas precisas de validación y su implementación correcta. Una auditoría debe cubrir rangos individuales, suma segura, coinbase y comisiones, orden de controles, vectores de prueba en los límites y coincidencia entre implementaciones independientes. La historia muestra también la rapidez de la comunidad inicial y su gran dependencia de pocos desarrolladores, mineros y coordinación manual. [5]
Para obtener la imagen más completa, lee esta entrada junto con Bitcoin Core, Reglas de consenso, Transacción, UTXO, Reorg, Soft Fork.
01¿Existieron alguna vez 184 mil millones de BTC en un Bitcoin válido?+
Existieron brevemente en la rama defectuosa que se minaba entonces como resultado del bloque explotado. Los nodos corregidos rechazaron esa rama y la válida la reorganizó, por lo que las salidas gigantes no forman parte de la blockchain activa ni del conjunto UTXO actuales. El incidente histórico sí está documentado en el bloque y en la reacción de la época.
02¿Rompió el incidente para siempre el límite de 21 millones?+
No en la historia aceptada hoy, porque las reglas corregidas rechazaron el bloque defectuoso y sus salidas desaparecieron con la reorganización. El episodio mostró que el límite depende de una validación correcta y del software que ejecutan los participantes; una frase en la documentación no impone por sí sola la oferta.