La transacción que rebasó el límite de Bitcoin y los nodos que rechazaron su historia
El bloque 74.638 incluyó dos salidas de 92.233.720.368,54275808 BTC cada una. La recuperación exigió un parche, mineros y nodos actualizados, y otra cadena que superó el historial defectuoso al día siguiente.
Resumen clave en 3 puntos
- El detonante / ParadojaA las 17:05:57 UTC del 15 de agosto de 2010, el bloque 74.638 incluyó dos salidas de 92.233.720.368,54275808 BTC, un total de 184.467.440.737,08551616 BTC.
- El punto de inflexiónJeff Garzik publicó la anomalía y los participantes rastrearon un desbordamiento que volvía negativa la suma de dos salidas positivas. Gavin Andresen propuso un arreglo rápido antes de que Satoshi subiera el parche de consenso.
- El legado históricoLa versión 0.3.10 invalidó la transacción, pero la recuperación dependió de mineros y operadores de nodos. Satoshi informó el 16 de agosto que la cadena corregida había adelantado a la defectuosa cerca de la altura 74.689.
Cronología de los hechos
Dos salidas positivas suman 184.467.440.737,08551616 BTC y el total desborda a un valor negativo en la validación antigua.
Garzik muestra los datos del bloque y pregunta por la relación entre la enorme salida y el límite entero.
Tras una prueba breve, plantea rechazar salidas que excedan el rango monetario.
A las 21:40 Satoshi publicó la revisión 132, que comprueba cada salida y el total acumulado frente al rango monetario. A las 23:48 anunció los ejecutables de la versión 0.3.10 que rechazaban la transacción y pidió a los operadores que actualizaran.
Satoshi informa que el historial válido superó al otro cerca de la altura 74.689 y los nodos antiguos se reorganizaron hacia él.
1. El bloque mostró una cantidad imposible
A las 17:05:57 UTC del 15 de agosto, el bloque 74.638 registró una entrada de 0,5 BTC y dos salidas exactas de 92.233.720.368,54275808 BTC.[1]
Sumaban 184.467.440.737,08551616 BTC. «184.000 millones» comunica la escala del titular, pero no es la cifra exacta.[1]
Cada salida quedaba justo por debajo del máximo de un entero con signo de 64 bits. Al sumarlas, el cliente antiguo desbordaba hasta -0,01 BTC. Así, una transacción que gastaba mucho más que su entrada atravesó un control pensado para cantidades normales; el minero del bloque cobró 50,51 BTC, incluidos los 0,51 BTC que el programa interpretó como comisión.[1]
2. Un hilo público convirtió la sorpresa en diagnóstico
Jeff Garzik publicó los datos a las 18:08.[1][2]
Otros participantes reprodujeron la transacción, señalaron la suma negativa, detuvieron la generación en algunos nodos y advirtieron que no se enviaran ni aceptaran pagos hasta resolver el fallo. El registro conservado no identifica al autor de la transacción ni su motivo; llamarlo hacker o minero intencional iría más allá de la evidencia.[1][2]
Gavin Andresen publicó a las 20:39 una propuesta sometida a pocas pruebas. Veinte minutos después, Satoshi mostró un borrador más amplio que rechazaba cada salida y también el total acumulado si excedían 21 millones de BTC. Gavin respondió que parecía correcto y preguntó cómo aislar el bloque sin obligar a todos a descargar de nuevo la cadena.[2]
3. Cambió primero el código; después cambió la historia aceptada
A las 21:40, Satoshi anunció la revisión 132 del repositorio.[2][4]
El commit conservado añade el control de rango monetario a cada salida y a su suma. Era una regla más estricta: el software corregido rechazaba la transacción que los clientes antiguos ya habían aceptado.[2][4]
Satoshi compiló después la versión 0.3.10 y la anunció a las 23:48. Los operadores debatieron cómo detenerse, actualizar y reiniciar desde el último historial válido; compartieron copias antiguas de la cadena y pares ya corregidos. Los mineros actualizados extendieron una rama desde el bloque 74.637. La versión aportó la regla y las decisiones independientes de los operadores aportaron la prueba de trabajo.[2][3]
4. La recuperación continuó durante la noche
A las 02:16 del 16 de agosto, Satoshi informó catorce bloques nuevos y dijo que más de la mitad de los nodos conectados a él usaban 0.3.10, aunque todavía expresó como estimación que la rama correcta probablemente tenía más potencia.[2]
A las 12:59 confirmó que había adelantado a la defectuosa cerca de la altura 74.689 y que los clientes antiguos llevaban horas siguiendo la altura vigente.[2]
La secuencia separa dos hitos que suelen comprimirse. El parche fuente apareció unas cuatro horas y media después de la marca temporal del bloque y los ejecutables llegaron más tarde; la confirmación de que el historial corregido había ganado llegó al día siguiente. Las transacciones ordinarias podían reincorporarse y sumar confirmaciones, mientras desaparecían las recompensas inmaduras posteriores al bloque 74.638 en la rama abandonada. Satoshi publicó la corrección, y mineros y operadores de nodos independientes completaron la recuperación coordinada.[2][3]
Lecciones clave para inversores y creadores
El límite debe cumplirse en cada valor y en la suma
La ruta antigua aceptaba cada salida, pero no impedía el desbordamiento al sumarlas. El parche añadió controles durante la acumulación.
Publicar el parche no reescribió el libro
La nueva regla pesó cuando mineros y operadores la ejecutaron y acumularon suficiente prueba de trabajo en la rama corregida.
La recuperación rápida movió confirmaciones y recompensas
Las transacciones ordinarias podían volver a confirmarse, mientras desaparecían recompensas inmaduras minadas en la rama abandonada.
Historias para seguir leyendo
Explora el tema a través de otros casos y contextos.
Fuentes y referencias
- [1]Fuente 1: Bitcoin Forum: primer aviso sobre las salidas anómalas del bloque 74.638Archivo de Bitcoin Forum · 2010-08-15
- [2]Fuente 2: Bitcoin Forum: respuesta urgente al fallo de desbordamientoArchivo de Bitcoin Forum · 2010-08-15
- [3]Fuente 3: Bitcoin Forum: anuncio de la versión corregida 0.3.10Satoshi Nakamoto / Archivo de Bitcoin Forum · 2010-08-15
- [4]Fuente 4: Código de Bitcoin: corrección del desbordamiento del bloque 74.638Repositorio del código de Bitcoin · 2010-08-15
- [5]Fuente 5: Detalles de la vulnerabilidad CVE-2010-5139National Vulnerability Database, NIST