path: root/06/55e93e9dc7f8219111e2ae2fd32a87c60c441e

Delivery-date: Tue, 29 Apr 2025 07:15:35 -0700
Received: from mail-yb1-f183.google.com ([209.85.219.183])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCZL7667UQCRB6V5YPAAMGQEBNAZPAQ@googlegroups.com>)
	id 1u9lkD-0002bQ-I9
	for bitcoindev@gnusha.org; Tue, 29 Apr 2025 07:15:35 -0700
Received: by mail-yb1-f183.google.com with SMTP id 3f1490d57ef6-e7315deb500sf6147545276.3
        for <bitcoindev@gnusha.org>; Tue, 29 Apr 2025 07:15:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1745936127; x=1746540927; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to: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=gj1kL9CGUfXFH6B2cag48W0muTFusYpUTVtd4rCKT0w=;
        b=nidzB1dtEJoAbv/cqgnsP2SFM1tmSnGopY+XvXKlMpbPRIPYnwa4Luv01mosgTv4Lm
         Pe30yWs0V3d2sZU51GrXxHbqMp41x5vOEoGheEQrPiV0Kq7wdOyhpUME6JH+KbZRAC4O
         9LJQB6oYQkmgRxkyLTuJsVJs9fsd1FN8hx1KuQzC5li8ynpOvoOT6k+DN+TCha1XRIdw
         wzWQRJh+RKifk5rYNT/ZJhInPvbUV2YjH/blzrDKn5ltO0Oi5qnoWdAs8FvTc8qTNX8e
         q/eUsu5Y+ij2m5n0Bqzs/XzICgw3FgbBh+Jh8gkGEBDwRcIXPexUAEnRD9K2tKHyT08c
         P5Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1745936127; x=1746540927;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:x-original-sender
         :mime-version:subject:references:in-reply-to:message-id:to:from:date
         :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=gj1kL9CGUfXFH6B2cag48W0muTFusYpUTVtd4rCKT0w=;
        b=VcG3+Wj8J3fUl8N5McdJ3o5uuvPQzSaTrgp//KLVuiEESd90UIf/6iahyyLEfk/zkb
         7R/nTJlHCSDCKckGczCKZm93maKJBfH5Oy9d2y91YLIo/WTFoLRT6lwFv7pyCB9pCKOQ
         dXs4xRPxK0zTwYupVz9Jvxp+vF1Cg2qYunPf1rIrM2e4lOnN7NZVSCYyJgTX5bsnhefe
         2MpG02BYpV0QOV196KgiKbXLIHH/5SbN920FWmGXcEQX5Yf0UQZAZzmrqO9bIDd6+KT/
         Bb2tv+zRwYw/d8uFHyxmg/nQ9N0ZhqaoaY+hNnldRNb8bdHFHT9ODZMQxcpih7MjOu0T
         rNmQ==
X-Forwarded-Encrypted: i=1; AJvYcCV7Laj9LzW79HedyNnWfG+iIdl15VKZq6LIADSQwmmpwruB6IDYaC6SYcLur/gIZJ/9ryfr1uxMIy2n@gnusha.org
X-Gm-Message-State: AOJu0YzW4vK6EaK4oOUCmqe3mwG88HkF62lNUZ5HA57rq4wyd7LVaR1+
	r8q2e7e305hyPX/4ZPAQRIAIgetWuJ3yEVVzi2jlh8vUqgD2G0ln
X-Google-Smtp-Source: AGHT+IFLLCGEN2gzi9FCZg0Np+HM0U+ApWMNeY6wpwFEvASbwYKNZMWSp1uCstGrpdVCT7UaADKT1w==
X-Received: by 2002:a05:6902:2085:b0:e73:2979:235a with SMTP id 3f1490d57ef6-e73510be129mr4658972276.14.1745936126623;
        Tue, 29 Apr 2025 07:15:26 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBF/F7Eq2iMpJ6zjgHN/1A+8SQk5QlTu7ghh0LKSN+9AeQ==
