From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 02 Apr 2024 12:06:03 -0700 Received: from mail-yw1-f190.google.com ([209.85.128.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rrjSM-0003wH-9b for bitcoindev@gnusha.org; Tue, 02 Apr 2024 12:06:03 -0700 Received: by mail-yw1-f190.google.com with SMTP id 00721157ae682-60ab69a9e6fsf2294117b3.0 for ; Tue, 02 Apr 2024 12:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1712084756; x=1712689556; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=TDiIEl0ESXkGj6Hgg8OmsNmSQ57v+brXraYnjevww+M=; b=t4sJ3hsejzLcoCSBj+i7MfSfdBAUOX8qPg6P7U+YnFSdgXoTrGIW/p8GeEMmHTDQgE uJkurq2U8Ks/VtRTGjUEI/MvIjowGyYOFLFi+Ath7LiAxvUk6XSVDiUR2CoxbX1NFnfB bU/5cSKT/Uu4UBmdJbrY+vBeQ8inOoSKEe/LFo/iiUwERG0s9V7qyeAtw5UgDHHo4FV7 PBIKicasrl6TawEA+V64y7Hm5WK1PX3AMfP0selKYc14xnophVcKkD3OJcAkUHXstwjt sYWMZFlbqFyBN4Jp5tooePXnaN4VTlOeK7j59cQEndf4dmpg1/psdF5V1octY0wNgr1K I+lA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emsit.sk; s=google; t=1712084756; x=1712689556; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=TDiIEl0ESXkGj6Hgg8OmsNmSQ57v+brXraYnjevww+M=; b=Mh0FzrCEp4zcD3CYs7y1C+cnqG/ylYuxhknWVz5VLI8U+I98c8Sxlm+XcH2jrd/a9A TboV6CXzi/IZgU/qxwWAKmE1+580czxz6LbfKuDy2jr93V/J0C1Ahf6zrbGHmhcJbxUR TPH4bTaibZAqP0HMC03jCJW2IzVJ0P5Tf+tb72aUOCR2BZ33iFAcIZz18N+CYp02FLzs ozyF1vb5x4liWsAflz5ORMGIhg8Y2+VLZEK/+Ug0W99qyYnTgssGfaABdeXi8SqVbE+S CWEBBBBHcyEz2vw0FKEEHd5dKaF+6sO2QOv+hQB9jHUvSq+Ma3cnmDoFKggk6V6jeyEs Ip8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712084756; x=1712689556; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=TDiIEl0ESXkGj6Hgg8OmsNmSQ57v+brXraYnjevww+M=; b=LGirqacRZUDuDqEx1f8Xca/b5p5acDzLpUecNQlluXFd1IQJipTOuZYYRD2pFu49p5 tENG/yUY+0Q4iaZAqX4mYFNoQn/rXA5TvWj1Sfbcv8lsx1hhX204adY06L3KEt0VCQuJ sQFYD+A71BHptjAP+NlUta+XxGV5cxq0ex0Iogmc3ocpKa7NXLBlmjBrVqdIeGSDE0eX mn29eWuk12axtU5YnyZrjNM3tfMTCusgp1owuFEmeBuWjycG1a/0qslCE2/spjQr2sZ8 enIYQGszZ3wRZ/Dhd3IuzmIzLkc9v1Rtj1JvVmbaXCTrzCr1rY1e95Y91Kx+NLf54ls6 lFUg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCULjdzt3dSO3CVa57kDrAu5uM/xK8VIVjbnuh0gGr7IFDVcglz/XevXPcaQW7vRXNxBjybbvl0o9kwlb4Bc3TtvFuAmPK0= X-Gm-Message-State: AOJu0Yxfdhgc8t8rdW1iBWb4YlgN4/Cgky8it185iZFNImAiRpgYrrrM 1LkLJKHcwC8wY5qjzJkTja7SQXLJE6aaVjRJBhBU7f34jvXJLiji X-Google-Smtp-Source: AGHT+IHlTKcuIt34ameNRnk8+ShFPZlJ8JpzaudYuMVjXHjWaU7ln0KAfsv3DTOT6EqzxQ8o0O22jA== X-Received: by 2002:a25:ef51:0:b0:dc6:16b7:7d6f with SMTP id w17-20020a25ef51000000b00dc616b77d6fmr423957ybm.10.1712084755961; Tue, 02 Apr 2024 12:05:55 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:d3c3:0:b0:dcb:f35a:afeb with SMTP id e186-20020a25d3c3000000b00dcbf35aafebls2257530ybf.2.-pod-prod-06-us; Tue, 02 Apr 2024 12:05:55 -0700 (PDT) X-Received: by 2002:a05:6902:228f:b0:dd9:1702:4837 with SMTP id dn15-20020a056902228f00b00dd917024837mr4042904ybb.3.1712084755044; Tue, 02 Apr 2024 12:05:55 -0700 (PDT) Received: by 2002:a05:690c:3:b0:611:9f18:9d1 with SMTP id 00721157ae682-61431553f97ms7b3; Tue, 2 Apr 2024 11:36:46 -0700 (PDT) X-Received: by 2002:a05:6902:2588:b0:dda:d7cf:5c2c with SMTP id du8-20020a056902258800b00ddad7cf5c2cmr917144ybb.13.1712083005177; Tue, 02 Apr 2024 11:36:45 -0700 (PDT) Date: Tue, 2 Apr 2024 11:36:44 -0700 (PDT) From: =?UTF-8?Q?Luk=C3=A1=C5=A1_Kr=C3=A1=C4=BE?= To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE=@protonmail.com> Subject: Re: [bitcoindev] The Future of Bitcoin Testnet MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_449488_934096894.1712083004763" X-Original-Sender: emsit@emsit.sk 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.7 (/) ------=_Part_449488_934096894.1712083004763 Content-Type: multipart/alternative; boundary="----=_Part_449489_158414172.1712083004763" ------=_Part_449489_158414172.1712083004763 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think people will be very reluctant to give up testnet3, including=20 myself. I've been running a testnet3 faucet for 10 years, distributing=20 327197.44 tBTC via the faucet + a few thousand outside the faucet.=20 Resetting the testnet will mean the end for my faucet because I won't be=20 mining new coins anymore. People who have testnet3 will have to find a new= =20 way to obtain testnet4. Are there any official rules for when a testnet reset will occur? If I=20 understand correctly, it's being considered because of the "price" and the= =20 low mining reward? When testnet4 launches and starts trading in a month,=20 will testnet5 be launched shortly after...? I would focus more on how to keep it invaluable and easily accessible to=20 developers. I would definitely leave the transitional phase for at least a= =20 year, and the BTC client should have parameters for both -testnet3 and=20 -testnet4. Personally, *I think the adoption of testnet4 will be very slow*= . D=C3=A1tum: utorok 2. apr=C3=ADla 2024, =C4=8Das: 14:00:40 UTC+2, odosielat= e=C4=BE: Jameson Lopp > I think Andrew's difficulty rule suggestions are the least invasive and= =20 > make sense for fixing the block storm issue while keeping the code change= s=20 > to the logic that is already conditional to testnet. Though even with tho= se=20 > rules I think it would still be possible, though far less likely, for the= =20 > difficulty to get permanently reset very low unless we also implement the= =20 > difficulty adjustment patch Fabian mentioned. > > I suspect that creating a "fair" faucet is an unsolvable problem: the onl= y=20 > robust way to gate free giveaways (much like airdrops) is to impose an=20 > economic cost on claiming them, which is against the spirit of testnet. > > As emsit and I both noted, 13 years without a reset means that it would b= e=20 > courteous to give testnet operators a reasonably long heads up to prepare= .=20 > Perhaps 6 months or 1 year lead time? > > On Mon, Apr 1, 2024 at 6:06=E2=80=AFPM 'Fabian' via Bitcoin Development M= ailing=20 > List wrote: > >> Hi, >> >> removing the special rule and moving to a reduced block interval sounds= =20 >> like a good and simple solution. >> >> Another idea: Keep the current exception logic and adapt the difficulty= =20 >> adjustment code (`CalculateNextWorkRequired`) to look for the last block= =20 >> that didn't have difficulty 1 and use that block's difficulty as the bas= is=20 >> for the new difficulty calculation. It seemed like the most intuitive fi= x=20 >> to me when I looked at the code after reading Jameson's first email (see= =20 >> https://github.com/bitcoin/bitcoin/pull/29775/commits/9913549637706749f0= af5d326f949bd652cbd5f8 >> ). >> >> Best, >> Fabian >> >> >> >> On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra < >> apoe...@wpsoftware.net> wrote: >> >> > On Mon, Apr 01, 2024 at 01:37:59PM +0000, Pieter Wuille wrote: >> >=20 >> > > As for using other measures to prevent too large difficulty=20 >> variations... I'm not sure that's desirable, because it always cuts both= =20 >> ways (nicely demonstrated by the "allow difficulty 1 rule" on testnet3= =20 >> backfiring and enabling block storms!). For applications that actually n= eed=20 >> very predictable block rate, there is signet. For others, just the norma= l=20 >> mainnet rules are probably not too terrible. I would be ok with having a= =20 >> somewhat reduced block interval (say a few days instead of 2 weeks) if= =20 >> that's not deemed to complex to implement across the ecosystem, but I do= n't=20 >> think it's that important. >> >=20 >> >=20 >> > I really like this. For my part (rust-bitcoin) this would be as simple >> > as adding an extra parameter to my blockparams structure. Possibly one >> > already exists, I'd have to check. >> >=20 >> > This would be much easier than the existing situation where we have >> > special-case logic for testnet the difficulty-1 target. >> >=20 >> > It would also limit the amount of bikeshedding possible, since there >> > aren't too many conflicting goals regarding the retargeting window... >> > unlike tweaking the existing logic where there's a tradeoff between >> > "we should make this never happen" and "it should happen often enough >> > that it doesn't break people's code" and "it should happen if blocks >> > slow down to like, 1/50th their normal rate even if they are still >> > technically being produced" and "it shouldn't be possible to trigger >> > it within the 2-hour timestamp-faking window" etc. And questions >> > about whether we should fix/redesign the interaction between the reset >> > rule and the normal difficulty retarget. >> >=20 >> >=20 >> > OTOH, since we already have the special logic, I'd also be happy with >> > tweaking the existing rule. My specific proposal (after reading=20 >> Jameson's >> > post, which has some nice graphs of difficulty) would be >> >=20 >> > * increase the reset threshold from 20 minutes to 6 hours, which is >> > (a) well outside the 2-hour window in which miners can easily fake >> > timestamps, and (b) will basically never be hit by accident >> > * increase the reset difficulty from 1 to 1MM, which is an rough lower >> > bound on the "normal" testnet difficulty seen historically >> >=20 >> > Which puts us in the "this rule would never be triggered unless >> > literally everyone stopped mining" corner of the design space. >> >=20 >> >=20 >> > -- >> > Andrew Poelstra >> > Director of Research, Blockstream >> > Email: apoelstra at wpsoftware.net >> > Web: https://www.wpsoftware.net/andrew >> >=20 >> > The sun is always shining in space >> > -Justin Lewis-Webster >> >=20 >> > -- >> > You received this message because you are subscribed to the Google=20 >> Groups "Bitcoin Development Mailing List" group. >> > To unsubscribe from this group and stop receiving emails from it, send= =20 >> an email to bitcoindev+...@googlegroups.com. >> > To view this discussion on the web visit=20 >> https://groups.google.com/d/msgid/bitcoindev/ZgrCxWxMkiAt2Tg2%40camus. >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion on the web visit=20 >> https://groups.google.com/d/msgid/bitcoindev/06oL-GctrcLb99M_RuOgygXKMjt= B_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04U= QuvuE%3D%40protonmail.com >> . >> > --=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 on the web visit https://groups.google.com/d/msgid/= bitcoindev/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.com. ------=_Part_449489_158414172.1712083004763 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I think people will be very reluctant to give up t= estnet3, including myself. I've been running a testnet3 faucet for 10 years= , distributing 327197.44 tBTC via the faucet + a few thousand outside the f= aucet. Resetting the testnet will mean the end for my faucet because I won'= t be mining new coins anymore. People who have testnet3 will have to find a= new way to obtain testnet4.

Are there any official= rules for when a testnet reset will occur? If I understand correctly, it's= being considered because of the "price" and the low mining reward? When te= stnet4 launches and starts trading in a month, will testnet5 be launched sh= ortly after...?

I would focus more on how to ke= ep it invaluable and easily accessible to developers. I would definitely le= ave the transitional phase for at least a year, and the BTC client should h= ave parameters for both -testnet3 and -testnet4. Personally, I think the= adoption of testnet4 will be very slow.


D=C3=A1tum: utorok 2. apr=C3= =ADla 2024, =C4=8Das: 14:00:40 UTC+2, odosielate=C4=BE: Jameson Lopp
I = think Andrew's difficulty rule suggestions are the least invasive and m= ake sense for fixing the block storm issue while keeping the code changes t= o the logic that is already conditional to testnet. Though even with those = rules I think it would still be possible, though far less likely, for the d= ifficulty to get permanently reset very low unless we also implement the di= fficulty adjustment patch Fabian mentioned.

I suspect th= at creating a "fair" faucet is an unsolvable problem: the only ro= bust way to gate free giveaways (much like airdrops) is to impose an econom= ic cost on claiming them, which is against the spirit=C2=A0of testnet.

As emsit and I both noted, 13 years without a reset me= ans that it would be courteous to give testnet operators a reasonably long = heads up to prepare. Perhaps 6 months or 1 year lead time?

<= div class=3D"gmail_quote">
On Mon, Apr 1, 2024 at 6:06=E2=80=AFPM 'Fabian= 9; via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
Hi,=

removing the special rule and moving to a reduced block interval sounds lik= e a good and simple solution.

Another idea: Keep the current exception logic and adapt the difficulty adj= ustment code (`CalculateNextWorkRequired`) to look for the last block that = didn't have difficulty 1 and use that block's difficulty as the bas= is for the new difficulty calculation. It seemed like the most intuitive fi= x to me when I looked at the code after reading Jameson's first email (= see https://github.com/bitcoin/bitcoin/pull/29775= /commits/9913549637706749f0af5d326f949bd652cbd5f8).

Best,
Fabian



On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra <apoe...@wpsoftware.net> wrote:

> On Mon, Apr 01, 2024 at 01:37:59PM +0000, Pieter Wuille wrote:
>
> > As for using other measures to prevent too large difficulty varia= tions... I'm not sure that's desirable, because it always cuts both= ways (nicely demonstrated by the "allow difficulty 1 rule" on te= stnet3 backfiring and enabling block storms!). For applications that actual= ly need very predictable block rate, there is signet. For others, just the = normal mainnet rules are probably not too terrible. I would be ok with havi= ng a somewhat reduced block interval (say a few days instead of 2 weeks) if= that's not deemed to complex to implement across the ecosystem, but I = don't think it's that important.
>
>
> I really like this. For my part (rust-bitcoin) this would be as simple=
> as adding an extra parameter to my blockparams structure. Possibly one=
> already exists, I'd have to check.
>
> This would be much easier than the existing situation where we have > special-case logic for testnet the difficulty-1 target.
>
> It would also limit the amount of bikeshedding possible, since there > aren't too many conflicting goals regarding the retargeting window= ...
> unlike tweaking the existing logic where there's a tradeoff betwee= n
> "we should make this never happen" and "it should happe= n often enough
> that it doesn't break people's code" and "it should = happen if blocks
> slow down to like, 1/50th their normal rate even if they are still
> technically being produced" and "it shouldn't be possibl= e to trigger
> it within the 2-hour timestamp-faking window" etc. And questions<= br> > about whether we should fix/redesign the interaction between the reset=
> rule and the normal difficulty retarget.
>
>
> OTOH, since we already have the special logic, I'd also be happy w= ith
> tweaking the existing rule. My specific proposal (after reading Jameso= n's
> post, which has some nice graphs of difficulty) would be
>
> * increase the reset threshold from 20 minutes to 6 hours, which is > (a) well outside the 2-hour window in which miners can easily fake
> timestamps, and (b) will basically never be hit by accident
> * increase the reset difficulty from 1 to 1MM, which is an rough lower=
> bound on the "normal" testnet difficulty seen historically >
> Which puts us in the "this rule would never be triggered unless > literally everyone stopped mining" corner of the design space. >
>
> --
> Andrew Poelstra
> Director of Research, Blockstream
> Email: apoelstra at wpsoftware.net > Web: https://www= .wpsoftware.net/andrew
>
> The sun is always shining in space
> -Justin Lewis-Webster
>
> --
> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send= an email to bitcoindev+...@goog= legroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZgrCxW= xMkiAt2Tg2%40camus.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/06oL-GctrcLb99M_RuOgygXKMjtB= _vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQ= uvuE%3D%40protonmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.com.=
------=_Part_449489_158414172.1712083004763-- ------=_Part_449488_934096894.1712083004763--