Bitcoin Core Prepares a Defense Against an Old Difficulty Adjustment Attack

• PR #35949 was merged on September 7, 2026, into Bitcoin Core.
• The change corrects how the template for the last block of each period is assembled.

Bitcoin Core, the reference software for the Bitcoin network, changed on September 7 how miners prepare one of the blocks for each period. The adjustment is the work of developer Fabian Jahr.

This is a preliminary step towards a larger future correction. For now, no network rules have changed: only the software that assembles the blocks before they are mined has been adjusted.

The correction targets an old and well-known flaw: the so-called time warp attack. It is a trick that would allow someone with a lot of mining power (hashrate) to cheat with the timestamps of the blocks.

Each Bitcoin block carries a timestamp. If a miner could systematically falsify that timestamp, they could deceive the network into believing that less time than actual has passed between blocks. This would artificially lower the mining difficulty, and with a lower difficulty, that miner would win blocks faster than they should, taking rewards away from other miners.

The fact that this error remains uncorrected more than a decade after it was identified is not negligence. Changing a consensus rule in Bitcoin requires that almost the entire network—miners, exchanges, those running a node—agree and are ready at the same time. That collective agreement, more than the technical difficulty, is what takes years to build.

That’s why the solution does not tackle this problem alone, but alongside three other old flaws in Bitcoin's original design. The proposal that groups them is called BIP54 and aims to correct, all at once: the time warp attack, blocks designed to be slow to validate, an ambiguity in Merkle trees that could be used to falsify transaction proofs, and a negligence that would allow the duplication of coinbase transactions (the one created when mining the block). Grouping these four corrections prevents the network from having to go through the lengthy agreement process once for each one.

What the New Change Specifically Corrects

The change discussed in this note is documented in pull request 35949 of the official Bitcoin Core repository, and it specifically addresses the first of those four problems: the time warp attack. The other three—slow-to-validate blocks, ambiguity in Merkle trees, and duplicated coinbase transactions—still do not have an equivalent software change as of now.

Let’s imagine that a miner's computer clock is misconfigured and shows a time earlier than the actual time. Before this change, if that happened just when preparing the last block of a difficulty period, the software could get stuck.

It would miscalculate the minimum allowed time and fail to assemble a valid block for mining. In practice, that miner would be unable to work until their clock corrected itself.

Fabian Jahr, the author of the change, explained in the repository itself that this scenario is unlikely on the main Bitcoin network because it would require a very large clock error. It is more common in test networks, where conditions are less stable.

Even so, Bitcoin Core preferred to resolve it before it became a real problem. With the new code, when a node's clock is behind, the software itself sets the correct time for the block proposal, instead of getting stuck. This adjustment is already functioning on the main network and on test networks, although BIP54 itself is still not active on any.

Why Bitcoin Corrects Its Errors So Slowly

This case shows a pattern that is rarely seen from the outside: those who develop Bitcoin Core do not correct consensus flaws all at once. They first prepare the software that works "around" the rule—in this case, mining—and only afterward, if there is enough community support, do they activate the underlying change.

That order has a simple reason: if the new rule were activated without the mining software being ready, avoidable problems would arise, such as nodes suddenly being unable to mine due to a simple clock error. Developers prefer to clean up those details before asking the entire network to take a step that cannot be undone.

The history of BIP54 itself confirms that patience. The idea was born in 2019, from Matt Corallo, and was kept on hold for years until Antoine Poinsot picked it up in 2023, as noted in the proposal text published in the Bitcoin BIPs repository. What may seem like slowness at first glance is, in reality, the same care that prevents a network moving billions of dollars from adopting changes without sufficient debate.

This does not mean that the time warp attack is harmless in the meantime. It remains a real possibility for anyone with sufficient mining power, and that forces the industry to acknowledge that this risk remains open. The difference is that now there is a concrete path, with approved code already, to close it.

This content is provided for general informational purposes only and doesn't constitute financial, investment, legal, or tax advice. Any events, rewards, online promotions, or related information mentioned herein should not be considered a recommendation, solicitation, or invitation to purchase, sell, trade, or otherwise deal in any crypto assets. Crypto assets are highly volatile and may result in loss. The availability of WEEX services, products, and related events may vary by region. You are responsible for ensuring that your participation is in accordance with applicable local laws and regulations.