Received: by 2002:a25:b291:0:b0:e63:6582:71c4 with SMTP id 3f1490d57ef6-e73017711b4ls487117276.1.-pod-prod-03-us;
 Tue, 29 Apr 2025 07:15:22 -0700 (PDT)
X-Received: by 2002:a05:690c:6b84:b0:702:4eac:175f with SMTP id 00721157ae682-7089b3588a9mr44622187b3.31.1745936121841;
        Tue, 29 Apr 2025 07:15:21 -0700 (PDT)
Received: by 2002:a0d:c202:0:b0:706:b535:945d with SMTP id 00721157ae682-70854d8a0bbms7b3;
        Mon, 28 Apr 2025 04:59:10 -0700 (PDT)
X-Received: by 2002:a05:690c:4a08:b0:706:ae3b:cca8 with SMTP id 00721157ae682-708541ff9c6mr163363427b3.35.1745841549351;
        Mon, 28 Apr 2025 04:59:09 -0700 (PDT)
Date: Mon, 28 Apr 2025 04:59:09 -0700 (PDT)
From: "'emsit' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <47f218f0-4c7d-464c-a68c-04bcfeb5b76dn@googlegroups.com>
In-Reply-To: <CADL_X_dfaBQJDXu=urRn40J7fCkDAPi-sdnnCwAZd4RUgr68fw@mail.gmail.com>
References: <hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU=@protonmail.com>
 <5c13e130-aaa2-4866-be26-7498100e868b@murch.one>
 <7c6800f0-7b77-4aca-a4f9-2506a2410b29@murch.one>
 <vgcVopNpWCowIGaIpVgjsCWyTMjxVKoWtRdDVnTNrM8tYPjKtC6MJ6S-2KxIYdJYgAhG8iNPig-xijwd7DtAm6tHN3T3xgIMUNUSTBYvT_A=@protonmail.com>
 <672cb527-9005-46fc-be2c-4508d39cfd7dn@googlegroups.com>
 <CADL_X_eXcmD8fEpL9Sqqwt6EfwtdjG+Aaqk+pgSBhPmaVT3gEw@mail.gmail.com>
 <CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A@mail.gmail.com>
 <CADL_X_dfaBQJDXu=urRn40J7fCkDAPi-sdnnCwAZd4RUgr68fw@mail.gmail.com>
Subject: Re: [bitcoindev] Unbreaking testnet4
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_198752_1119539221.1745841549056"
X-Original-Sender: emsit@emsit.sk
X-Original-From: emsit <emsit@emsit.sk>
Reply-To: emsit <emsit@emsit.sk>
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: -1.0 (-)

------=_Part_198752_1119539221.1745841549056
Content-Type: multipart/alternative; 
	boundary="----=_Part_198753_1071964476.1745841549056"

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

I think that the idea of expiring testnet coins would kill faucets. So=20
getting some coins would become even harder.
My faucet doesn't work based on donations. What I distribute I had to mine=
=20
myself (ideally in the early days, when the difficulty was lower). And=20
since I=E2=80=99ve been running the faucet for more than 10 years, I can sa=
y that=20
only a very small portion of testnet BTC ever returns to the faucet, and it=
=20
was like that even before people started trading it.
It's better for people to keep their testnet coins for future use rather=20
than later struggling to find ways to get more. Not everyone can mine. I=20
myself had to rent mining power.
Back in the day, I used to give away 1-2 BTC per withdrawal =E2=80=94 there=
 were=20
enough coins, and nobody cared about them. But in recent years, demand has=
=20
skyrocketed, supplies have shrunk, and withdrawals became more frequent.=20
Some people started abusing faucets, and it=E2=80=99s still happening today=
, which=20
is why my current withdrawal limit is set to 0.001-0.002 per request.

