Bitcoin drafts a stricter testnet

A draft BIP published in the official Bitcoin Improvement Proposals repository proposes replacing testnet4 with a new network, testnet5. The central fact is specific: the proposal, opened on June 10, 2026 by Fabian Jahr and co-authored with Pol Espinasa, removes the difficulty exception that allowed test blocks to be mined at minimum difficulty after twenty minutes without a block. The authors argue that this rule, originally meant to keep testing accessible, is now being persistently exploited and has made testnet4 too unreliable.

A Bitcoin testnet is used by developers, wallets, payment services and researchers to try code without putting real bitcoin at risk. Its value therefore does not come from a token price, which should be meaningless, but from predictable behavior. If the chain often reorganizes its recent blocks, if block storms overload nodes, or if test coins become hard to obtain, the network stops being a useful rehearsal space. Testnet4 was already introduced to address abuse on testnet3, but its main compromise, the so-called twenty-minute rule, left an obvious manipulation surface.

The testnet5 draft chooses a stricter answer: make the test network behave much more like mainnet. In concrete terms, testnet5 would follow the same consensus rules as mainnet with two explicit differences. First, BIP54, the “consensus cleanup” proposal, would be active from block 1. That package of rules is intended to block the timewarp attack, reduce some worst-case validation behavior and limit historical weaknesses around Merkle trees, the data structure used to summarize the transactions in a block. Second, the minimum difficulty would be raised, with the maximum proof-of-work target encoded as 0x1a0fffff, corresponding to a minimum difficulty of roughly one million.

That choice has a trade-off: it reduces the usefulness of occasional CPU mining on testnet, which was one of the original reasons for the exception. The authors accept that shift. Their argument is that any predictable exception can be exploited by a motivated actor, while a useful Bitcoin test network should mainly reproduce the constraints that software will face on the real network. For teams maintaining nodes, libraries or wallets, the practical signal is straightforward: if the proposal moves forward, clients will need new network parameters, a new genesis block, a default P2P port and consensus handling that enforces BIP54 from the start. This is not a monetary upgrade, but a repair of the workshop where Bitcoin tests its future parts.