[BIP Draft] Testnet 5

121 views
Skip to first unread message

Pol Espinasa

unread,
Jun 2, 2026, 7:27:28 AM (yesterday) Jun 2
to bitco...@googlegroups.com
Dear list,

I am sharing a BIP draft for a new Testnet5.
People are complaining about Testnet4 being difficult to use, the new testnet also works as a miner playground for BIP54, we are killing two birds with one stone.

You can find the full text to read and comment on in the following draft PR: https://github.com/fjahr/bips/pull/2
Feel free to leave inline comments there or respond here on the list.


Pol
publickey - polespinasa@protonmail.com - 0x44205759.asc
signature.asc

José Edil Guimarães de Medeiros

unread,
Jun 2, 2026, 11:04:41 AM (yesterday) Jun 2
to Pol Espinasa, bitco...@googlegroups.com
Hey Pol,

Thanks for bringing this out.

Do you have more evidence of testnet4 being difficult to use? The Bitcoin talk thread seems to be a conversation between 3 or 4 people, not a generalized concern (at least for now). I mean, what are the specific use cases that worth looking in more detail to decide about this specific proposal tradeoffs?

I'm not trying to push back the proposal, but I feel that a new testnet without pow exceptions will very soon cause complaints of 1) coins being too difficult to mine without a lot of hash rate, and 2) moments when the chain doesn't progress because "big" miners just decided to point the machines elsewhere.

And if miners keep this new network quite stable, it's pretty reasonable to anticipate that non-negligible value will emerge for these coins and we are soon enough talking about reseting it (or spawning a new test network) again.

I wonder if the goal of having a clone of mainnet with worthless coins is even possible. 

--
Edil

On 2 Jun 2026, at 08:27, 'Pol Espinasa' via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:


--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/BrgqDZiNhpEz32-Z9ZX2rrPDE9EUIb62SKT2WsTo-yZtd3gLMLVk6TkO6kLIR96-87TumXqi92l_m1j3xlJr1tcJwG_I3UVDk2NZgXZL8fw%3D%40protonmail.com.
<publickey - poles...@protonmail.com - 0x44205759.asc>

Saint Wenhao

unread,
Jun 2, 2026, 11:05:11 AM (yesterday) Jun 2
to Pol Espinasa, bitco...@googlegroups.com
> I am sharing a BIP draft for a new Testnet5.

Interesting. Does it mean, that testnet4 fixes won't be done? https://batmanbytes.github.io/testnet4-softfork/

> For the Pubkey field, use a recent Bitcoin mainnet block hash.

Do you mean taking the hash of the block, and using it as x-value for a public key? Then, it could be potentially spendable, if it would be a valid secp256k1 point, and people would send more coins to it, or unspendable, if it would be outside of the curve. For example:

spendable: 0200000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
unspendable: 02000000000000000000013ac2955a2b6029bc1a86ab4b19e01e8030ceb0eeb2ae OP_CHECKSIG
unspendable: 00000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG

Also, if the size of the stack push would be different than 33 or 65 bytes, then it would be unspendable (for example if it would take 32 bytes, like block hashes, and would be followed by OP_CHECKSIG, to invalidate it, or if it would start with OP_RETURN).

> Difficulty: 0x1d00ffff

I wonder, how quickly it would be listed on exchanges, and traded. Because historically, new testnets were launched, when that happened. But today, new coins are listed faster, than they are replaced. Which would give the creator with any ASIC an incentive, to mine initial 30k or so blocks, keep them for a while, and then sell for BTCs, when the coin will be listed.

Also, I wonder if testnet5 will have any premine. Previous attempt to create testnet5: https://bitcointalk.org/index.php?topic=5543921

> Testnet 5 also does not apply the difficulty exception rule from Testnet 3 or Testnet 4 requires.

It would be nice to simplify the code, and remove that rule completely from sources, but it would probably take a while to deprecate testnet3 and testnet4.

--

Antoine Poinsot

unread,
Jun 2, 2026, 2:19:07 PM (yesterday) Jun 2
to José Edil Guimarães de Medeiros, Pol Espinasa, bitco...@googlegroups.com
Hi Edil,

Testnet4 is pretty obviously in a rough state. It is highly unstable due to min-difficulty rule exploits, which has severely hindered its adoption. You can see it for yourself by running a testnet4 node or looking at a block explorer, but here is a fork monitor screenshot Laolu shared last year:
image.png

It's true there is a risk that some miner ramps up the difficulty and leave, making the network more difficult (🥁) to use until it re-adjusts. However a risk that the network becomes temporarily unusable does not justify introducing yet another band-aid that would inevitably make it permanently unusable. Moreover, i think we are in a better position nowadays to deal with such a situation than we were 15 years ago when that happened on testnet1.

Best,
Antoine

Antoine Poinsot

unread,
Jun 2, 2026, 2:19:20 PM (yesterday) Jun 2
to Saint Wenhao, Pol Espinasa, bitco...@googlegroups.com
Hi,

On Tuesday, June 2nd, 2026 at 11:05 AM, Saint Wenhao <saint...@gmail.com> wrote:
> I am sharing a BIP draft for a new Testnet5.

Interesting. Does it mean, that testnet4 fixes won't be done? https://batmanbytes.github.io/testnet4-softfork/

I for one believe we are better off ripping the band-aid and starting fresh than trying to pile up more workarounds.

Garlo Nicon

unread,
Jun 2, 2026, 2:19:33 PM (yesterday) Jun 2
to Saint Wenhao, Pol Espinasa, bitco...@googlegroups.com
> coins being too difficult to mine without a lot of hash rate

