```
  BIP: 95
  Layer: Applications
  Title: Testnet 5
  Authors: Pol Espinasa <polespinasa@protonmail.com>
           Fabian Jahr <fjahr@protonmail.com>
  Status: Draft
  Type: Specification
  Assigned: 2026-06-22
  License: CC0-1.0
  Discussion: 2026-06-02: https://groups.google.com/g/bitcoindev/c/kGUMTxOvdJA
  Version: 0.1.0
  Requires: 54
  Replaces: 94
```

## Abstract

Testnet 5 is a new test network intended to replace [Testnet 4][BIP94]. 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][BIP54] from block 1.

## Motivation

Testnet 4 included mitigations for an issue known as the [block storm attack][block-storms] 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][bitcointalk-thread]
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][signet-bip54] 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][BIP54] 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][BIP30] validation.

#### Rule Specification

See specification in [bip-0054][BIP54].

### 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: <code>03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e</code>
> * Pubkey: <code>000000000000000000000000000000000000000000000000000000000000000000</code>
> * Time stamp: 1714777860
> * Nonce: 393743547
> * Difficulty: <code>0x1d00ffff</code>
> * Version: 1
> 
> The resulting Genesis block hash is <code>00000000da84f2bafbbc53dee25a72ae507ff4914b867c565be350b0da8bf043</code>, and the block hex is <code> </code>.

### Message Start

The message start (also known as the network magic) is defined as <code>0x46495645</code>. 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][t4-discussion] 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

- [BIP 30][BIP30]: Duplicate transactions
- [BIP 54][BIP54]: Consensus Cleanup
- [BIP 94][BIP94]: Testnet 4
- [The block storms of Bitcoin's Testnet][block-storms]
- [Testnet 4 difficulty exception analysis and discussion (Bitcointalk)][bitcointalk-thread]
- [BIP 54 enforcement on signet via Bitcoin Inquisition][signet-bip54]
- [Discussion on changing the Testnet 4 rules (Bitcoin Core PR #31117)][t4-discussion]

[block-storms]: https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
[bitcointalk-thread]: https://bitcointalk.org/index.php?topic=5569103.0
[signet-bip54]: https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236
[t4-discussion]: https://github.com/bitcoin/bitcoin/pull/31117
[BIP30]: bip-0030.mediawiki
[BIP54]: bip-0054.md
[BIP94]: bip-0094.mediawiki

## Copyright

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.
