Re: [bitcoindev] [BIP Draft] Testnet 5

["'Fabian' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>]

Hi AJ,

Thanks for the detailed feedback! Pol and I have coordinated on the
main points below and I have just pushed an update to the draft
accordingly.

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

I agree that this was contradictory. The Specification now no longer
frames BIP 54 as an exception but as a change relative to mainnet,
and the Consensus Rules section now mentions BIP 54 as well. I kept
the BIP 54 section under Specification since it is the main thing
the BIP describes and without it there would not really be a
Specification section which seems to contradict BIP 3 which makes the
section mandatory.

> I think "are active .. from Genesis" is perhaps not great, and the
> BIP 54 rules should apply to block 1 and above only?

Right, it now says "from block 1" throughout.

> 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

I see the potential upside you are referring to but think it is
outweighed but bigger issues in practice. Any sort of pre-mine
would invite controversy and could create unnecessary headaches
for those involved that nobody is keen to take on. And this seems
unavoidable no matter how big the logistical effort would be to
distribute these coins as fairly as possible. As you say, not
pre-mining is the most defensible position so we are not going
to take this on.

> Rather than dropping immediately to min-difficulty, having the
> difficulty drop by 50% every 120 minutes or similar could be a
> reasonable approach

May be worth exploring if Testnet 5 runs into these issues but would
also introduce additional complexity which is why we are deferring
it to a potential future testnet as you suggested yourself.

> That "difficulty" value is probably better described as "maximum
> target's nBits"

Fixed, the field is now labeled nBits.

> So I think increasing the minimum difficulty would make sense,
> personally. Perhaps 0x1a0fffff for difficulty=1M or 0x1a00ffff for
> difficulty=16M would make sense?

We adopted 0x1a0fffff (~1M) in the draft now. This was discussed in
Testnet 4 already but collided with the difficulty exception which
had more conceptual support at the time. We preferred 1M over 16M
since it already significantly dampens quick mining of large numbers
of blocks shortly after launch while a handful of at-home miners or
a single (older) ASIC can still keep the network usable. It seems
to strike a good balance.

Fabian


On Friday, June 5th, 2026 at 12:27 PM, Anthony Towns <aj@erisian.com.au> wrote:

> 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
> 
> --
> 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+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aiKYWu7Osn5hIJFP%40erisian.com.au.
> 

-- 
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/DJs9JYTbROCHQIg0XGSnLLI1edzOYp0i3i96a_YFXuxqmhZq8nYyhHq5_upeVXcu-gPiOZHMzChmCOSBVe3kOk5pdlxDYWNFvtRy5JX89bo%3D%40protonmail.com.