Delivery-date: Wed, 24 Apr 2024 08:32:21 -0700
Sender: bitcoindev@googlegroups.com
Date: Sun, 21 Apr 2024 21:33:03 -0700 (PDT)
From: Ali Sherief <ali@notatether.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <664a3cd1-44d2-46d7-ae1a-2dca6f609b56n@googlegroups.com>
In-Reply-To: <dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en@googlegroups.com>
References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
 <ZgmJFfXnQddkTQVq@petertodd.org>
 <CAFC_Vt7zKvMEfQLzWHQ6t_9bgv1iqt4Ah8N883CuoSfmLUKdMA@mail.gmail.com>
 <ZgnVtJHn2ikLfwa9@petertodd.org>
 <dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en@googlegroups.com>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_397778_1438628905.1713760383903"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_397778_1438628905.1713760383903
Content-Type: multipart/alternative; 
	boundary="----=_Part_397779_216172030.1713760383903"

------=_Part_397779_216172030.1713760383903
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Regarding testing, It is important for it to be done with a deterministic=
=20
chain if you're building some kind of node.

But other things like wallets can easily mock the blockchain by having=20
lists of static blocks with specially crafted transactions in them. It=20
allows for things like signing to be tested without having to connect to=20
some live blockchain RPC interface that might fail for some reason.

-Ali

On Monday, April 15, 2024 at 6:01:25=E2=80=AFPM UTC Garlo Nicon wrote:

> > nothing stops people from using, say, regtest for that kind of testing.
>
> How can you test the scenario, where it is hard to get new coins, and you=
=20
> have to get them from the current owners, by using regtest? If the=20
> difficulty is absolutely minimal, and every second nonce gives you a vali=
d=20
> block hash, then you don't have to worry about your hashrate, because you=
=20
> can always produce a new block, and publish your tests, no matter what.
>
> Also, if you have no difficulty adjustments, then you cannot realisticall=
y=20
> see your hashrate, even on your CPU. You have to apply a lot of soft-fork=
s=20
> on regtest, if you want to check those cases. And you cannot test "gettin=
g=20
> coins from the current owners" either, because regtest is not safe enough=
=20
> to be deployed online, and you have to soft-fork it into signet, if you=
=20
> want to do so.
>
> Which means, that if you want to test "how the network could behave after=
=20
> many halvings", then testnet3 is a better choice than regtest (which you=
=20
> cannot safely deploy online) or signet (which have less halvings than eve=
n=20
> mainnet).
>
> And in general, I think it is a good idea, to have at least one test=20
> network, which will have more halvings than the mainnet, so we can see in=
=20
> advance, what could happen, before those problems will hit the main=20
> network. By the way, when I think about it now, then my conclusion is, th=
at=20
> it would be nice, to even have a network, where timestamps are pushed=20
> forward, and for example we could see year 2038 or year 2106 problem in=
=20
> some test network earlier, than on the mainnet.
>
> sunday, 31 march 2024 at 23:30:04 UTC+2 Peter Todd wrote:
>
> On Sun, Mar 31, 2024 at 06:01:51PM -0300, Nagaev Boris wrote:=20
> > > If we fix the difficulty reset bug, we might as well also fix the coi=
n=20
> supply=20
> > > issue: get rid of the halving for testnet and just make every block=
=20
> create new=20
> > > coins.=20
> >=20
> > If such a change is made, then such a network won't be suitable to=20
> > test halvings and software behaviour related to halvings.=20
>
> I don't think that's very important. That's a very small part of what=20
> testnet=20
> is used for, and nothing stops people from using, say, regtest for that=
=20
> kind of=20
> testing. We already changed important consensus code around difficulty=20
> with=20
> testnet-specific behavior.=20
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org=20
>
>

--=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/664a3cd1-44d2-46d7-ae1a-2dca6f609b56n%40googlegroups.com.

------=_Part_397779_216172030.1713760383903
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Regarding testing, It is important for it to be done with a deterministic c=
hain if you're building some kind of node.<div><br /></div><div>But other t=
hings like wallets can easily mock the blockchain by having lists of static=
 blocks with specially crafted transactions in them. It allows for things l=
ike signing to be tested without having to connect to some live blockchain =
RPC interface that might fail for some reason.</div><div><br /></div><div>-=
Ali<br /><br /></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"=
gmail_attr">On Monday, April 15, 2024 at 6:01:25=E2=80=AFPM UTC Garlo Nicon=
 wrote:<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;">&gt; =
nothing stops people from using, say, regtest for that kind of testing.<br>=
<br>How can you test the scenario, where it is hard to get new coins, and y=
ou have to get them from the current owners, by using regtest? If the diffi=
culty is absolutely minimal, and every second nonce gives you a valid block=
 hash, then you don&#39;t have to worry about your hashrate, because you ca=
n always produce a new block, and publish your tests, no matter what.<br><b=
r>Also, if you have no difficulty adjustments, then you cannot realisticall=
y see your hashrate, even on your CPU. You have to apply a lot of soft-fork=
s on regtest, if you want to check those cases. And you cannot test &quot;g=
etting coins from the current owners&quot; either, because regtest is not s=
afe enough to be deployed online, and you have to soft-fork it into signet,=
 if you want to do so.<br><br>Which means, that if you want to test &quot;h=
ow the network could behave after many halvings&quot;, then testnet3 is a b=
etter choice than regtest (which you cannot safely deploy online) or signet=
 (which have less halvings than even mainnet).<br><br>And in general, I thi=
nk it is a good idea, to have at least one test network, which will have mo=
re halvings than the mainnet, so we can see in advance, what could happen, =
before those problems will hit the main network. By the way, when I think a=
bout it now, then my conclusion is, that it would be nice, to even have a n=
etwork, where timestamps are pushed forward, and for example we could see y=
ear 2038 or year 2106 problem in some test network earlier, than on the mai=
nnet.<br><br><div><div dir=3D"auto">sunday, 31 march 2024 at 23:30:04 UTC+2=
 Peter Todd wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Mar 31, 202=
4 at 06:01:51PM -0300, Nagaev Boris wrote:
<br>&gt; &gt; If we fix the difficulty reset bug, we might as well also fix=
 the coin supply
<br>&gt; &gt; issue: get rid of the halving for testnet and just make every=
 block create new
<br>&gt; &gt; coins.
<br>&gt;=20
<br>&gt; If such a change is made, then such a network won&#39;t be suitabl=
e to
<br>&gt; test halvings and software behaviour related to halvings.
<br>
<br>I don&#39;t think that&#39;s very important. That&#39;s a very small pa=
rt of what testnet
<br>is used for, and nothing stops people from using, say, regtest for that=
 kind of
<br>testing. We already changed important consensus code around difficulty =
with
<br>testnet-specific behavior.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" rel=3D"nofollow" target=3D"_blank" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1713846610857000&amp;usg=3DAOvVaw0=
ZJvzkhfG-LS2KRIYDCc0M">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" rel=3D"nofollow" target=3D"_blank" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1713846610857000&amp;usg=3DAOvVaw3RsnuHlTosxr=
fS4G_RRiAQ">petertodd.org</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/664a3cd1-44d2-46d7-ae1a-2dca6f609b56n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/664a3cd1-44d2-46d7-ae1a-2dca6f609b56n%40googlegroups.com</a>.=
<br />

------=_Part_397779_216172030.1713760383903--

------=_Part_397778_1438628905.1713760383903--