Even though testnet4 is new and the block reward is 50 BTC, it hasn=E2=80=
=99t=20
solved the shortage problem because most mined coins aren't publicly=20
available.
And even if some faucet had plenty of them, it would still only offer a=20
very small withdrawal amount, because people would immediately start=20
abusing it to profit.

D=C3=A1tum: pondelok 28. apr=C3=ADla 2025, =C4=8Das: 13:06:38 UTC+2, odosie=
late=C4=BE: Jameson=20
Lopp

> On Mon, Apr 28, 2025 at 2:11=E2=80=AFAM Saint Wenhao <saint...@gmail.com>=
 wrote:
>
>> > Demurrage might be asking a bit much in terms of deviation.
>>
>> If that's the case, then why signing all blocks in signet is not "too=20
>> much"?=20
>>
>
> Because signet isn't testnet? It gives up permissionless block creation i=
n=20
> return for predictability.
> =20
>
>> Or why unlimited supply is not "too much"?=20
>>
>
> It might be, but it might not be, given that the point of testnet is for=
=20
> coins to be free for developers to acquire and use without fear of=20
> financial loss. Thus scarcity isn't really an inviolable property of=20
> testnet.
> =20
>
>> All of these changes were put in the same basket of "Require unanimous=
=20
>> consent", so why one kind of change is better or worse than the others? =
All=20
>> of them deviates from the mainnet, and we probably wouldn't want anythin=
g=20
>> like that on the original chain anyway.
>>
>
>>
>> > I'd think that testnets should be reset more frequently than that.
>>
>> Then why don't we put any kind of reset logic into testnet5 consensus=20
>> rules? Because when nothing like that is present, then testnets can=20
>> potentially run forever. Testnet3 is becoming an altcoin, and new testne=
ts=20
>> will also be, if no significant changes will be made. Signet is not trad=
ed=20
>> yet, mainly because of centralized mining, but there already are=20
>> centralized altcoin federations, so it may change in the future.
>>
>>
> Encoding an "end of life date" into testnets is actually an interesting=
=20
> idea worth discussing. As far as I'm aware it's never been done before on=
=20
> any network.=20
>
> And again, the word "reset" should be replaced by "abandon", unless you=
=20
>> really want to reorganize the whole old chain of some existing testnet, =
by=20
>> producing a stronger alternative chain in testnet5, which would replace =
the=20
>> old network in a backward-compatible way, by mining everything on top of=
=20
>> the same Genesis Block, and eventually producing a bigger chainwork.
>>
>
>> pon., 28 kwi 2025 o 00:50 Jameson Lopp <jameso...@gmail.com> napisa=C5=
=82(a):
>>
>>>
>>>
>>> On Sun, Apr 27, 2025 at 12:47=E2=80=AFPM Saint Wenhao <saint...@gmail.c=
om>=20
>>> wrote:
>>>
>>>> What about introducing demurrage in testnet5 consensus rules?
>>>>
>>> In general it seems desirable for a testnet to be as close as possible=
=20
>>> to mainnet's rules. Demurrage might be asking a bit much in terms of=20
>>> deviation.
>>>
>>> I'd suggest simply disabling the halving logic and making it a perpetua=
l=20
>>> 50 TBTC issuance. At that rate, it would still take ~8 years or so to=
=20
>>> surpass the 21M limit and I'd think that testnets should be reset more=
=20
>>> frequently than that.
>>>
>>>>
>>>> Testnet coins were supposed to be worthless. But it failed in both=20
>>>> testnet3 and testnet4. In the meanwhile, signet was introduced, to mak=
e a=20
>>>> more stable test network. However, signing blocks was listed on wiki p=
age=20
>>>> https://en.bitcoin.it/wiki/Prohibited_changes as something, that=20
>>>> "Require unanimous consent". And, as the history can tell us, people s=
till=20
>>>> wanted to test mining anyway, which is why testnet3 and testnet4 have =
much=20
>>>> more chainwork than signet (and when it comes to signet, sending=20
>>>> signed-but-unmined blocks to the miners was never implemented, so they=
 had=20
>>>> no chance to provide more hashing power).
>>>>
>>>> Another kind of change on the list, that would require consent, was=20
>>>> increasing the total number of coins beyond 21 million. But then, test=
ing=20
>>>> supply limits would be harder, and it could cause integer overflows in=
 some=20
