Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
170 changes: 170 additions & 0 deletions bip-XXXX.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,170 @@
```
BIP: ?
Layer: Applications
Title: Testnet 5
Authors: Pol Espinasa <polespinasa@protonmail.com>
Fabian Jahr <fjahr@protonmail.com>
Status: Draft
Type: Specification
Assigned: ?
License: CC0-1.0
Discussion: 2026-06-02: https://groups.google.com/g/bitcoindev/c/kGUMTxOvdJA
Version: 0.1.0

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the following two additional headers would make sense:

Suggested change
Version: 0.1.0
Version: 0.1.0
Requires: 54
Replaces: 94

```

## Abstract

A new test network with the goal of replacing [Testnet 4][BIP94]. Testnet 5 removes the difficulty

@murchandamus murchandamus Jun 14, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: The abstract starts on a sentence fragment without a verb.

exception defined in Testnet 4. Sustained exploitation of this exception has made the network difficult
to use for testing. Additionally, Testnet 5 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][block-storms] which could render the
whole network unusable. This led to a depletion of block subsidies, which made it hard to acquire

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It’s ambiguous whether "this" refers to the mitigations or the block storms.

Suggested change
whole network unusable. This led to a depletion of block subsidies, which made it hard to acquire
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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since much of this paragraph discusses the issues with the difficulty exception, perhaps it should be briefly explained.

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 has been
systematically and persistently exploited, which prevented the exception from achieving the intended
goals. While block storms were prevented, the network suffers 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,

@murchandamus murchandamus Jun 14, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just had a random thought that I was wondering whether it was considered:

What would happen if blocks mined with the difficulty exception would be forbidden from collecting the subsidy (i.e., could only collect fees)? That would permit users to get blocks if the difficulty had run up, or to mine non-standard transactions, but would remove the incentive to mine blocks for collecting the subsidy. It would not prevent people from creating low-difficulty blocks to deny others from getting them and it might be more complicated than just dropping the exception, though.

since any such exception could be exploited by a motivated attacker. This
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 with the following two changes.
Comment thread
fjahr marked this conversation as resolved.

### 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:
Comment on lines +74 to +76

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a look at BIP94 in regard to the meaning of these two fields. It seems to me that the pubkey field is also only implicitly explained there. Looking at the construction, it seems to me that the pubkey field takes the place of the previous block hash in the block header, is that right? I was unable to find out where the message field goes. I thought it would appear in the coinbase field of the coinbase transaction, but I could not find the message string either forward or backward in the block hex.
I would recommend that it be explicitly explained where the pubkey and message field appear in the construction.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oooh. Does pubkey go into the P2PK output script? Still confused about the message, though.


- For the `Pubkey` field, use a recent Bitcoin mainnet block hash. This single field then
Comment thread
fjahr marked this conversation as resolved.
Comment thread
fjahr marked this conversation as resolved.
serves two purposes: the output is provably unspendable and it acts as an anti-pre-mine
commitment. This is different from what Testnet 4 did (empty Pubkey and block hash in
message) but this is actually more elegant and was only suggested by Sjors after the
final Genesis block for Testnet 4 was already mined.
- `Message` content is up for suggestions but keeping it empty would prevent bike shedding
- `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>0100000000000000000000000000000000000000000000000000000000000000000000004e7b2b9128fe0291db0693af2ae418b767e657cd407e80cb1434221eaea7a07a046f3566ffff001dbb0c78170101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5504ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065ffffffff0100f2052a010000002321000000000000000000000000000000000000000000000000000000000000000000ac00000000</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 as well. The decision
for a new network has 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]

[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
[BIP30]: bip-0030.mediawiki
[BIP54]: bip-0054.md
[BIP94]: bip-0094.mediawiki
Comment thread
fjahr marked this conversation as resolved.

## Copyright

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

## Changelog

* __0.1.0__ (2026-06-02):
* Initial draft
Comment thread
fjahr marked this conversation as resolved.