Delivery-date: Mon, 15 Apr 2024 11:01:32 -0700
Sender: bitcoindev@googlegroups.com
Date: Tue, 9 Apr 2024 23:57:23 -0700 (PDT)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en@googlegroups.com>
In-Reply-To: <ZgnVtJHn2ikLfwa9@petertodd.org>
References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
 <ZgmJFfXnQddkTQVq@petertodd.org>
 <CAFC_Vt7zKvMEfQLzWHQ6t_9bgv1iqt4Ah8N883CuoSfmLUKdMA@mail.gmail.com>
 <ZgnVtJHn2ikLfwa9@petertodd.org>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_3034_324913078.1712732243309"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_3034_324913078.1712732243309
Content-Type: multipart/alternative; 
	boundary="----=_Part_3035_1941323314.1712732243309"

------=_Part_3035_1941323314.1712732243309
Content-Type: text/plain; charset="UTF-8"

> 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 
have to get them from the current owners, by using regtest? If the 
difficulty is absolutely minimal, and every second nonce gives you a valid 
block hash, then you don't have to worry about your hashrate, because you 
can always produce a new block, and publish your tests, no matter what.

Also, if you have no difficulty adjustments, then you cannot realistically 
see your hashrate, even on your CPU. You have to apply a lot of soft-forks 
on regtest, if you want to check those cases. And you cannot test "getting 
coins from the current owners" either, because regtest is not safe enough 
to be deployed online, and you have to soft-fork it into signet, if you 
want to do so.

Which means, that if you want to test "how the network could behave after 
many halvings", then testnet3 is a better choice than regtest (which you 
cannot safely deploy online) or signet (which have less halvings than even 
mainnet).

And in general, I think it is a good idea, to have at least one test 
network, which will have more 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 about it now, then my conclusion is, that 
it would be nice, to even have a network, where timestamps are pushed 
forward, and for example we could see year 2038 or year 2106 problem in 
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: 
> > If we fix the difficulty reset bug, we might as well also fix the coin 
supply 
> > issue: get rid of the halving for testnet and just make every block 
create new 
> > coins. 
> 
> If such a change is made, then such a network won't be suitable to 
> test halvings and software behaviour related to halvings. 

I don't think that's very important. That's a very small part of what 
testnet 
is used for, and nothing stops people from using, say, regtest for that 
kind of 
testing. We already changed important consensus code around difficulty with 
testnet-specific behavior. 

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org 

-- 
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en%40googlegroups.com.

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

&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 coi=
ns, and you have to get them from the current owners, by using regtest? If =
the difficulty is absolutely minimal, and every second nonce gives you a va=
lid block hash, then you don't have to worry about your hashrate, because y=
ou can always produce a new block, and publish your tests, no matter what.<=
br /><br />Also, if you have no difficulty adjustments, then you cannot rea=
listically see your hashrate, even on your CPU. You have to apply a lot of =
soft-forks on regtest, if you want to check those cases. And you cannot tes=
t "getting coins from the current owners" either, because regtest is not sa=
fe 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 "how=
 the network could behave after many halvings", then testnet3 is a better c=
hoice than regtest (which you cannot safely deploy online) or signet (which=
 have less halvings than even mainnet).<br /><br />And in general, I think =
it is a good idea, to have at least one test network, which will have more =
halvings than the mainnet, so we can see in advance, what could happen, bef=
ore those problems will hit the main network. By the way, when I think abou=
t it now, then my conclusion is, that it would be nice, to even have a netw=
ork, where timestamps are pushed forward, and for example we could see year=
 2038 or year 2106 problem in some test network earlier, than on the mainne=
t.<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.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Sun, =
Mar 31, 2024 at 06:01:51PM -0300, Nagaev Boris wrote:
<br />&gt; &gt; If we fix the difficulty reset bug, we might as well also f=
ix the coin supply
<br />&gt; &gt; issue: get rid of the halving for testnet and just make eve=
ry block create new
<br />&gt; &gt; coins.
<br />&gt;=20
<br />&gt; If such a change is made, then such a network won't be suitable =
to
<br />&gt; test halvings and software behaviour related to halvings.
<br />
<br />I don't think that's very important. That's a very small part of what=
 testnet
<br />is used for, and nothing stops people from using, say, regtest for th=
at kind of
<br />testing. We already changed important consensus code around difficult=
y with
<br />testnet-specific behavior.
<br />
<br />--=20
<br /><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow">=
https://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org" tar=
get=3D"_blank" rel=3D"nofollow">petertodd.org</a>
<br /></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/dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/dd1f43b7-bd02-4fe4-9d69-2fa398c99b4en%40googlegroups.com</a>.=
<br />

------=_Part_3035_1941323314.1712732243309--

------=_Part_3034_324913078.1712732243309--