>>>> cases. But: in all test networks, including testnet3, testnet4, and si=
gnet,=20
>>>> there was never a problem of "not enough coins for miners", so that ch=
ange=20
>>>> probably wouldn't solve any problems (and seeing it in action would ta=
ke=20
>>>> years anyway; testnet4 is still far from the first halving, and it is=
=20
>>>> traded anyway, so that change won't fix it).
>>>>
>>>> Then, we have the third option, which was not yet tried in test=20
>>>> networks: demurrage. There are two main options: burning coins, or=20
>>>> re-assigning them to someone else. To make a soft-fork out of it,=20
>>>> re-assigning would be backward-incompatible, so it is probably easier =
to=20
>>>> just implement burning, and just treat all coins older than N blocks i=
n the=20
>>>> same way, as OP_RETURN, by simply invalidating transactions spending t=
hem=20
>>>> on consensus level.
>>>>
>>>> Also, when it comes to maintaining testnet nodes, if it would be=20
>>>> possible to automatically remove things from the UTXO set, then it wou=
ld=20
>>>> make Initial Blockchain Download easier, just because new nodes wouldn=
't=20
>>>> need to synchronize everything, if old coins would be automatically=20
>>>> invalidated. In practice, all nodes could be just running in pruned mo=
de=20
>>>> all the time, and everything beyond the pruning point, could be simply=
=20
>>>> ignored on consensus level (which would also prevent the UTXO set from=
=20
>>>> exploding). And then, if we would keep for example the last 2,016 bloc=
ks,=20
>>>> then the whole chain would never take more than 2016 * 4 MB =3D 8.064 =
GB of=20
>>>> storage, and that's all we would need to send during Initial Blockchai=
n=20
>>>> Download to other nodes.
>>>>
>>>> poniedzia=C5=82ek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot napi=
sa=C5=82(a):
>>>>
>>>>> Good point on not having the flag day on a holiday. One or two weeks=
=20
>>>>> sounds good to me.=20
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch.one> wrote=
:=20
>>>>>
>>>>> >=20
>>>>> >=20
>>>>> > Errr, I wrote the same date as you, but I meant a week later,=20
>>>>> 2026-01-08=20
>>>>> > instead.=20
>>>>> >=20
>>>>> > -Murch=20
>>>>> >=20
>>>>> > On 2025-03-21 14:20, Murch wrote:=20
>>>>> >=20
>>>>> > > Hey Antoine and everyone,=20
>>>>> > >=20
>>>>> > > What you suggest makes sense to me. Since the 20-minute difficult=
y=20
>>>>> > > exception is now exploited perpetually, it doesn=E2=80=99t serve =
its=20
>>>>> intended=20
>>>>> > > purpose of allowing developers to mine themselves a few coins=20
>>>>> easily or=20
>>>>> > > confirm their own non-standard transactions. In that case, it=20
>>>>> would be=20
>>>>> > > better to not have it at all.=20
>>>>> > >=20
>>>>> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development=20
>>>>> Mailing=20
>>>>> > > List wrote:=20
>>>>> > >=20
>>>>> > > > I propose to fix this by removing the difficulty reset rule fro=
m=20
>>>>> > > > testnet4 through a flag day hard fork on 2026-01-01.=20
>>>>> > >=20
>>>>> > > I would suggest to pick a date that=E2=80=99s not a holiday in ma=
ny places=20
>>>>> to=20
>>>>> > > avoid disrupting people=E2=80=99s holiday, how about 2026-01-01 i=
nstead?=20
>>>>> > >=20
>>>>> > > Cheers,=20
>>>>> > > Murch=20
>>>>> >=20
>>>>> >=20
>>>>> > --=20
>>>>> > You received this message because you are subscribed to the Google=
=20
>>>>> Groups "Bitcoin Development Mailing List" group.=20
>>>>> > To unsubscribe from this group and stop receiving emails from it,=
=20
>>>>> send an email to bitcoindev+...@googlegroups.com.=20
>>>>> > To view this discussion visit=20
>>>>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-=
2506a2410b29%40murch.one.=20
>>>>>
>>>>>
>>>> --=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 visit=20
>>>> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4=
508d39cfd7dn%40googlegroups.com=20
>>>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-=
4508d39cfd7dn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>>>> .
>>>>
>>>

--=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 visit https://groups.google.com/d/msgid/bitcoindev/=
47f218f0-4c7d-464c-a68c-04bcfeb5b76dn%40googlegroups.com.

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

I think that the idea of expiring testnet coins would kill faucets. So gett=
ing some coins would become even harder.<br />My faucet doesn't work based =
on donations. What I distribute I had to mine myself (ideally in the early =
days, when the difficulty was lower). And since I=E2=80=99ve been running t=
he faucet for more than 10 years, I can say that only a very small portion =
of testnet BTC ever returns to the faucet, and it was like that even before=
 people started trading it.<br />It's better for people to keep their testn=
et coins for future use rather than later struggling to find ways to get mo=
re. Not everyone can mine. I myself had to rent mining power.<br />Back in =
the day, I used to give away 1-2 BTC per withdrawal =E2=80=94 there were en=
ough coins, and nobody cared about them. But in recent years, demand has sk=
yrocketed, supplies have shrunk, and withdrawals became more frequent. Some=
 people started abusing faucets, and it=E2=80=99s still happening today, wh=
ich is why my current withdrawal limit is set to 0.001-0.002 per request.<b=
r /><br />Even though testnet4 is new and the block reward is 50 BTC, it ha=
sn=E2=80=99t solved the shortage problem because most mined coins aren't pu=
blicly available.<br />And even if some faucet had plenty of them, it would=
 still only offer a very small withdrawal amount, because people would imme=
diately start abusing it to profit.<br /><br /><div class=3D"gmail_quote"><=
div dir=3D"auto" class=3D"gmail_attr">D=C3=A1tum: pondelok 28. apr=C3=ADla =
2025, =C4=8Das: 13:06:38 UTC+2, odosielate=C4=BE: Jameson Lopp<br/></div><b=
lockquote 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"><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 28, 20=
25 at 2:11=E2=80=AFAM Saint Wenhao &lt;<a href data-email-masked rel=3D"nof=
ollow">saint...@gmail.com</a>&gt; wrote:<br></div></div></div><div dir=3D"l=
tr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr">&gt; Demurrage might be asking a bit much in terms o=
f deviation.<br><br></div></blockquote></div></div><div dir=3D"ltr"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">If that&#39;s the case, then why signing all blocks in signet i=
s not &quot;too much&quot;? </div></blockquote><div><br></div><div>Because =
signet isn&#39;t testnet? It gives up permissionless block creation in retu=
rn for predictability.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr">Or why unlimited supply is not &quot;t=
oo much&quot;? </div></blockquote><div><br></div><div>It might be, but it m=
ight not be, given that the point of testnet is for coins to be free for de=
velopers to acquire and use without fear of financial loss. Thus scarcity i=
sn&#39;t really an inviolable property of testnet.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">All of the=
se changes were put in the same basket of &quot;Require unanimous consent&q=
uot;, so why one kind of change is better or worse than the others? All of =
them deviates from the mainnet, and we probably wouldn&#39;t want anything =
like that on the original chain anyway.</div></blockquote></div></div><div =
dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><br><br>&gt; I&#39;d think that testnets sho=
uld be reset more frequently than that.<br><br></div></blockquote></div></d=
iv><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr">Then why don&#39;t we put any kind o=
f reset logic into testnet5 consensus rules? Because when nothing like that=
 is present, then testnets can potentially run forever. Testnet3 is becomin=
