Home › Browse › BIP 95

BIP 95: Testnet 5

In plain English: Proposes Testnet 5 to replace Testnet 4, removing a special rule that let blocks be mined at minimum difficulty, which had been heavily abused. It also raises the minimum difficulty and applies the BIP 54 consensus cleanup rules from the start, aiming for a more stable test network.

Status
Draft
Type
Specification
Layer
Applications
Authors
Pol Espinasa, Fabian Jahr
Assigned
Last changed
Requires
BIP 54
Replaces
BIP 94
Topics
Consensus
Source
bip-0095.md on GitHub · Markdown

Abstract

Testnet 5 is a new test network intended to replace Testnet 4. Testnet 5 removes the difficulty exception defined in Testnet 4. Sustained exploitation of this exception has made the network difficult to use for testing. Additionally, Testnet 5 raises the minimum difficulty and enforces the consensus rules specified in BIP 54 from block 1.

Motivation

Testnet 4 included mitigations for an issue known as the block storm attack which could render the whole network unusable. Block storm attacks led to a depletion of block subsidies, which made it hard to acquire coins for testing. However, Testnet 4 still retained a modified version of the difficulty exception rule. The difficulty exception permits a block to be mined at the minimum difficulty when more than 20 minutes have passed since the previous block. Testnet 4 kept this exception with the aim of allowing CPU users a limited path to acquire coins for testing, to mine non-standard transactions that other miners would not relay, and to keep the chain moving if a large source of hash power were to leave the network. Shortly after Testnet 4's introduction, the exception had been systematically and persistently exploited, which prevented the exception from achieving the intended goals. While block storms were prevented, the network suffered from constant re-orgs of small numbers of blocks due to multiple difficulty-exception blocks competing for the tip. This led to discussion about changing Testnet 4 to mitigate this issue (see Bitcointalk for analysis and discussion).

In Testnet 5 there is no exception to the PoW rules. This appears to be the logical conclusion, since any such exception could be exploited by a motivated attacker. The lack of exception ensures the network’s behavior matches mainnet as closely as possible.

BIP 54 is already enforced on signet through Bitcoin Inquisition as of this BIP's creation. However, signet does not allow miners to test that their software reliably follows the rules of BIP 54. Testnet 5 provides a testing environment for this.

Specification

Testnet 5 follows the same consensus rules as mainnet, except for the following two changes.

BIP 54 activation

The rules specified in BIP 54 version 1.0.0 are active on Testnet 5 from block 1.

Problem Statement

BIP 54 proposes new consensus rules in order to fix several potential attack vectors. Namely it prevents the timewarp attack, reduces the worst-case block validation time, mitigates Merkle tree weaknesses, and avoids duplicate transactions without bip-0030 validation.

Rule Specification

See specification in bip-0054.

Minimum Difficulty

The proof-of-work limit (the maximum target) is 0x1a0fffff in compact encoding (nBits), corresponding to a minimum difficulty of approximately 1,000,000.

Consensus Rules

All consensus rules active on mainnet as of May 2026 are enforced from block 1, the most recent of these being the Taproot softfork. Additionally, the rules of BIP 54 are enforced from block 1, as specified above.

Genesis Block

TODO: Mine the block. The values below are placeholders inherited from Testnet 4. They are the genesis block's header fields together with the Message and Pubkey of its coinbase transaction. Notes for the miner:

  • Pubkey is the public key in the coinbase transaction's pay-to-public-key (P2PK) output. Use a recent Bitcoin mainnet block hash.[^pubkey-methodology]
  • Message is an arbitrary string in the coinbase input script, like the newspaper headline in Bitcoin's mainnet genesis block. Testnet 4 used it to carry the anti-pre-mine commitment, but Testnet 5 places that in the Pubkey instead, so the Message should be left empty, which also avoids bike shedding over its content.
  • Time stamp time of mining or that of the block which hash is used in Pubkey
  • nBits: 0x1a0fffff, per the raised minimum difficulty.
  • Version: 1

Testnet 4 placeholders:

  • Message: 03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e
  • Pubkey: 000000000000000000000000000000000000000000000000000000000000000000
  • Time stamp: 1714777860
  • Nonce: 393743547
  • Difficulty: 0x1d00ffff
  • Version: 1

