BIP Draft: Testnet 5#2196
Conversation
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Good first showing. I have left a few comments and suggestions.
| 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 sustainably exploited, which prevented the exception from achieving the intended |
There was a problem hiding this comment.
I think you mean that the exploit has been sustained continuously, but I’m not sure I would call the it "sustainable". ;)
| systematically and sustainably exploited, which prevented the exception from achieving the intended | |
| systematically and persistently exploited, which prevented the exception from achieving the intended |
or maybe:
| systematically and sustainably exploited, which prevented the exception from achieving the intended | |
| systematically and continuously exploited, which prevented the exception from achieving the intended |
| it prevents the timewarp attack, reduces the worst-case block validation time, prevents Merkle | ||
| tree weaknesses, and avoids duplicate transactions without [bip-0030][BIP30] validation. |
There was a problem hiding this comment.
It doesn’t "prevent" the Merkle tree weaknesses, but rather it doesn’t allow the weakness to be exploited. Perhaps:
| it prevents the timewarp attack, reduces the worst-case block validation time, prevents Merkle | |
| tree weaknesses, and avoids duplicate transactions without [bip-0030][BIP30] validation. | |
| 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. |
|
|
||
| ## Specification | ||
|
|
||
| Testnet 5 follows the same consensus rules as mainnet with the following two changes. |
There was a problem hiding this comment.
I assume that this implies that segwit and taproot are also active starting from block 1, but perhaps that should be mentioned?
There was a problem hiding this comment.
Nevermind, I see that it is more explicitly mentioned below in Network Parameters. Perhaps Network Parameters should be a subsection of Specification, though?
| TODO: Mine the block. The values below are placeholders inherited from Testnet 4. Notes | ||
| for the miner: | ||
|
|
||
| - For the `Pubkey` field, use a recent Bitcoin mainnet block hash. This single field then |
There was a problem hiding this comment.
"Pubkey field" has not been introduced here?
| TODO: Mine the block. The values below are placeholders inherited from Testnet 4. Notes | ||
| for the miner: | ||
|
|
||
| - For the `Pubkey` field, use a recent Bitcoin mainnet block hash. This single field then |
There was a problem hiding this comment.
Perhaps add a line along the lines of the following to give the reader a sense what you’re about to talk about:
| - For the `Pubkey` field, use a recent Bitcoin mainnet block hash. This single field then | |
| The following information is included in the Genesis block coinbase transaction’s coinbase field: | |
| - For the `Pubkey` field, use a recent Bitcoin mainnet block hash. This single field then |
|
|
||
| ### Message Start | ||
|
|
||
| The message start is defined as <code>0x46495645</code>. These four bytes spell `FIVE` when |
There was a problem hiding this comment.
Do you mean the “network magic”?
| 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. | ||
|
|
||
| ## Network Parameters |
There was a problem hiding this comment.
Aren’t the network parameters part of the specification?
| ## References | ||
|
|
||
| [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 |
There was a problem hiding this comment.
Since these references are all just link definitions, the References section currently appears empty in the rendered document.
| 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 from Testnet 3 or Testnet 4 requires. |
There was a problem hiding this comment.
Maybe also make it clear for newer readers:
They use different genesis blocks, so their UTXO sets will be unique, and it is infeasible for any transactions to ever be replayable across these networks. Since output scripts look are compatible, addresses could be reused across these networks.
| ## Changelog | ||
|
|
||
| * __0.1.0__ (2026-06-02): | ||
| * Initial draft |
There was a problem hiding this comment.
Nit: Changelog is only necessary if there are changes to a BIP after it has been advanced to Complete, but it is of course allowed to have one from the get-go.
However, if you do have a Changelog, please include the corresponding Version header in the preamble.
3 participants
Following up from the discussion on the mailing list.