BIP Draft: Testnet 5 #2196

fjahr commented at 11:47 AM on June 10, 2026: contributor

Following up from the discussion on the mailing list.

jonatack added the label New BIP on Jun 10, 2026

in bip-XXXX.md:28 in 1f0da5a9fe

  23 | +whole network unusable. This led to a depletion of block subsidies, which made it hard to acquire
  24 | +coins for testing. However, Testnet 4 still retained a modified version of the difficulty exception rule
  25 | +with the aim of allowing CPU users a limited path to acquire coins for testing, to mine non-standard
  26 | +transactions that other miners would not relay, and to keep the chain moving if a large source of hash
  27 | +power were to leave the network. Shortly after Testnet 4's introduction, the exception has been
  28 | +systematically and sustainably exploited, which prevented the exception from achieving the intended

murchandamus commented at 4:57 PM on June 11, 2026:

I think you mean that the exploit has been sustained continuously, but I’m not sure I would call the it "sustainable". ;)

systematically and persistently exploited, which prevented the exception from achieving the intended

or maybe:

systematically and continuously exploited, which prevented the exception from achieving the intended

fjahr commented at 12:23 PM on June 13, 2026:

Took "persistently" here.

in bip-XXXX.md:54 in 1f0da5a9fe

  49 | +
  50 | +#### Problem Statement
  51 | +
  52 | +BIP 54 proposes new consensus rules in order to fix several potential attack vectors. Namely 
  53 | +it prevents the timewarp attack, reduces the worst-case block validation time, prevents Merkle
  54 | +tree weaknesses, and avoids duplicate transactions without [bip-0030][BIP30] validation.

murchandamus commented at 5:00 PM on June 11, 2026:

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, mitigates Merkle
tree weaknesses, and avoids duplicate transactions without [bip-0030][BIP30] validation.

fjahr commented at 12:23 PM on June 13, 2026:

Done

in bip-XXXX.md:44 in 1f0da5a9fe outdated

  39 | +However, signet does not allow miners to test that their software reliably follows the rules of
  40 | +BIP 54. Testnet 5 provides a testing environment for this.
  41 | +
  42 | +## Specification
  43 | +
  44 | +Testnet 5 follows the same consensus rules as mainnet with the following two changes.

murchandamus commented at 5:01 PM on June 11, 2026:

I assume that this implies that segwit and taproot are also active starting from block 1, but perhaps that should be mentioned?

murchandamus commented at 5:04 PM on June 11, 2026:

Nevermind, I see that it is more explicitly mentioned below in Network Parameters. Perhaps Network Parameters should be a subsection of Specification, though?

fjahr commented at 12:23 PM on June 13, 2026:

I moved the Network Parameters section into Specification

in bip-XXXX.md:99 in 1f0da5a9fe outdated

  94 | +### Genesis Block
  95 | +
  96 | +TODO: Mine the block. The values below are placeholders inherited from Testnet 4. Notes
  97 | +for the miner:
  98 | +
  99 | +- For the `Pubkey` field, use a recent Bitcoin mainnet block hash. This single field then

murchandamus commented at 5:07 PM on June 11, 2026:

"Pubkey field" has not been introduced here?

murchandamus commented at 5:08 PM on June 11, 2026:

Perhaps add a line along the lines of the following to give the reader a sense what you’re about to talk about:

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

fjahr commented at 12:23 PM on June 13, 2026:

Added something of a clarification on this (see other comment).

fjahr commented at 12:23 PM on June 13, 2026:

I introduced something similar to clarify, but this part should be mostly removed when the actual Genesis block has been mined.

murchandamus commented at 6:10 PM on June 14, 2026:

It could perhaps be turned into a footnote to explain the methodology in case someone else wants to start the next testnet in a couple years.

in bip-XXXX.md:122 in 1f0da5a9fe

 117 | +> 
 118 | +> The resulting Genesis block hash is <code>00000000da84f2bafbbc53dee25a72ae507ff4914b867c565be350b0da8bf043</code>, and the block hex is <code>0100000000000000000000000000000000000000000000000000000000000000000000004e7b2b9128fe0291db0693af2ae418b767e657cd407e80cb1434221eaea7a07a046f3566ffff001dbb0c78170101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5504ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065ffffffff0100f2052a010000002321000000000000000000000000000000000000000000000000000000000000000000ac00000000</code>.
 119 | +
 120 | +### Message Start
 121 | +
 122 | +The message start is defined as <code>0x46495645</code>. These four bytes spell `FIVE` when

murchandamus commented at 5:10 PM on June 11, 2026:

Do you mean the “network magic”?

fjahr commented at 12:24 PM on June 13, 2026:

Yes, in Testnet 4 it is called Message Start which is the term used in the chainparams in Bitcoin Core. But I made a little change to also mention "network magic".

in bip-XXXX.md:86 in 1f0da5a9fe

  81 | +argument no longer applies. A minimum difficulty of approximately 1,000,000 strikes a balance
  82 | +between dampening the quick mining of large numbers of blocks shortly after launch, before the
  83 | +difficulty has adjusted to the available hash power, and keeping a low barrier so that a handful
  84 | +of at-home miners or a single ASIC can keep the network usable.
  85 | +
  86 | +## Network Parameters

murchandamus commented at 5:11 PM on June 11, 2026:

Aren’t the network parameters part of the specification?

fjahr commented at 12:24 PM on June 13, 2026:

