-
Notifications
You must be signed in to change notification settings - Fork 6k
BIP Draft: Testnet 5 #2196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
BIP Draft: Testnet 5 #2196
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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 | ||||||
| ``` | ||||||
|
|
||||||
| ## Abstract | ||||||
|
|
||||||
| A new test network with the goal of replacing [Testnet 4][BIP94]. Testnet 5 removes the difficulty | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
|
||||||
| coins for testing. However, Testnet 4 still retained a modified version of the difficulty exception rule | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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, | ||||||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||||||
|
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
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oooh. Does |
||||||
|
|
||||||
| - For the `Pubkey` field, use a recent Bitcoin mainnet block hash. This single field then | ||||||
|
fjahr marked this conversation as resolved.
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 | ||||||
|
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 | ||||||
|
fjahr marked this conversation as resolved.
|
||||||
There was a problem hiding this comment.
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: