From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 09 Jun 2026 16:09:57 -0700 Received: from mail-oi1-f191.google.com ([209.85.167.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wX5a0-0000xx-Jc for bitcoindev@gnusha.org; Tue, 09 Jun 2026 16:09:57 -0700 Received: by mail-oi1-f191.google.com with SMTP id 5614622812f47-486660d2abasf7283280b6e.2 for ; Tue, 09 Jun 2026 16:09:56 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1781046590; cv=pass; d=google.com; s=arc-20240605; b=ijzfoRStpRLeZbE36TVFyTJ42Q9qxfc/dTKBzw4bZeOxWcD0oMcAUpJf24iRbZfJF2 GeVH7TAtzywlKhxUmFb/RB29lltc+9tZCGl+Np1RvTjSYj/G4ZyD8A+Ow2ARX0ldIrOb nnaWuKLP3bdkI9MytmQFn0xgt4CPt660CG5iSh6QszkNw9n+MdqbKQxUpL46VyawgBFd SQdwLRG1ZTRQhWIkhXawTqUSc/fO1511BTkxi2JiBdth3DXCaegZuAk85gnX4hzN3xBS kMT2F6ueM4DWXoYjuQMV0NkxRSNkXcRr3YcdcZjVY/yAplDNb3KgzoffUpJTo+/6u3n3 070w== 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:content-transfer-encoding :in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:dkim-signature; bh=aGJfV0LF++1MuIxyEf+876hh1485jj15fLMtxJTfNNU=; fh=Iit4cRK28eDgFyoLM/u6BmUU0GbQtplmNadhqr250Lo=; b=KtB1Agy4Flvfo6y4eeQttiNlIXXjtY6H2PCpnEpU3cZ0JmOw44Q4NF5ItB5ReLoH/S RV2jD1w/dd6RPrdjQ3ctJLKEYjzNV1ARJoks5TI+XdWcvYxoOD8JYw8/q59dCN1VJw5+ x0DTbkuJEG4ua0p//OJI31/GyYI+66KIv9jPbITx24dHz7U/OYYUe0vGJAGdchb/xKrJ Lf1w/+L9F5X7+yalvGGsemY7ElxjPbpm7Q85S7NTMZRwbHBj2BSY7Bj4ws0GPMuxBoJ5 WMBr0RkPeLKhGOjXW2u3PgPa8cXwwKywxzSZAggpV06rV8qtuiw7LrfyIh4LP8hJjUVf b/YA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=OMmpFTmz; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1781046590; x=1781651390; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=aGJfV0LF++1MuIxyEf+876hh1485jj15fLMtxJTfNNU=; b=LBVSFGWsJqQOx1ask2LxVl3dBcS7nf6B3m6YrJMquRW+IcECvKsZO5mIeE9eMNI1PA Zbr3/K/bU8Az7LvIXYuOpNpJ2j3i5IE0IfvK9xbozMgK7/Gud40mAJk+P/A1Gu9yPyii biHj1EHiCm0tlxp+MUYHMP2Tc464aoE9394NN93rhtDc7Cqaord5jEyPnMB3A2YFgHkL czAPUf3QeqsXIMTRXQGmHgT3NZ8j9hE3fsVN04lAWBfbxOLO/Ar+YLwOKWGC22XidqGP zl5gkYWX/qTnPfeLOyCUKfw26qB4/Ua2qC45Z4jzpL5M/qyyuLIlm3odbVaT+v5Vx5hj P92Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781046590; x=1781651390; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=aGJfV0LF++1MuIxyEf+876hh1485jj15fLMtxJTfNNU=; b=kWztEyTOvX1Nt6NOLGXRHoH5Wukt6FyQ1IvH9x4pMU3pKFsnF+3mNwQFkPEUrgC3rp Nj3XD/H2VPRPx9edkJ91ChseJGzuhHH/YZ7PCsGom7LMW2go8TvZogY5CHrkR0n7WgZe UGD8b3445tJnkh1pfMJFr/lFy4jdLq426fga6uyspHwqbZpghCSdM7YqwcUlnbVOfL1u 7+jfaaYdLdxhuWa5rWLVhhVKqqpl+TQwPnkjDp1C7n2h6zgQXqvlVB9kvRMKJYSoAQ0t c9O8xS9hxVUrlO2B5Tln/ODoaayQRhxKHM+1vqNuUYhEEP6e+Kw1fyuLZSBlz3OqmI8L +IxA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ/mzt/tl90xaSDklTpHK1ewNN+NJLKtMi6Sg3b84bM2B57QOZgv/ryp9VPNRrUlJ6upWUpJvOfG5dg3@gnusha.org X-Gm-Message-State: AOJu0Ywic4EsoyiG0KguV32/nDyf6EiN/jml9RGoll5M1V4XLEfy4L4y L9VcfhSFl62TSKWiroZLWBPfGF9yHXAkFZ5RP9eak4g0Dzt/rpOG4QSC X-Received: by 2002:a05:6808:1792:b0:479:2ef3:50a5 with SMTP id 5614622812f47-4868dc03b43mr14239973b6e.7.1781046590301; Tue, 09 Jun 2026 16:09:50 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AX0PUUdvWuT2nbyIFOJbZbjxNgKIe39uHzbgz7krMP0b83nSnw==" Received: by 2002:a05:6870:3ec:b0:43d:b8f:a6db with SMTP id 586e51a60fabf-44109906aa5ls3115417fac.1.-pod-prod-08-us; Tue, 09 Jun 2026 16:09:44 -0700 (PDT) X-Received: by 2002:a05:6808:1b09:b0:479:fc87:27ee with SMTP id 5614622812f47-4868dc00f20mr13216183b6e.1.1781046584360; Tue, 09 Jun 2026 16:09:44 -0700 (PDT) Received: by 2002:ab3:5087:0:b0:2e5:dca6:8eb2 with SMTP id a1c4a302cd1d6-3045428eb04msc7a; Tue, 9 Jun 2026 14:54:05 -0700 (PDT) X-Received: by 2002:a05:6512:39d4:b0:5a8:dc4e:477a with SMTP id 2adb3069b0e04-5aa88667378mr4525420e87.8.1781042043456; Tue, 09 Jun 2026 14:54:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781042043; cv=none; d=google.com; s=arc-20240605; b=NkoBOXW8DtXeU7ms+SeAyVsSNtbGQsTK8XkGVZzWgCW9KxGT3sBrD1ifOg+ZoU2So+ hY0aiOQSUZmbkgbP2JESQUqyJfx9FGyVffalpZ8Xh1eOz673MVnecOV6JDUqEIy1k3Ez zb8fNDNDC2nZIIrZYGCXQNmGd+Dz5TOd/gthNMCWCrdXp9esnikux5SU26RT0X89r3zC j4v71cztAiH6jeJP7bAr63lifQvyRpjOmo5fY7BnZoa2qIa6dpC5+56bRHYC5Jw7q96E gJhTYUKvy8/vEi0a0faqRJKzUpbKa8D4wG2/lWic+FEvDTj0Gvp6TYEs7GGoVVMMzkIr 6mLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=dkim-signature:content-transfer-encoding:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id; bh=+IRXBYxA95mf9gbzSEDED41fgIBDjAg1VpBrAagSTD8=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=LYGVTl+SU4GoRnk0K+qL28+Aq8vdUIlB5wdAGrdBUQhSKlUyR752RvDx9YUX1zfeys g0iuQBNhAqrLdsA8icDeBUo+zpxzfcYzfU1+fJoH5F3tcs3PjjrtXcF0uLZUCGdxQ1w0 2k9cVPXk9a868O92/Uty1Yd3bZ+kUI27lKM3e2eH7V15ZDkT7aVaL+Le9gUa3b34Kh0t d3NSsUq2xBLjvUSWzwP+9wdjId/PGgthj4ivc5qIZNS+YRyqXspmaNc4EOsZo6yF7F6T TlK1nV4NWRssQ/n+8MhdJ3UtXemO3t1ztu2/7vrrIUaIGm0BGfQB1yaVu7oLKlHhnRNb zDaw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=OMmpFTmz; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one Received: from mailgate02.uberspace.is (mailgate02.uberspace.is. [2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5aa7b97233bsi398392e87.4.2026.06.09.14.54.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2026 14:54:03 -0700 (PDT) Received-SPF: pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) client-ip=2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4; Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235]) by mailgate02.uberspace.is (Postfix) with ESMTPS id ADA8018016F for ; Tue, 09 Jun 2026 23:54:02 +0200 (CEST) Received: (qmail 22466 invoked by uid 989); 9 Jun 2026 21:54:02 -0000 Received: from unknown (HELO unknown) (::1) by farbauti.uberspace.de (Haraka/3.1.1) with ESMTPSA; Tue, 09 Jun 2026 23:54:02 +0200 Message-ID: Date: Tue, 9 Jun 2026 14:53:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [bitcoindev] [BIP Draft] Testnet 5 To: bitcoindev@googlegroups.com References: Content-Language: en-US From: Murch In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: --- X-Rspamd-Report: BAYES_HAM(-3) XM_UA_NO_VERSION(0.01) MIME_GOOD(-0.1) X-Rspamd-Score: -3.09 X-Original-Sender: murch@murch.one X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@murch.one header.s=uberspace header.b=OMmpFTmz; spf=pass (google.com: domain of murch@murch.one designates 2a00:d0c0:200:0:1c7b:a6ff:fee0:8ea4 as permitted sender) smtp.mailfrom=murch@murch.one 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: -0.8 (/) Hi Fabian and Pol, It sounds like your proposal is already getting some interest and=20 improvement suggestions. Please feel free to open a PR when you=E2=80=99re = happy=20 with your initial draft. Cheers, Murch On 2026-06-07 14:52, 'Fabian' via Bitcoin Development Mailing List wrote: > 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=3D1M or 0x1a00ffff for >> difficulty=3D16M 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 Dev= elopment Mailing List wrote: >>> I am sharing a BIP draft for a new Testnet5. >>> People are complaining about Testnet4 being difficult to use, the new t= estnet 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 followi= ng 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 locktim= e >> 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 probab= ly >> 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 difficult= y >> 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 trivia= l >> amount of time. >> >> So I think increasing the minimum difficulty would make sense, >> personally. Perhaps 0x1a0fffff for difficulty=3D1M or 0x1a00ffff for >> difficulty=3D16M 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=3D1239M you need ~7400 BitAxe Gammas or ~30 S23's (at 305TH/s= ) >> for comparison. BIP323 nVersion rolling plus potentially a couple of nTi= me >> 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 minut= e >> 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 Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/aiKYWu7Osn5hIJFP%40erisian.com.au. >> --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= ed49cb11-f7f7-4385-8b87-b5192385b06d%40murch.one.