The resulting Genesis block hash is 00000000da84f2bafbbc53dee25a72ae507ff4914b867c565be350b0da8bf043, and the block hex is 0100000000000000000000000000000000000000000000000000000000000000000000004e7b2b9128fe0291db0693af2ae418b767e657cd407e80cb1434221eaea7a07a046f3566ffff001dbb0c78170101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5504ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065ffffffff0100f2052a010000002321000000000000000000000000000000000000000000000000000000000000000000ac00000000.

Message Start

The message start (also known as the network magic) is defined as 0x46495645. These four bytes spell FIVE when interpreted as ASCII.

P2P Port

The default p2p port for Testnet 5 is 18335.

Rationale

Instead of starting a new Testnet, changing the rules of Testnet 4 was considered as well. The decision for a new network had two main reasons:

  1. Deploying network changes is hard and typically takes a long time. This effort doesn't seem to be worth it for a Testnet that has the alternative option to start fresh, especially considering that the attackers exploiting Testnet 4's rules may use them to prevent a smooth deployment of new rules, including those of BIP 54.
  2. Any fix to Testnet 4 that goes beyond a band-aid would require a hard fork, which brings its own implementation cost: adding hard-fork support to clients, handling the p2p layer correctly, etc. For a test network this isn't worth taking on, especially since a band-aid would only make Testnet 4 diverge further from mainnet.

Raising the minimum difficulty was dismissed for Testnet 4 because it would have prevented CPU miners from utilizing the difficulty exception. With the exception removed in Testnet 5, this argument no longer applies. A minimum difficulty of approximately 1,000,000 strikes a balance between dampening the quick mining of large numbers of blocks shortly after launch, before the difficulty has adjusted to the available hash power, and keeping a low barrier so that a handful of at-home miners or a single ASIC can keep the network usable.

Backward Compatibility

Testnet 5's consensus rules are not compatible with those of Testnet 3 and Testnet 4. The consensus rules differ in both directions: Testnet 5 enforces the BIP 54 consensus rules from block 1, which is not the case for Testnet 3 or Testnet 4. Testnet 5 also does not apply the difficulty exception rule that Testnet 3 or Testnet 4 requires.

Because each network has its own genesis block, their UTXO sets are disjoint and transactions can never be replayed across them. Address formats are shared, however, so the same address may be reused on different networks.

Any implementation that intends to follow Testnet 5 must add the new network parameters and additionally enforce the BIP 54 rules while not permitting any of the difficulty exception rules.

Reference Implementation

Pull request at ?

References

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Changelog

  • 0.1.0 (2026-06-02):
    • Initial draft

[^pubkey-methodology]: The Pubkey field is the public key placed in the coinbase transaction's output as a pay-to-public-key (P2PK) script. Setting it to a recent Bitcoin mainnet block hash serves two purposes: the resulting output is provably unspendable, and the referenced block hash acts as an anti-pre-mine commitment, since the genesis block cannot have been created before that mainnet block existed.

Related proposals

  • BIP 30: Duplicate transactions: Deployed. Added a rule forbidding a block from including a transaction with the same ID as an earlier one whose outputs are not fully spent. Such duplicates can overwrite earlier coins and make them…
  • BIP 34: Block v2, Height in Coinbase: Deployed. Upgraded blocks to version 2 and required each block's coinbase transaction (the one paying the miner) to include the block's height. This makes every coinbase unique, preventing duplicate…
  • BIP 42: A finite monetary supply for Bitcoin: Deployed. A tongue-in-cheek proposal fixing a software quirk that would have made the block reward reappear and coin issuance restart a couple of centuries from now. It ensures the roughly 21 million coin…
  • BIP 50: March 2013 Chain Fork Post-Mortem: Deployed. A post-mortem of the March 2013 incident in which a database limit in older Bitcoin software caused the blockchain to split temporarily. It explains what went wrong, how miners and developers…
  • BIP 54: Consensus Cleanup: Complete. Bundles fixes for several long-standing protocol weaknesses: the timewarp attack (manipulating block timestamps to speed up coin issuance), blocks that take extremely long to validate, Merkle tree…
  • BIP 62: Dealing with malleability: Closed. Proposed a set of rules to stop third parties from altering a transaction's ID without changing what it does, a problem called malleability. It was withdrawn after Segregated Witness (SegWit) solved…