From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 07 Jun 2026 15:02:28 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wWLZb-0006jm-IZ for bitcoindev@gnusha.org; Sun, 07 Jun 2026 15:02:28 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-440ec63f571sf6151527fac.0 for ; Sun, 07 Jun 2026 15:02:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1780869741; cv=pass; d=google.com; s=arc-20240605; b=KGz0WZ+tMKCNcYR0L/U4hnHP1k8WsWXNfA0NimcZiJzLGRRC+UiXeHA3CS7tmjBaSW 2RwKfV5B8P0VveZiMe6CBhZt5RFxuHnSIE/Onhy6EF7Kd50K8qOYg9nRHmYOmzaF4dFz ggc4Y3E8PaG4Q9CpWQRvK+5QtwrvnLo8rSQqSPIa4DNv7P+fM+waE6Z5/vF1XG0Dwj6P wp8mBBomAoj2LA1neWwXThCs2v5oQ2pOOILb0mV7jnbFt5AgO1itx00BaH158ZUORemt iXjM8ohZQ+w/M0D4HPKwbkAlYkBJP2IqDjQMLw/6rBzaJGogCYk6SuNl1BBWKmZPrWtr F33g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=5uwTtMgo/2VrvaHuYhm/6bqiqqE8KQlLlA1x3+oNMQc=; fh=xJyenzGN5822VEdgcmoSunXITPoiF96spA0X3jIXEW4=; b=Qvnvyn3LpXT6+6TUXxJDR6+hCeDVH8G2sm5rwANrFcGxk3Fy7iZwkFA8SYlq4pJpNh R2pXPjZAsc0mvACrHJqOyHhbgcrdV54Wb9o3fbLgakSWfJMr4DZ+fwE/3A3av/H0hT8h Xv0yVIZQ2Qds2QOvHxXPg0OiiVm7lhGTMohXKOYwsSYlMd3XJzz0TFjopC9EczBr5fIk uYM0iBaH0cqvzY/p5XJM3L22d16uxbujlOO6Yi8mGxCMChD9vycPvxpCFqM1+HYSojsn tU4ITbgh3hx7YcBZvwVymgBlasN9U7h/9G/4PBuB/5noPPyfv5exCVjVgSq+0yw64QFh BWkQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=XUQ61FRF; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.18 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780869741; x=1781474541; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=5uwTtMgo/2VrvaHuYhm/6bqiqqE8KQlLlA1x3+oNMQc=; b=mWFtCKlrYYvZ+Wwsr0Ovvi8spRQgWbkdoq7AHHlufQ0BGkqbWFm7RSTyp4JCHp8/24 oe2QWkiZBYS2LMZ/NWgTGTFp0WUAQmXhK4HMBdkeS0R0edipyppTRV5mZZV60LUjHwPv mDbPvkcP4GXR57ZZ+AplGwY1YWd3fJ8DAUc+qjmqWB0IYcXDOQnurF1Uc3QYzk23+AUQ 7lReRvAKsPDEeNddBiIWOqlsUx0bMi156yGN3eosdzUkU1uJTugk0CFvQqu/fkX2oly1 uDe9J4cfMtZF2nVI4PojedqbHPV66NfK69ThdedutHfvyRcrOd52L6FIQAQRmxPyMv7C 2y0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780869741; x=1781474541; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5uwTtMgo/2VrvaHuYhm/6bqiqqE8KQlLlA1x3+oNMQc=; b=EkwpQ9+pnhiEZAZN3PDDek49elaQVo8itjNmQ4Gani2PUvc/sP99uGYxJZ5cZ0bdtD FO8aHw1bNbgWwNt4ik2nJaCO2lTCchZQCCadY32NzGqKvViFdH4jr00Ug8ArOnMXIUR5 M+sar+FvNZA8rEwpKTF845JTN/gzTegZaC2Y4ZH6TIkFOzcUb8d3Cg6I8abQvz8US4Fs IpfNT94FfcEcDuHdixC/5hK8YPT0kDfVXv69zFzfYZuoNTLVAwy9Bzw25eRwKvEvhXNU CNG4njykDFc62Vu6tYzF/X5KW/NttrSV6/6ocdRIP8rZZ8G8VPo/0wUPCB4bUo4kygxR Z61w== X-Forwarded-Encrypted: i=2; AFNElJ+nnLxjaXE7M/Va6Iub8Tjeo3L0jWwCzHztNlP5V6y7+kW6I1JFeqifBmQbsTUsAHbzc2tKOXH0XqSS@gnusha.org X-Gm-Message-State: AOJu0YzKGPGGXA1Mo/+1JrmW1c5vXk1zc2PpT7r0AZ9ViOAda05VVwGt sILqMdF+25g4rSuUJ/An7dab2pE/DLPZeDc5U3lMScLdSer/uj2zmwS4 X-Received: by 2002:a05:6870:9348:b0:43c:33e6:275c with SMTP id 586e51a60fabf-44145dbb78dmr5101828fac.9.1780869741405; Sun, 07 Jun 2026 15:02:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUe/TAcsFEQ6oIp8UVeLGoLu3zbT9APPya7+29QQG6TZWg==" Received: by 2002:a05:6871:e90c:b0:43f:74af:be3c with SMTP id 586e51a60fabf-440d78d5e45ls1078909fac.0.-pod-prod-00-us-canary; Sun, 07 Jun 2026 15:02:16 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8J+0FF/v529J5hC8ASwAr5H6FewnwqnOvygvluGK58iiPZ7Zrqnvo7W88JtyA0QS4bNzHDUjlCW2z2@googlegroups.com X-Received: by 2002:a05:6808:1814:b0:486:3816:f40c with SMTP id 5614622812f47-486925fdb44mr5797680b6e.0.1780869736169; Sun, 07 Jun 2026 15:02:16 -0700 (PDT) Received: by 2002:ae9:e701:0:b0:915:741c:9c83 with SMTP id af79cd13be357-9159e1def8bms85a; Sun, 7 Jun 2026 14:52:11 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/IYAUSJWBxiNjS7SklVlIz5AwxkVdl2XMvEhyLJj2g80PGQHBlydlx96Prob1iyEpgkFdTgV2PsIyB@googlegroups.com X-Received: by 2002:a05:6102:ca:b0:6d7:a2b4:bedd with SMTP id ada2fe7eead31-7002b70dd8cmr2810294137.5.1780869130365; Sun, 07 Jun 2026 14:52:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780869130; cv=none; d=google.com; s=arc-20240605; b=R4xWPBZEf3f5cAseAnS+E+juJQH9prUATH5QymnNI+G1cQg27BqKpXnIhbDlkhdTVg jM6ALMeN6YvWyToTEoxBcfzx2u+pkU3zCugssYRNtgMo0K0Au8FQAbcwvIDkfcZZw661 WMyi0zmVF3A6qnkrAXapMhIRdsCpbuh4nWseFfL43FWrFX7xFP3v6CS8BBHFAHEolizB CI1fkh4cnMvHmhNXWAWiaT1A8uT/nczJwI61e+w9lPBRY7eplYvEUyXfAVgpZXlj2X3t ZXobrk0KZO2KixnZLoAw2Kvz+sYPTt/4xAkNE4gxUs4eGFqm+t2LbwVoIBqZmO6GUB2i tCjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=8prF9MdgW+G7yorcvNSu41dixc3J94ZqSUL9BbZiePo=; fh=nKfVWK04nAf3/Borto6HJdR+/lGnaANwhipRZz2lXFE=; b=Yu4RlvJfC0N/Ggc4MIoW+cCBD3OeJvfz7IByq3Q+vek8pJRfzdY6MR69GAMr5YUTU8 ZXiqjFMAmqr/BBlaZuqVYlqPePpEr8e3BReFtZqmryj1fNCZBGipRtb2HQRZfY6eAjo6 t5/hf9GowrGEiuIaSNDlwbVAdvSjxqW1yI2P9jVxskzdMCRuYF8KKLxUwvg3WEBETwAO 42PRpkkKYPg/hDsrU8npsMdeFjJ0PqyLvmOl1sBWSJHk6ixuVFhc7nb4TcpFFGbqO2RN OIxxN4HdwdGHAhpwF+YfwJaOCCbWsVpPdzw+XoInaJu5vWex7tQpbXHjKvpk1w7ImiSO TDZg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=XUQ61FRF; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.18 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-24418.protonmail.ch (mail-24418.protonmail.ch. [109.224.244.18]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-96413ec0ea9si535404241.1.2026.06.07.14.52.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jun 2026 14:52:10 -0700 (PDT) Received-SPF: pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.18 as permitted sender) client-ip=109.224.244.18; Date: Sun, 07 Jun 2026 21:52:03 +0000 To: Anthony Towns From: "'Fabian' via Bitcoin Development Mailing List" Cc: Pol Espinasa , "bitcoindev@googlegroups.com" Subject: Re: [bitcoindev] [BIP Draft] Testnet 5 Message-ID: In-Reply-To: References: Feedback-ID: 5067558:user:proton X-Pm-Message-ID: 20b928214d41964318dde17f668047c72e51afa5 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Original-Sender: fjahr@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=XUQ61FRF; spf=pass (google.com: domain of fjahr@protonmail.com designates 109.224.244.18 as permitted sender) smtp.mailfrom=fjahr@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Fabian Reply-To: Fabian Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) 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 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.