I moved the Network Parameters section into Specification now

in bip-XXXX.md:150 in 1f0da5a9fe outdated

 145 | +[block-storms]: https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
 146 | +[bitcointalk-thread]: https://bitcointalk.org/index.php?topic=5569103.0
 147 | +[signet-bip54]: https://delvingbitcoin.org/t/bitcoin-inqusition-29-2/2236
 148 | +[BIP30]: bip-0030.mediawiki
 149 | +[BIP54]: bip-0054.md
 150 | +[BIP94]: bip-0094.mediawiki

murchandamus commented at 5:12 PM on June 11, 2026:

Since these references are all just link definitions, the References section currently appears empty in the rendered document.

fjahr commented at 12:24 PM on June 13, 2026:

Oh, I added a visible list here now as well.

in bip-XXXX.md:134 in 1f0da5a9fe

 129 | +## Backward Compatibility
 130 | +
 131 | +Testnet 5's consensus rules are not compatible with those of Testnet 3 and Testnet 4. The
 132 | +consensus rules differ in both directions: Testnet 5 enforces the BIP 54 consensus rules from
 133 | +block 1 which is not the case for Testnet 3 or Testnet 4. Testnet 5 also does not apply the
 134 | +difficulty exception rule from Testnet 3 or Testnet 4 requires.

murchandamus commented at 5:16 PM on June 11, 2026:

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.

fjahr commented at 12:24 PM on June 13, 2026:

Sure, I added a paragraph clarifying this.

in bip-XXXX.md:159 in 1f0da5a9fe outdated

 154 | +This document is licensed under the Creative Commons CC0 1.0 Universal license.
 155 | +
 156 | +## Changelog
 157 | +
 158 | +* __0.1.0__ (2026-06-02):
 159 | +    * Initial draft

murchandamus commented at 5:17 PM on June 11, 2026:

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.

fjahr commented at 12:24 PM on June 13, 2026:

I like to have a changelog now which lists the changes since the BIP PR was opened because people may read the version that was referenced in the mailing list post first and miss some changes that were made between that and the latest version here. So I added the version preamble.

murchandamus commented at 5:19 PM on June 11, 2026: member

Good first showing. I have left a few comments and suggestions.

BIP draft: Testnet 5 1677e2861f

fjahr force-pushed on Jun 13, 2026

in bip-XXXX.md:12 in 1677e2861f

   7 | +  Status: Draft
   8 | +  Type: Specification
   9 | +  Assigned: ?
  10 | +  License: CC0-1.0
  11 | +  Discussion: 2026-06-02: https://groups.google.com/g/bitcoindev/c/kGUMTxOvdJA
  12 | +  Version: 0.1.0

murchandamus commented at 5:52 PM on June 14, 2026:

I think the following two additional headers would make sense:

  Version: 0.1.0
  Requires: 54
  Replaces: 94

in bip-XXXX.md:17 in 1677e2861f

  12 | +  Version: 0.1.0
  13 | +```
  14 | +
  15 | +## Abstract
  16 | +
  17 | +A new test network with the goal of replacing [Testnet 4][BIP94]. Testnet 5 removes the difficulty

murchandamus commented at 5:56 PM on June 14, 2026:

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

in bip-XXXX.md:24 in 1677e2861f

  19 | +to use for testing. Additionally, Testnet 5 enforces the consensus rules specified in BIP 54 from block 1.
  20 | +
  21 | +## Motivation
  22 | +
  23 | +Testnet 4 included mitigations for an issue known as the [block storm attack][block-storms] which could render the
  24 | +whole network unusable. This led to a depletion of block subsidies, which made it hard to acquire

murchandamus commented at 5:57 PM on June 14, 2026:

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

whole network unusable. Block storm attacks led to a depletion of block subsidies, which made it hard to acquire

in bip-XXXX.md:25 in 1677e2861f

  20 | +
  21 | +## Motivation
  22 | +
  23 | +Testnet 4 included mitigations for an issue known as the [block storm attack][block-storms] which could render the
  24 | +whole network unusable. This led to a depletion of block subsidies, which made it hard to acquire
  25 | +coins for testing. However, Testnet 4 still retained a modified version of the difficulty exception rule

murchandamus commented at 6:00 PM on June 14, 2026:

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

in bip-XXXX.md:35 in 1677e2861f

  30 | +goals. While block storms were prevented, the network suffers from constant re-orgs of small
  31 | +numbers of blocks due to multiple difficulty-exception blocks competing for the tip. This led
  32 | +to discussion about changing Testnet 4 to mitigate this issue (see [Bitcointalk][bitcointalk-thread]
  33 | +for analysis and discussion).
  34 | +
  35 | +In Testnet 5 there is no exception to the PoW rules. This appears to be the logical conclusion,

murchandamus commented at 6:04 PM on June 14, 2026:

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.

in bip-XXXX.md:76 in 1677e2861f

  71 | +
  72 | +### Genesis Block
  73 | +
  74 | +TODO: Mine the block. The values below are placeholders inherited from Testnet 4. They are
  75 | +the genesis block's header fields together with the `Message` and `Pubkey` of its coinbase
  76 | +transaction. Notes for the miner:

murchandamus commented at 7:13 PM on June 14, 2026:

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.

murchandamus commented at 7:19 PM on June 14, 2026:

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

murchandamus commented at 7:14 PM on June 14, 2026: member

Good improvements, thanks for the quick response. I gave this another read: