Bitcoin Core prepara una defensa contra un viejo ataque al ajuste de dificultad

Bitcoin Core, el software de referencia de la red Bitcoin, cambió el 7 de septiembre la forma en que los mineros preparan uno de los bloques de cada periodo. El ajuste es obra del desarrollador Fabian Jahr.

Se trata de un paso previo a una futura corrección más grande. Por ahora, ninguna regla de la red cambió: solo se ajustó el software que arma los bloques antes de minarlos.

La corrección apunta a una falla vieja y conocida: el llamadotime warp attack. Es un truco que permitiría a alguien con mucho poder de minería (hashrate) hacer trampa con la hora de los bloques.

Cada bloque de Bitcoin lleva una marca de tiempo. Si un minero pudiera falsear esa marca de forma sistemática, podría engañar a la red para que crea que pasó menos tiempo del real entre bloques. Eso bajaría artificialmente la dificultad de minado, y con dificultad más baja, ese minero ganaría bloques más rápido de lo que le corresponde, quitándole recompensa a otros mineros.

Que ese error siga sin corregirse del todo, más de una década después de conocerse, no es descuido. Cambiar una regla del consenso de Bitcoin exige que casi toda la red —mineros, exchanges, quienes corren un nodo— esté de acuerdo y lista al mismo tiempo. Ese acuerdo colectivo, más que la dificultad técnica, es lo que tarda años en construirse.

Por eso la solución no ataca este problema sola, sino junto a otras tres fallas antiguas del diseño original de Bitcoin. La propuesta que las agrupa se llama BIP54 y busca corregir, de una sola vez: el time warp attack, los bloques diseñados para ser lentos de validar, una ambigüedad en los árboles Merkle que podría usarse para falsificar comprobantes de transacción, y un descuido que permitiría duplicar transacciones coinbase (la que se crea al minar el bloque). Agrupar estas cuatro correcciones evita que la red tenga que pasar por el largo proceso de acuerdo una vez por cada una.

Qué corrige en concreto el nuevo cambio

El cambio del que habla esta nota está documentado en el pull request 35949 del repositorio oficial de Bitcoin Core, y se ocupa puntualmente del primero de esos cuatro problemas: el time warp attack. Los otros tres —bloques lentos de validar, la ambigüedad en los árboles Merkle y las transacciones coinbase duplicadas— siguen sin tener un cambio de software equivalente hasta ahora.

Imaginemos que el reloj de la computadora de un minero está mal configurado y marca una hora anterior a la real. Antes de este cambio, si eso ocurría justo al preparar el último bloque de un periodo de dificultad, el software podía quedar trabado.

Calculaba mal el tiempo mínimo permitido y no lograba armar un bloque válido para minar. En la práctica, ese minero se quedaba sin poder trabajar hasta que su reloj se corrigiera solo.

Fabian Jahr, autor del cambio, explicó en el propio repositorio que este escenario es poco probable en la red principal de Bitcoin, porque requeriría un error de reloj muy grande. Es más frecuente en redes de prueba, donde las condiciones son menos estables.

Aun así, Bitcoin Core prefirió resolverlo antes de que se vuelva un problema real. Con el nuevo código, cuando el reloj de un nodo está atrasado, el propio software le pone la hora correcta a la propuesta de bloque, en lugar de quedar bloqueado. Este ajuste ya funciona en la red principal y en las de prueba, aunque BIP54 en sí todavía no esté activo en ninguna.

Por qué Bitcoin corrige sus errores tan despacio

Este caso muestra un patrón que rara vez se ve desde afuera: quienes desarrollan Bitcoin Core no corrigen las fallas de consenso de un solo golpe. Primero preparan el software que trabaja «alrededor» de la regla —en este caso, la minería— y recién después, si hay suficiente respaldo de la comunidad, activan el cambio de fondo.

Ese orden tiene una razón simple: si se activara la regla nueva sin que el software de minería estuviera listo, aparecerían problemas evitables, como nodos que de pronto no pueden minar por un simple error de reloj. Los desarrolladores prefieren limpiar esos detalles antes de pedirle a toda la red que dé un paso que no tiene vuelta atrás.

La propia historia de BIP54 confirma esa paciencia. La idea nació en 2019, de la mano de Matt Corallo, y quedó guardada durante años hasta que Antoine Poinsot la retomó en 2023, según consta en el propio texto de la propuesta publicado en el repositorio de BIPs de Bitcoin. Lo que a simple vista parece lentitud es, en realidad, el mismo cuidado que evita que una red que mueve miles de millones de dólares adopte cambios sin el debate suficiente.

Esto no quiere decir que el time warp attack sea inofensivo mientras tanto. Sigue siendo una posibilidad real para quien tenga suficiente poder de minería, y eso obliga a la industria a asumir que ese riesgo sigue abierto. La diferencia es que ahora hay un camino concreto, con código ya aprobado, para cerrarlo.