BIP95: Testnet 5 #2196

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

Took "persistently" here.

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.

Done

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

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

I moved the Network Parameters section into Specification

"Pubkey field" has not been introduced here?

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

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

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

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.

Ok, using a footnote now and adding the intention for the methodology which is a bit slimmer so it's good to keep around after the block has been added.

Do you mean the “network magic”?

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".

Aren’t the network parameters part of the specification?

I moved the Network Parameters section into Specification now

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

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

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.

Sure, I added a paragraph clarifying this.

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.

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.

I think the following two additional headers would make sense:

  Version: 0.1.0
  Requires: 54
  Replaces: 94

Done

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

Changed

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

Fixed

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

I was thinking that people could hop over to BIP94 for the details but I added another sentence to give a short explainer.

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.

Yet another band-aid fix, I fear. Way better off fresh and "right" from the start.

There are other ways to earn coins besides Block Rewards, using a difficulty exploit. Perhaps even more disruptive.

I also agree with the more complicated.

What would happen if blocks mined with the difficulty exception would be forbidden from collecting the subsidy (i.e., could only collect fees)?

Then, coins will be burned, and ASIC miners will have an incentive to reorg them. To prevent that, additional coins could be simply timelocked to some future block number, then stronger miners won't have an incentive to reorg them, and will simply collect them later instead.

Anyway, the idea to decrease the coinbase reward, proportionally to the Proof of Work in the block header, is not new. But it makes things more complicated, and there are other ways, like pay to Proof of Work scripts, which could be used to achieve the same things, without messing up with consensus rules.

Also, the scenario, where the chain would halt, because of not enough miners, could happen on the mainnet as well, so it would be good, if test network would behave in a similar way, to let someone try to deal with that problem, and prepare a solution for mainnet as well.

It's an interesting idea but I agree that it would be adding more complexity while this proposal is partly motivated by removing complexity. And I also think that while it may remove part of the incentive in the form of the subsidy, since this is basically free to exploit, there will still be people trying to do this just for the fees or to mess with the network for fun.

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.

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

I guess it could be just some x-value pubkey, equal to the mainnet block hash. For example: https://mempool.space/address/0200000000000000000001ae18e25b101d485505283d8d8e67771e1d865acbfece (and then, getting the private key for the Genesis Block would be impossible, if the secp256k1 point would be invalid, or would be as hard, as breaking secp256k1, if it would turn out to be a valid point, like 04 00000000000000000001AE18E25B101D485505283D8D8E67771E1D865ACBFECE 0E007A49956DB6EF8251FADDB106C649250FD5E5EEE9E875C88F62EACF3473D4 is in this case).

@murchandamus Right, see the footnote change I made, I hope that makes it clear enough. I also added details to explain the message. Since a future Testnet creator wouldn't need to use this mechanism of commitment at all anymore, I think it's fine to not do another footnote on it and remove it when the genesis block is added, but I can be convinced otherwise if people think it's interesting to keep the historical context around.

Thanks, looks good!

Testnet 3 never became unusable for users or especially for the "whole network"... on the contrary, confirmations came in much faster, and made using certain services easier. My testnet service did better during blockstorms for users (100 confirmations didn't take days).

Some services that had preexisting problems (expected in testing) had problems, but many did not. The ones who had issues have more Twitter followers.

What the blockstorm did was drain the block reward from miners, rendering mining basically useless. I agree with this.

Testnet 3 never became unusable for users or especially for the "whole network"

If someone with a capable machine just mines min-difficult blocks with maximum speed deactivates the mempool, the network is unusable because nobody would get their transactions in other than mining a real difficulty block. What user facing wallet would not have a problem with that?

Testnet3 didn't face min block miners purposely mining empty blocks.

Testnet3 was attacked by Lopp doing blockstorms and they included transactions.

I'm just stating the facts of what did happen. I'm not sure what could have happened.

I'd be totally happy to provide historical blockchain evidence if you'd like.

Also, I believe the "capable machine" causing the Testnet4 issues is or was a BitAxe. It's more about how the machine is used than about its ability when gamesmanship is involved.

So then why write this comment at all? The text already says that this could happen, not that it did happen.

I wrote this comment so future contributors and interested individuals have historical facts to work with, rather than design proposals engineered around an imaginary situation that didn't actually happen.

Yes, Lopp was probably still being nice when he demonstrated block storms, doesn't mean that this need to be misinterpreted as block storms being less of a problem.

I do agree it was a problem (several called it a "feature" at first). However, I think development documentation should lean toward historical facts rather than "if" and "probably."

Lopp wasn't acting out of niceness or direct financial testnet incentive, and the empty blocks on Testnet 4 aren't due to someone being mean—they are purely driven by financial incentives. The two attack vectors shouldn't be blended together.

Anyways, no need to respond. Thank you for not deleting these facts and taking them into consideration so that this important documentation can convey the facts of how we got here and not fiction.

  BIP: 95

Done

  Assigned: 2026-06-22

Done

after Testnet 4's introduction, the exception had been systematically and persistently exploited, which

Done

s/suffers/suffered/

Done

Mildly ambiguous subject.

since any such exception could be exploited by a motivated attacker. The lack of exception

Done

Testnet 5 follows the same consensus rules as mainnet, except for the following two changes.

Done

for a new network had two main reasons:

Done

block 1, which is not the case for Testnet 3 or Testnet 4. Testnet 5 also does not apply the

Done

Perhaps link to discussion in https://github.com/bitcoin/bitcoin/pull/31117 somewhere in this BIP.

Instead of starting a new Testnet, changing the rules of Testnet 4 [was considered](https://github.com/bitcoin/bitcoin/pull/31117) as well. The decision

Done

Note that a reference implementation and test vectors (if applicable) would be needed before advancing the status from Draft to Complete.

Noted, will follow-up here

Should the link to BIP54 be present on the first mention of the BIP (Line 22 under Abstract)?

Done