It could be easily solved, if blocks with regular difficulty would replace the min-difficulty ones. Because the current rule forces all miners, with CPUs, GPUs, ASICs, or anything else, to produce a min-difficulty block after 20 minutes. However, there are many different ways to handle that. For example: after 20 minutes, block with any difficulty could be accepted, but could be reorged by stronger miners later. Then, the network would never be stuck.

Or: to discourage mining low-difficulty blocks, the amount of the coinbase could be adjusted, proportionally to the difficulty. You don't have hashpower, to mine a block with 1M difficulty, and receive 50 tBTC? No problem, mine million times easier block, get 5k tBTC for testing, and do your tests. If stronger miner will appear, they will have a chance to reorg you, but the same is true in testnet3 and testnet4.


> I wonder if the goal of having a clone of mainnet with worthless coins is even possible.

Currently, even signet coins are traded for mainnet BTCs, so probably not. By the way: I wonder, if there are any tests, where testnets like testnet3 or testnet4 are still needed. Because most things can be covered by regtest and signet. And if someone needs to test mining, then coins can be locked to a Proof of Work in many ways, and then, miners could claim them, by solving such puzzle. And it works even on mainnet, all you need is using OP_SIZE on a DER signature, to reach an arbitrary difficulty: https://github.com/adambor/btc-pow-locked-outputs/

So, are there any use cases, where testnet5 is needed, and signet cannot be used?

Pol Espinasa

unread,
Jun 2, 2026, 2:19:53 PM (yesterday) Jun 2
to Saint Wenhao, bitco...@googlegroups.com
Hi,


On Tuesday, June 2nd, 2026 at 5:02 PM, Saint Wenhao <saint...@gmail.com> wrote:

> > I am sharing a BIP draft for a new Testnet5.
>
> Interesting. Does it mean, that testnet4 fixes won't be done? https://batmanbytes.github.io/testnet4-softfork/

They won't (or at least it is not what we are proposing here), I agree with Antoine that a fresh start is better than just pile up workarounds.
Sometimes the cure is worse than the disease.

> > For the Pubkey field, use a recent Bitcoin mainnet block hash.
>
> Do you mean taking the hash of the block, and using it as x-value for a public key? Then, it could be potentially spendable, if it would be a valid secp256k1 point, and people would send more coins to it, or unspendable, if it would be outside of the curve. For example:
>
> spendable: 0200000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
> unspendable: 02000000000000000000013ac2955a2b6029bc1a86ab4b19e01e8030ceb0eeb2ae OP_CHECKSIG
> unspendable: 00000000000000000001799c6f72ebe5ebc6b18fd5cdf8bd3697b8d73d01b084 OP_CHECKSIG
>
> Also, if the size of the stack push would be different than 33 or 65 bytes, then it would be unspendable (for example if it would take 32 bytes, like block hashes, and would be followed by OP_CHECKSIG, to invalidate it, or if it would start with OP_RETURN).

yes, as per the original text in the draft: "the output is provably unspendable". The idea comes from: https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093516015, https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2095786951, https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2099974737


> > Difficulty: 0x1d00ffff
>
> I wonder, how quickly it would be listed on exchanges, and traded. Because historically, new testnets were launched, when that happened. But today, new coins are listed faster, than they are replaced. Which would give the creator with any ASIC an incentive, to mine initial 30k or so blocks, keep them for a while, and then sell for BTCs, when the coin will be listed.

That is a risk, but I personally don't think there is any real solution for that. It is impossible to avoid people selling coins.
I hope the risk of resetting the network or starting a new one (as we did multiple times, and we are suggesting here) is enough for coins to not have "much" value.

> Also, I wonder if testnet5 will have any premine. Previous attempt to create testnet5: https://bitcointalk.org/index.php?topic=5543921

It will not, using a mainnnet block hash in the Pubkey field acts as an anti-premine-commitment.

> > Testnet 5 also does not apply the difficulty exception rule from Testnet 3 or Testnet 4 requires.
>
> It would be nice to simplify the code, and remove that rule completely from sources, but it would probably take a while to deprecate testnet3 and testnet4.

I agree that might take time, but that is a node client implementation detail :)
publickey - polespinasa@protonmail.com - 0x44205759.asc
signature.asc

Pol Espinasa

unread,
Jun 2, 2026, 2:20:00 PM (yesterday) Jun 2
to Garlo Nicon, Saint Wenhao, bitco...@googlegroups.com

Hi Garlo,

So, are there any use cases, where testnet5 is needed, and signet cannot be used?"


Yes, as per the BIP text: "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."

You want to test the same software that you are aiming to run on mainnet, not a modified version that allows you to solve some PoW puzzles. Also, you want to test enforcement of consensus rules on block creation and validation, and check interaction with other nodes and miners.


Pol

publickey - polespinasa@protonmail.com - 0x44205759.asc
signature.asc

Edil Guimarães de Medeiros

unread,
5:57 PM (2 hours ago) 5:57 PM
to Antoine Poinsot, Pol Espinasa, bitco...@googlegroups.com
Hi Antoine,
 
However a risk that the network becomes temporarily unusable does not justify introducing yet another band-aid that would inevitably make it permanently unusable.

Agree.
 
Moreover, i think we are in a better position nowadays to deal with such a situation than we were 15 years ago when that happened on testnet1.

Yes, I expect some people to contribute some hash rate to unstuck a testnet5 chain (I would be willing to contribute), but I'm not so sure that will be enough.
Anyhow, I gave this scenario some thought and came to the conclusion that the odds of it happening (big miner increasing difficulty on purpose and leaving) would be pretty low.

Yet, it doesn't address the problem of coins getting value (which I still think is unsolvable given a pretty stable network).
Not the biggest concern to me, just that this will be an argument anytime soon.

--

Edil
Reply all
Reply to author
Forward
0 new messages