g an altcoin, and new testnets will also be, if no significant changes will=
 be made. Signet is not traded yet, mainly because of centralized mining, b=
ut there already are centralized altcoin federations, so it may change in t=
he future.<br><br></div></blockquote><div><br></div><div>Encoding an &quot;=
end of life date&quot; into testnets is actually an interesting idea worth =
discussing. As far as I&#39;m aware it&#39;s never been done before on any =
network.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr">And again, the word &quot;reset&quot; should be=
 replaced by &quot;abandon&quot;, unless you really want to reorganize the =
whole old chain of some existing testnet, by producing a stronger alternati=
ve chain in testnet5, which would replace the old network in a backward-com=
patible way, by mining everything on top of the same Genesis Block, and eve=
ntually producing a bigger chainwork.</div></blockquote></div></div><div di=
r=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">pon., 28 kwi 2025 o 00:50=C2=A0Jameson Lopp &lt;<a href data-email-ma=
sked rel=3D"nofollow">jameso...@gmail.com</a>&gt; napisa=C5=82(a):<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div di=
r=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Sun, Apr 27, 2025 at 12:47=E2=80=AFPM Saint Wenhao &lt;<=
a href data-email-masked rel=3D"nofollow">saint...@gmail.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What about intr=
oducing demurrage in testnet5 consensus rules?<br></blockquote><div>In gene=
ral it seems desirable for a testnet to be as close as possible to mainnet&=
#39;s rules. Demurrage might be asking a bit much in terms of deviation.</d=
iv><div><br></div><div>I&#39;d suggest simply disabling the halving logic a=
nd making it a perpetual 50 TBTC issuance. At that rate, it would still tak=
e ~8 years or so to surpass the 21M limit and I&#39;d think that testnets s=
hould be reset more frequently than that.</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><br>Testnet coins were supposed to be worthless. But =
it failed in both testnet3 and testnet4. In the meanwhile, signet was intro=
duced, to make a more stable test network. However, signing blocks was list=
ed on wiki page <a href=3D"https://en.bitcoin.it/wiki/Prohibited_changes" t=
arget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.googl=
e.com/url?hl=3Dsk&amp;q=3Dhttps://en.bitcoin.it/wiki/Prohibited_changes&amp=
;source=3Dgmail&amp;ust=3D1745925411245000&amp;usg=3DAOvVaw1V8WT4z7opycN2S_=
QflVyi">https://en.bitcoin.it/wiki/Prohibited_changes</a> as something, tha=
t &quot;Require unanimous consent&quot;. And, as the history can tell us, p=
eople still wanted to test mining anyway, which is why testnet3 and testnet=
4 have much more chainwork than signet (and when it comes to signet, sendin=
g signed-but-unmined blocks to the miners was never implemented, so they ha=
d no chance to provide more hashing power).<br><br>Another kind of change o=
n the list, that would require consent, was increasing the total number of =
coins beyond 21 million. But then, testing supply limits would be harder, a=
nd it could cause integer overflows in some cases. But: in all test network=
s, including testnet3, testnet4, and signet, there was never a problem of &=
quot;not enough coins for miners&quot;, so that change probably wouldn&#39;=
t solve any problems (and seeing it in action would take years anyway; test=
net4 is still far from the first halving, and it is traded anyway, so that =
change won&#39;t fix it).<br><br>Then, we have the third option, which was =
not yet tried in test networks: demurrage. There are two main options: burn=
ing coins, or re-assigning them to someone else. To make a soft-fork out of=
 it, re-assigning would be backward-incompatible, so it is probably easier =
to just implement burning, and just treat all coins older than N blocks in =
the same way, as OP_RETURN, by simply invalidating transactions spending th=
em on consensus level.<br><br>Also, when it comes to maintaining testnet no=
des, if it would be possible to automatically remove things from the UTXO s=
et, then it would make Initial Blockchain Download easier, just because new=
 nodes wouldn&#39;t need to synchronize everything, if old coins would be a=
utomatically invalidated. In practice, all nodes could be just running in p=
runed mode all the time, and everything beyond the pruning point, could be =
simply ignored on consensus level (which would also prevent the UTXO set fr=
om exploding). And then, if we would keep for example the last 2,016 blocks=
, then the whole chain would never take more than 2016 * 4 MB =3D 8.064 GB =
of storage, and that&#39;s all we would need to send during Initial Blockch=
ain Download to other nodes.<br><br><div class=3D"gmail_quote"><div dir=3D"=
auto" class=3D"gmail_attr">poniedzia=C5=82ek, 31 marca 2025 o=C2=A022:50:27=
 UTC+2 Antoine Poinsot napisa=C5=82(a):<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">Good point on not having the flag day on a holiday.=
 One or two weeks sounds good to me.
<br>
<br>
<br>
<br>
<br>On Monday, March 24th, 2025 at 8:25 AM, Murch &lt;mu...@murch.one&gt; w=
rote:
<br>
<br>&gt;=20
<br>&gt;=20
<br>&gt; Errr, I wrote the same date as you, but I meant a week later, 2026=
-01-08
<br>&gt; instead.
<br>&gt;=20
<br>&gt; -Murch
<br>&gt;=20
<br>&gt; On 2025-03-21 14:20, Murch wrote:
<br>&gt;=20
<br>&gt; &gt; Hey Antoine and everyone,
<br>&gt; &gt;=20
<br>&gt; &gt; What you suggest makes sense to me. Since the 20-minute diffi=
culty
<br>&gt; &gt; exception is now exploited perpetually, it doesn=E2=80=99t se=
rve its intended
<br>&gt; &gt; purpose of allowing developers to mine themselves a few coins=
 easily or
<br>&gt; &gt; confirm their own non-standard transactions. In that case, it=
 would be
<br>&gt; &gt; better to not have it at all.
<br>&gt; &gt;=20
<br>&gt; &gt; On 2025-03-18 07:29, &#39;Antoine Poinsot&#39; via Bitcoin De=
velopment Mailing
<br>&gt; &gt; List wrote:
<br>&gt; &gt;=20
<br>&gt; &gt; &gt; I propose to fix this by removing the difficulty reset r=
ule from
<br>&gt; &gt; &gt; testnet4 through a flag day hard fork on 2026-01-01.
<br>&gt; &gt;=20
<br>&gt; &gt; I would suggest to pick a date that=E2=80=99s not a holiday i=
n many places to
<br>&gt; &gt; avoid disrupting people=E2=80=99s holiday, how about 2026-01-=
01 instead?
<br>&gt; &gt;=20
<br>&gt; &gt; Cheers,
<br>&gt; &gt; Murch
<br>&gt;=20
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &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 rel=3D"nofollow">bitcoindev+...@googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one" rel=
=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google.=
com/url?hl=3Dsk&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/7c6800=
f0-7b77-4aca-a4f9-2506a2410b29%2540murch.one&amp;source=3Dgmail&amp;ust=3D1=
745925411245000&amp;usg=3DAOvVaw13JdwqGVuBStg38_gZHzB8">https://groups.goog=
le.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one<=
/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 data-email-masked rel=3D"nofollow">bitcoindev+...@googlegro=
ups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"nofollow" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Dsk&amp;q=3Dhttps://gro=
ups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%254=
0googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&amp;source=3Dgma=
il&amp;ust=3D1745925411245000&amp;usg=3DAOvVaw3hZFVfms4HEybJ8srVfhvK">https=
://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7=
dn%40googlegroups.com</a>.<br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/47f218f0-4c7d-464c-a68c-04bcfeb5b76dn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/47f218f0-4c7d-464c-a68c-04bcfeb5b76dn%40googlegroups.com</a>.<br />

------=_Part_198753_1071964476.1745841549056--

------=_Part_198752_1119539221.1745841549056--