[BIP Draft] Testnet 5

[Pol Espinasa]

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

[José Edil Guimarães de Medeiros]

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]

> 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]

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:

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

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/286A17B7-9FAE-4FCD-A054-58688E797EE1%40gmail.com.

[Antoine Poinsot]

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.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOKGG1ht-2deT3jP81BzMrcqYd8tTL-tXeX-Z5sugUngJw%40mail.gmail.com.

[Garlo Nicon]

> 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?

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOKGG1ht-2deT3jP81BzMrcqYd8tTL-tXeX-Z5sugUngJw%40mail.gmail.com.

[Pol Espinasa]

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 :)

[Pol Espinasa]

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

[Edil Guimarães de Medeiros]

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

[Anthony Towns]

On Tue, Jun 02, 2026 at 11:24:18AM +0000, 'Pol Espinasa' via Bitcoin Development Mailing List wrote:
> 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.

+1 in general, but some notes:



This seems slightly contradictory:

a)

>> Testnet 5 follows the same consensus rules as mainnet with the following exception.
>>
>> ### BIP 54 activation
>>
>> The rules specified in [BIP 54 version 1.0.0][BIP54] are active on
>> Testnet 5 from Genesis.

b)

>> ### Consensus Rules
>>
>> All consensus rules active on mainnet as of May 2026 are enforced
>> from Genesis, the most recent of these being the Taproot softfork.

The "enforce BIP 54" part should just be under consensus rules, afaics.

I think "are active .. from Genesis" is perhaps not great, and the BIP
54 rules should apply to block 1 and above only? Otherwise, applying the
timestamp rule to block 0 per-BIP 54 doesn't seem coherent (it depends
on the timestamps of block -1 and block -2015), and the coinbase locktime
rule likewise would require setting the genesis block's locktime to -1.



>> the output is provably unspendable and it acts as an anti-pre-mine
>> commitment.

I'd argue that, economically, a pre-mine (or initial allocation/auction,
whatever you want to call it) is probably helpful for a testnet rather
than harmful, in that it provides a potentially large pool of coins that
can immediately be used for testing, and to suppress the scarcity/value
of mined coins. Not a blocker, just my opinion. Not pre-mining is probably
the most defensible position from a regulatory POV, however.

I think being demonstrably willing to regularly create new testnet
versions is probably also a good way of avoiding testnet coins becoming
particularly valuable/expensive; so even if the technical reasons for a
new testnet weren't compelling, that might be a good reason to do so on
its own. It's been about two years since testnet4 launched, which seems
like an okay cadence, if it were to actually become a regular thing.



Rather than dropping immediately to min-difficulty, having the difficulty
drop by 50% every 120 minutes or similar could be a reasonable approach
if it turns out, in practice that difficulty gets pushed very high by a
miner testing new hardware, then block creation stalls for a long period,
preventing difficulty from adjusting downward. Seems like something to
defer to testnet6, though. (Could perhaps also just grab the dynamic
difficulty adjustment logic that BCH/etc settled on, if something along
these lines is necessary)



>> - Other parameters (`Difficulty: 0x1d00ffff`, `Version: 1`) should
>> match Testnet 4.

That "difficulty" value is probably better described as "maximum target's
nBits", since it corresponds with "difficulty: 1" per "getblockheader".

Taking 0x1d00ffff as an integer gives ~486M compared with current
mainnet difficulty of ~138T, or testnet4's current difficulty of ~1239M,
so I think interpreting it as an actual difficulty wouldn't actually be
terrible, apart from perhaps rounding issues when converting it back to
the corresponding nBits.

However, I think with a low initial difficulty like this you get a
pre-mine in effect anyway. For example, if there's a single modern
antminer (U3S23H claims 1160TH/s) pointed at testnet5 initially, then,
only counting the hashing, it should take about 50 minutes to mine the
first 20k blocks (ie 400 blocks per second on average) and 1M tBTC,
pushing the difficulty up to 1M, and then another 2 days to mine the
next 3 retarget periods for another 6k blocks and 300k tBTC, pushing
difficulty up to 67M, after which blocks start taking more than a trivial
amount of time.

So I think increasing the minimum difficulty would make sense,
personally. Perhaps 0x1a0fffff for difficulty=1M or 0x1a00ffff for
difficulty=16M would make sense? At a difficulty of 1M you need about
6 BitAxe Gammas (at 1.2TH/s each) to keep the network at 10m/block,
at a difficulty of 16M you'd need ~100 BitAxe Gammas. At testnet4's
difficulty=1239M you need ~7400 BitAxe Gammas or ~30 S23's (at 305TH/s)
for comparison. BIP323 nVersion rolling plus potentially a couple of nTime
increments should be enough to get a valid hash at up to 16M difficulty,
I think.

If min difficulty were 16M, and the entire hashrate of testnet4 switched
over to testnet5 immediately, then blocks would initially come out every
8s, 31s, 124s and block spacing would be ~equalised against the 10 minute
target after about 4 days, 6048 blocks, and 300k tBTC. Min difficulty of
1M would make that take ~1h longer (with an initial phase of 0.5s blocks
then 2s blocks), adding 4032 blocks, and 200k tBTC to the pseudo-premine.

Cheers,
aj