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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aiKYWu7Osn5hIJFP%40erisian.com.au.
