path: root/4c/13d9046069ea1dc92d140b98ec576c2e95bf90

Delivery-date: Wed, 24 Apr 2024 08:32:21 -0700
Received: from mail-yw1-f189.google.com ([209.85.128.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCQ6HM7U3YGRB7GLUSYQMGQE6HSDNPI@googlegroups.com>)
	id 1rzebc-00025Y-I9
	for bitcoindev@gnusha.org; Wed, 24 Apr 2024 08:32:21 -0700
Received: by mail-yw1-f189.google.com with SMTP id 00721157ae682-61b57c7b151sf6763467b3.1
        for <bitcoindev@gnusha.org>; Wed, 24 Apr 2024 08:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1713972734; x=1714577534; 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=JvdFrg6SUMHGX6zoCuVUmFPy9rfjm/DsCReljGvbnyM=;
        b=UK7IgPRYS0IUiEGvoi1/VCmQYM/d73r+l8JWq3WtPHDatpK6bADAQzQa78LJFyrDVf
         DqrqLp5xYT6IbUVNoYrGGjC2CGzncDbTTbYe50Jxapy61cbWLMSBUn40HQnAZ9vgI33D
         zAc7vopxodIoZXJQN2ymPH1+mpKc2I1hM7M4jC2dJXF9/lI79VMgmk86kRtpldXQBKBs
         yH+fsc5tcvRfz/5y2ZWIhcisNlnC4q4OBS+22ya8Iu/mMJfLYDl9xaOuMIRk+Nb+qKuo
         1EUaGN9GUzqRBJ4JU3rkGUZrBEbMwXZrBwronZGCaVdMz4HUOYA8VoaTbhVbbFGnLetH
         v5yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1713972734; x=1714577534;
        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=JvdFrg6SUMHGX6zoCuVUmFPy9rfjm/DsCReljGvbnyM=;
        b=IvIRWlGY7tiQL8O1viHj02pn4IttNSvHLANxYGPngwjiftYnTe1uly9AY47f34VoPc
         4/+IT7Fzm77wM6A1dxtaHNnms3Jwo2v9YMLGVWt8vLGbs2GW0lGbeiacSsozVUtzirzt
         DQXIJjXu1dzvMUmlj+jUWMiLLh0F3Zbxe9tjZ8jd+ea6WEUNW4fm4o3SyRJ4QKqq9OmE
         bN3DABuR2WNm6ClGZa1/pUVJoyYzAohuBqn4FpewrQvOrd3Q3f0vEJcq12euxTCQQQRW
         Mw85XTFonZ3NF3nBkCC5KJnVLdsC4t//ApOdg8NQH2WOB8QKUR/uxlwg5MeBYjHEqCkE
         8Jdw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXIUE7BgCUtYjh9rwl+S57T7qrPQh0gD6tltiLhij9rRg4FGT0StnCT3Dm8LD4dvNMbTd/FDu0NOqEr2Mt8PUO13C+QsTE=
X-Gm-Message-State: AOJu0YwteOvK5kTr2aIeirst9i9qE0/bQ/chOF1B17IMJJJ0HBAWJWjJ
	rTMUYrRUlSS9gkspDA7L30dmkQ8IreK6YE3Ybcdxsu7QIMfPBUly
X-Google-Smtp-Source: AGHT+IFmGKLZ4lhR0KSxam5myse0z35bk6lwl8oxH9gjNz15LJdTFkyjGwj0gZxkqCqDQ4+HW/HnAQ==
X-Received: by 2002:a25:ce41:0:b0:dcc:a446:55b with SMTP id x62-20020a25ce41000000b00dcca446055bmr2633954ybe.5.1713972734141;
        Wed, 24 Apr 2024 08:32:14 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:698d:0:b0:de4:5fa0:fe22 with SMTP id 3f1490d57ef6-de58611499als19009276.1.-pod-prod-06-us;
 Wed, 24 Apr 2024 08:32:12 -0700 (PDT)
X-Received: by 2002:a05:6902:2b0a:b0:de5:319b:a226 with SMTP id fi10-20020a0569022b0a00b00de5319ba226mr966876ybb.1.1713972732574;
        Wed, 24 Apr 2024 08:32:12 -0700 (PDT)
Received: by 2002:a05:690c:1e:b0:611:2a20:d0cc with SMTP id 00721157ae682-61b30c7a8a6ms7b3;
        Sun, 21 Apr 2024 21:33:05 -0700 (PDT)
X-Received: by 2002:a81:8d4e:0:b0:611:66e0:8dd4 with SMTP id w14-20020a818d4e000000b0061166e08dd4mr2788104ywj.5.1713760384244;
        Sun, 21 Apr 2024 21:33:04 -0700 (PDT)
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"
X-Original-Sender: ali@notatether.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)

------=_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--