184 lines
9.0 KiB
Markdown
184 lines
9.0 KiB
Markdown
```
|
||
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>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][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.
|