Delivery-date: Tue, 02 Apr 2024 12:06:03 -0700
Sender: bitcoindev@googlegroups.com
Date: Tue, 2 Apr 2024 11:36:44 -0700 (PDT)
From: =?UTF-8?Q?Luk=C3=A1=C5=A1_Kr=C3=A1=C4=BE?= <emsit@emsit.sk>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <c1e32072-55ff-4cca-a56c-09c747e7e4a6n@googlegroups.com>
In-Reply-To: <CADL_X_dR1ENC9jm76azf_dkbJdeSCSBbPEpTkm71s4i-g_g=WA@mail.gmail.com>
References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
 <ZgmJFfXnQddkTQVq@petertodd.org>
 <CAFC_Vt7zKvMEfQLzWHQ6t_9bgv1iqt4Ah8N883CuoSfmLUKdMA@mail.gmail.com>
 <ZgnVtJHn2ikLfwa9@petertodd.org>
 <CADL_X_cmcXxHke089OD_45VRJy5aR+9uj-18bSjXBE7FKwR-Jw@mail.gmail.com>
 <wKrcm6SEjcG_7UmxByP-rDDVajB7-oYJRF9p_BjLe5XVzxVV9nCB8RsTAXcD5vF_rWxUmLK4HOM7zV7U4-kZSUO9Ccj4jEehsbbb7FD45GQ=@wuille.net>
 <ZgrCxWxMkiAt2Tg2@camus>
 <06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE=@protonmail.com>
 <CADL_X_dR1ENC9jm76azf_dkbJdeSCSBbPEpTkm71s4i-g_g=WA@mail.gmail.com>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_449488_934096894.1712083004763"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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 <bitco...@googlegroups.com> 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

<p style=3D"border: 0px solid rgb(227, 227, 227); box-sizing: border-box; m=
argin: 0px 0px 1.25em; color: rgb(13, 13, 13); font-family: S=C3=B6hne, ui-=
sans-serif, system-ui, -apple-system, &quot;Segoe UI&quot;, Roboto, Ubuntu,=
 Cantarell, &quot;Noto Sans&quot;, sans-serif, &quot;Helvetica Neue&quot;, =
Arial, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Seg=
oe UI Symbol&quot;, &quot;Noto Color Emoji&quot;; font-size: 16px; white-sp=
ace-collapse: preserve;">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.</p><p style=3D"border: 0px solid rgb(227, 227,=
 227); box-sizing: border-box; margin: 1.25em 0px; color: rgb(13, 13, 13); =
font-family: S=C3=B6hne, ui-sans-serif, system-ui, -apple-system, &quot;Seg=
oe UI&quot;, Roboto, Ubuntu, Cantarell, &quot;Noto Sans&quot;, sans-serif, =
&quot;Helvetica Neue&quot;, Arial, &quot;Apple Color Emoji&quot;, &quot;Seg=
oe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color Emoji&quot=
;; font-size: 16px; white-space-collapse: preserve;">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...?</p><p style=3D"border: 0px solid rgb(227, 227, 227); box-si=
zing: border-box; margin: 1.25em 0px 0px; color: rgb(13, 13, 13); font-fami=
ly: S=C3=B6hne, ui-sans-serif, system-ui, -apple-system, &quot;Segoe UI&quo=
t;, Roboto, Ubuntu, Cantarell, &quot;Noto Sans&quot;, sans-serif, &quot;Hel=
vetica Neue&quot;, Arial, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emo=
ji&quot;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color Emoji&quot;; font-s=
ize: 16px; white-space-collapse: preserve;">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, <b>I think the=
 adoption of testnet4 will be very slow</b>.</p><br /><div class=3D"gmail_q=
uote"><div dir=3D"auto" class=3D"gmail_attr">D=C3=A1tum: utorok 2. apr=C3=
=ADla 2024, =C4=8Das: 14:00:40 UTC+2, odosielate=C4=BE: Jameson Lopp<br/></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-=
left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr">I =
think Andrew&#39;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.<div><br></div><div>I suspect th=
at creating a &quot;fair&quot; 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.</div=
><div><br></div><div>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></div><br><=
div class=3D"gmail_quote"></div><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Mon, Apr 1, 2024 at 6:06=E2=80=AFPM &#39;Fabian&#3=
9; via Bitcoin Development Mailing List &lt;<a href data-email-masked rel=
=3D"nofollow">bitco...@googlegroups.com</a>&gt; wrote:<br></div></div><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,=
<br>
<br>
removing the special rule and moving to a reduced block interval sounds lik=
e a good and simple solution.<br>
<br>
Another idea: Keep the current exception logic and adapt the difficulty adj=
ustment code (`CalculateNextWorkRequired`) to look for the last block that =
didn&#39;t have difficulty 1 and use that block&#39;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&#39;s first email (=
see <a href=3D"https://github.com/bitcoin/bitcoin/pull/29775/commits/991354=
9637706749f0af5d326f949bd652cbd5f8" rel=3D"noreferrer nofollow" target=3D"_=
blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dsk&amp;q=3Dh=
ttps://github.com/bitcoin/bitcoin/pull/29775/commits/9913549637706749f0af5d=
326f949bd652cbd5f8&amp;source=3Dgmail&amp;ust=3D1712168389733000&amp;usg=3D=
AOvVaw0zp5HUkFOqdaT37PqkSnXa">https://github.com/bitcoin/bitcoin/pull/29775=
/commits/9913549637706749f0af5d326f949bd652cbd5f8</a>).<br>
<br>
Best,<br>
Fabian<br>
<br>
<br>
<br>
On Monday, April 1st, 2024 at 4:20 PM, Andrew Poelstra &lt;<a href data-ema=
il-masked rel=3D"nofollow">apoe...@wpsoftware.net</a>&gt; wrote:<br>
<br>
&gt; On Mon, Apr 01, 2024 at 01:37:59PM +0000, Pieter Wuille wrote:<br>
&gt; <br>
&gt; &gt; As for using other measures to prevent too large difficulty varia=
tions... I&#39;m not sure that&#39;s desirable, because it always cuts both=
 ways (nicely demonstrated by the &quot;allow difficulty 1 rule&quot; 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&#39;s not deemed to complex to implement across the ecosystem, but I =
don&#39;t think it&#39;s that important.<br>
&gt; <br>
&gt; <br>
&gt; I really like this. For my part (rust-bitcoin) this would be as simple=
<br>
&gt; as adding an extra parameter to my blockparams structure. Possibly one=
<br>
&gt; already exists, I&#39;d have to check.<br>
&gt; <br>
&gt; This would be much easier than the existing situation where we have<br=
>
&gt; special-case logic for testnet the difficulty-1 target.<br>
&gt; <br>
&gt; It would also limit the amount of bikeshedding possible, since there<b=
r>
&gt; aren&#39;t too many conflicting goals regarding the retargeting window=
...<br>
&gt; unlike tweaking the existing logic where there&#39;s a tradeoff betwee=
n<br>
&gt; &quot;we should make this never happen&quot; and &quot;it should happe=
n often enough<br>
&gt; that it doesn&#39;t break people&#39;s code&quot; and &quot;it should =
happen if blocks<br>
&gt; slow down to like, 1/50th their normal rate even if they are still<br>
&gt; technically being produced&quot; and &quot;it shouldn&#39;t be possibl=
e to trigger<br>
&gt; it within the 2-hour timestamp-faking window&quot; etc. And questions<=
br>
&gt; about whether we should fix/redesign the interaction between the reset=
<br>
&gt; rule and the normal difficulty retarget.<br>
&gt; <br>
&gt; <br>
&gt; OTOH, since we already have the special logic, I&#39;d also be happy w=
ith<br>
&gt; tweaking the existing rule. My specific proposal (after reading Jameso=
n&#39;s<br>
&gt; post, which has some nice graphs of difficulty) would be<br>
&gt; <br>
&gt; * increase the reset threshold from 20 minutes to 6 hours, which is<br=
>
&gt; (a) well outside the 2-hour window in which miners can easily fake<br>
&gt; timestamps, and (b) will basically never be hit by accident<br>
&gt; * increase the reset difficulty from 1 to 1MM, which is an rough lower=
<br>
&gt; bound on the &quot;normal&quot; testnet difficulty seen historically<b=
r>
&gt; <br>
&gt; Which puts us in the &quot;this rule would never be triggered unless<b=
r>
&gt; literally everyone stopped mining&quot; corner of the design space.<br=
>
&gt; <br>
&gt; <br>
&gt; --<br>
&gt; Andrew Poelstra<br>
&gt; Director of Research, Blockstream<br>
&gt; Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferre=
r nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.co=
m/url?hl=3Dsk&amp;q=3Dhttp://wpsoftware.net&amp;source=3Dgmail&amp;ust=3D17=
12168389733000&amp;usg=3DAOvVaw3-YCMSxAtgkQ0zgvvFtiuC">wpsoftware.net</a><b=
r>
&gt; Web: <a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noreferrer n=
ofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/u=
rl?hl=3Dsk&amp;q=3Dhttps://www.wpsoftware.net/andrew&amp;source=3Dgmail&amp=
;ust=3D1712168389733000&amp;usg=3DAOvVaw17ZLYOK9Gw23079DNLRH41">https://www=
.wpsoftware.net/andrew</a><br>
&gt; <br>
&gt; The sun is always shining in space<br>
&gt; -Justin Lewis-Webster<br>
&gt; <br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@goog=
legroups.com</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/d/msgid/bitcoindev/ZgrCxWxMkiAt2Tg2%40camus" rel=3D"noreferrer nofo=
llow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?=
hl=3Dsk&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/ZgrCxWxMkiAt2T=
g2%2540camus&amp;source=3Dgmail&amp;ust=3D1712168389733000&amp;usg=3DAOvVaw=
346aInNs2tZdJPo-o-dIfx">https://groups.google.com/d/msgid/bitcoindev/ZgrCxW=
xMkiAt2Tg2%40camus</a>.<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@googlegro=
ups.com</a>.<br></blockquote></div><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5=
wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%3D%40protonmail.com"=
 rel=3D"noreferrer nofollow" target=3D"_blank" data-saferedirecturl=3D"http=
s://www.google.com/url?hl=3Dsk&amp;q=3Dhttps://groups.google.com/d/msgid/bi=
tcoindev/06oL-GctrcLb99M_RuOgygXKMjtB_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKI=
JbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQuvuE%253D%2540protonmail.com&amp;sourc=
e=3Dgmail&amp;ust=3D1712168389733000&amp;usg=3DAOvVaw1OvcM-2pyusPgtDDOiDFns=
">https://groups.google.com/d/msgid/bitcoindev/06oL-GctrcLb99M_RuOgygXKMjtB=
_vPLHOCuc-axYrGVy_QBRGPu5wA9C2QXDb7cKIJbJu_t_JKmRrr9FsBORdUPavXPFvOi98p04UQ=
uvuE%3D%40protonmail.com</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/c1e32072-55ff-4cca-a56c-09c747e7e4a6n%40googlegroups.com</a>.=
<br />

------=_Part_449489_158414172.1712083004763--

------=_Part_449488_934096894.1712083004763--