mirror of
https://github.com/bitcoin/bips.git
synced 2026-11-09 19:47:16 +00:00
Anthony Towns
69ec29d518
This moves the anti-pre-mine commitment back into `pszTimestamp` and keeps it as ASCII text, rather than using it as a fake public key. The genesis transaction's output is replaced by an `OP_RETURN` to avoid confusion over spendability. Using the `OP_RETURN` output and `nVersion` rolling for additional nonce bits are explicitly allowed.
188 lines
8.9 KiB
Markdown
188 lines
8.9 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.3.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. They are
|
||
the genesis block's header fields together with the `Message` and
|
||
`scriptPubKey` of its coinbase transaction. Notes for the miner:
|
||
|
||
- `scriptPubKey` is the script public key in the coinbase transaction's
|
||
output. It is `OP_RETURN` followed by a push of 8-bytes of extranonce
|
||
space, as it is unspendable in any event, and this avoids bike shedding
|
||
over its content.
|
||
- `Message` is a string in the coinbase input script, and carries a
|
||
recent Bitcoin mainnet block hash as an anti-pre-mine commitment,
|
||
serving the same purpose as the newspaper headline in Bitcoin's mainnet
|
||
genesis block.
|
||
- `Time stamp` is the time of mining or that of the block which hash is
|
||
used in `Message`
|
||
- `nBits` is `0x1a0fffff`, per the raised minimum difficulty.
|
||
- `Version` is used for version-rolling to meet the difficulty.
|
||
|
||
Placeholders:
|
||
|
||
> (Note, these values have the wrong nBits value (too low difficulty) and are pre-mined so are not suitable for use)
|
||
>
|
||
> * Message: "2026-11-03 974343 00000000000000000000a86d6da2c1563d08668d9ec18cce58cb8c865d4a31c8"
|
||
> * scriptPubKey: <code>0x6a089763e96a00000000</code>
|
||
> * Time stamp: 1793680278
|
||
> * Nonce: <code>0x73ba1699</code>
|
||
> * nBits: <code>0x1b07fff8</code>
|
||
> * Version: <code>0x201c4000</code>
|
||
>
|
||
> The resulting Genesis block hash is <code>000000000001bd3ade1e24d07c1a3677d4868c34f2f1696fa419e3b9f061b1e0</code>, and the block hex is <code>00401c200000000000000000000000000000000000000000000000000000000000000000de48bbaa869592873fc4e5042f2931f9b42bb7e8ddeccd373df845d80983409b9663e96af8ff071b9916ba730101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5b04ffff001d01044c52323032362d31312d3033203937343334332030303030303030303030303030303030303030306138366436646132633135363364303836363864396563313863636535386362386338363564346133316338ffffffff0100f2052a010000000a6a089763e96a0000000000000000</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 `18353`.
|
||
|
||
## 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 [Bitcoin Core #35861](https://github.com/bitcoin/bitcoin/pull/35861)
|
||
|
||
## 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.3.0__ (2026-11-05):
|
||
* Move commitment back to scriptSig, and use `OP_RETURN` for output.
|
||
* __0.2.0__ (2026-11-05):
|
||
* Change default P2P port from 18335 to 18353
|
||
* __0.1.0__ (2026-06-02):
|
||
* Initial draft
|
||
|