path: root/d5/6793f0927787530bbb72736d0b1f6b09a71636

Delivery-date: Mon, 28 Apr 2025 04:06:47 -0700
Received: from mail-oo1-f61.google.com ([209.85.161.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDFIP6H73EBBBO6CXXAAMGQE5K3CBOQ@googlegroups.com>)
	id 1u9MJx-0006nK-VK
	for bitcoindev@gnusha.org; Mon, 28 Apr 2025 04:06:47 -0700
Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-60624d13c7fsf903639eaf.0
        for <bitcoindev@gnusha.org>; Mon, 28 Apr 2025 04:06:45 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1745838399; cv=pass;
        d=google.com; s=arc-20240605;
        b=h2mYmVv1uSYPsCTOppbv7OIZ3giSHf5m6he1bJsu0AmdjnHYHjzxUjwBQA3/pFC/2v
         rXv+S6VJ+kGs2ObjZonXiDnZ1vuGu8KOeDAPSAVx3iNVl4xQMVWHSlyCiK65EaUji+gW
         wuoTGNyl2FQlwE8hqxshLKZgsKia/wSBpS4CsiSTsfHw72ukkB1ov16fT3T8R6DWF+aN
         ruARFOp09arbDORp4qNTbfGhfyPOzTzKG2QuaQKxZJ/zlq8gtBAqU3wpAkDyt/yIog4r
         8b4BxFyId3o3UOOUhqu5wOWwdNiY0/WUdptxIGioGC1Cq9E4dOMKfba0L1ZFhwiwcq3D
         3Z1A==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=L5E+y55Z4BNr/4j+NhpGrG+QATXd7sAawjQ0228mPhI=;
        fh=kaCMT8SpfMq0zaRX7UY716bxZjaFBM9sWWYyfGIHw94=;
        b=EvhILMAQVx+JlBU8ptAvaTDT3IyJktyN6qrsMC1l07kQ8U2ceYhiSfDlKg9D/qv84z
         ShUQy6PfOsa0yNC4rkx6AbMe3xOueSSO+WZGlCByAioPJipiPrq8o/GeJiZCNUfKRY17
         t1ZMS3Frn+D4ZFuPYQlFy0XjXaQ+H2K9AI2u9sD+9FTufodTosrVRx5n7HSBqqej2ZWs
         RtPvlOf8wSKqYtDsT/W9Zoek8GhsdzniPgKjmDoZjrCRFpTt52aUcBBLE0XS1+v2uafY
         kmZ98BdF79BuijRmNdAXIJPwB4FFhpfJP8uqvHgWaBrU0LCAZhAtbztwH8Y8z1f0sQnZ
         tsGA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b="gTmL+/es";
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1745838399; x=1746443199; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=L5E+y55Z4BNr/4j+NhpGrG+QATXd7sAawjQ0228mPhI=;
        b=mMFkxFxsWGWNTX9nFRHpMxa4mZYt6A+bQzXCGaCOwJo7Vy7l5lbgbbFA7H9W9O87J2
         MDFuF5NFZsrvKMXn0OGnzOxS5+7IRUJlcawdbrV35U0tWeYJlhLKiaCsoavN1Q7QRrl5
         Gd2C8syeLnLixQTqNlXgC9axWEv1APdrq5RIVmfqBQDUy8yO7uvQxVztR5Cr0q6/JzYl
         Ue7otNVjExNpDGJyaI7fRvlAoaZKhjf48i3bFNBTJIr1KGGZkiurLMyh4g22p9shqUYx
         kISpNtpjX9hvYd7vuuJGYlB3yQYeIy4KBY83AoxTJBF0CXMUG/htpWd7+0dpndN4T0LU
         Gttw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1745838399; x=1746443199; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=L5E+y55Z4BNr/4j+NhpGrG+QATXd7sAawjQ0228mPhI=;
        b=Iu/1Dbjk+O6GI/iUtOm68YT89nJpaJW5ZLloOttVDXMAFFRHWvmDy1e/EaeCoubWhe
         SqgSKQESsnsm8Dcfd9yC/BP+Ac5MojEYE8daSiZS+f9DEe4ypBu+yUw0JjHl03Frw7oW
         djh58I45Uxe2nt13u4VDiogjVYb3KaSUja4SPAgsHiumkX2fzIf48FCaA/qAslIkK2dI
         sMw8GKfJloCHa9YYEPBWmpdwb1RMiOymKr0J7EdWbK63QKD+bUKor9nXZ/WMOQxwHdzq
         lwsStpdv6tSzDw74HG11ON6Hj/3Eyh0k2s15Bv9ej2ODxXYcvAYvePXh1c7ELCfpzRNB
         9XLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1745838399; x=1746443199;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=L5E+y55Z4BNr/4j+NhpGrG+QATXd7sAawjQ0228mPhI=;
        b=KYTrLkOWJJtYOvNXR5iipjJT03AkI41wQgM1WbZLX+LMlTAL0uXTijdxpNM4J4Jokr
         Az0RuB1gYfX7Gde2LgtkTwAKJQolFMlIZd1caSJ9nLZzYUDq/1gxzqmPan/a47XGqp3m
         zIPAGu457NAbgP51KDZq+CJaFKsEmSuhCEZAyJdYVHEOqZVmSdILWsqZ0Or7KPaj9/sp
         ZXqAXf7MUkOdkzbabj2taLhlhXDr/Wh2ySoTpywrHXRaxpGGHxnwF0FAfPagiJzZqgH8
         YS2lORnDrnL/45dBplAu13trI7/aAK2uQaNM+B8FQ9K1b0I5At7eKbCfKD0mgmoMSKSU
         SM3Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWouqBKuQkvoJFCJ0O+OjGu4JjvXZUFZdlj3DZJqjhS2c9Z1JyehovN8GFaT85lrrnI96TE7T31JFyc@gnusha.org
X-Gm-Message-State: AOJu0Yxuxv6eoz/Z9Vy+R0QEpwalg2Lo9bz72ZAj8ITQ4dqM/knrRcLi
	w/ywRBCAw8/LZiKanITjObqRvvIjYjecZTag5jfDenwFWz33WlJI
X-Google-Smtp-Source: AGHT+IEfuo2ANAZLJDCzv2FgCW1UJVglY8lSuUtbf0Gpx+NcMq6yy1SSljWAdrEidVQOj7IAxRLVww==
X-Received: by 2002:a05:6820:3102:b0:603:f973:1b1 with SMTP id 006d021491bc7-60658d72432mr5197934eaf.0.1745838398682;
        Mon, 28 Apr 2025 04:06:38 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBGwOT59Wse50Osvq2o6S/V+UlvMViibtokG+BzuHPYrFw==
Received: by 2002:a4a:dc4c:0:b0:606:1fcd:dd8f with SMTP id 006d021491bc7-606438099afls872344eaf.2.-pod-prod-06-us;
 Mon, 28 Apr 2025 04:06:35 -0700 (PDT)
X-Received: by 2002:a05:6808:3604:b0:3f9:2fdc:eeac with SMTP id 5614622812f47-401fd7be0cfmr3891388b6e.33.1745838395341;
        Mon, 28 Apr 2025 04:06:35 -0700 (PDT)
Received: by 2002:a50:8a95:0:b0:5e6:412b:7fe with SMTP id 4fb4d7f45d1cf-5f727a63ba2msa12;
        Mon, 28 Apr 2025 03:45:39 -0700 (PDT)
X-Received: by 2002:a17:907:3f9f:b0:aca:a1cf:d5f8 with SMTP id a640c23a62f3a-ace848c0272mr719034966b.11.1745837136648;
        Mon, 28 Apr 2025 03:45:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1745837136; cv=none;
        d=google.com; s=arc-20240605;
        b=eHvls5vfa5/xe1Se2G9bYnBD6VKdJNgV30nT1qo/6W8VP+WXEfhggGZ1TTVXKGWYVw
         ve8hZrpuMH7EvyD4mx40AnhIQTOejGYg3v9Fxn+wfG31ma/v0rgpHxgZc8iOyBzCb+zo
         S/nPU6n+uy5Sm/BDwKTom9I/5TFdAer32cXEQhxz74rRnG+88bWpH78jd1PVu/dARm2d
         covquKjTGl7Yu5ki0zgFlYI1G1F+kk3k1TQfBGWCE4vGOBmKsqGkQpzu3YunTQgQCLzQ
         ZK+VTUNL6oa1h+NPbA8iZUKKt8SpGH6s0Ei6kde9Jr2L2rVl245t4IZb5fmlCXLRo1G0
         pg6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=R7k0jIq/iDHmdlMhBRIWMP7QwoqJAgumxVBrdS0cW8o=;
        fh=IEPLWoyJKcVvSmoA1ytbY29vMgb09bRNcxsIV5rxU6U=;
        b=Sw7lENQ17gzbxgPLKYW8GizTmJqlvxPIt1PU/T7mw6nHpG+i9Pid38PLa3YUXfkn4V
         QJyIHFkNl9pkAhkgWgX07lBteXYCnniTeokAbKs3zJFz9MFHwx8yl39Dn7Rmd0xCFnJv
         aDxI98FmzA399/yPV0JOG6CmwrVk9DdzwB+3QUeOkWou7WqSsSiW86jSjwY6ac2DTXem
         yxxtA0iR0xg8A5o1vA2WVzxn+/Fl72ScqLpmt5WXx/7TMhttijSgTQxPYMica/Y5W3sq
         GK5ZXkReLCvBuy9Xt+sMnJLltayEFRXeg7fwd1AKrMhXerTHa9/OSrp8XJeRDpzXdcb6
         67ZA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b="gTmL+/es";
       spf=pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com. [2a00:1450:4864:20::12a])
        by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-5f703140ac8si220777a12.4.2025.04.28.03.45.36
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 28 Apr 2025 03:45:36 -0700 (PDT)
Received-SPF: pass (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) client-ip=2a00:1450:4864:20::12a;
Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-549b159c84cso5285889e87.3
        for <bitcoindev@googlegroups.com>; Mon, 28 Apr 2025 03:45:36 -0700 (PDT)
X-Gm-Gg: ASbGncv8TAtWjEgb+Y55uVC66wo8nkfmQzM+hqMZR/9wnyq5zrbVGnNC8nweI665PXm
	2dS4btxQ2LwBWmcNpuRJiNz3wryjLt9THZXgZpDNCM+2NXr8AGkaMMnwJU2BYY2QkPLkVSLMgNT
	dIUwPzvfPbqqkCWkhTMxoTLvs=
X-Received: by 2002:a05:6512:ba5:b0:54d:67d7:c523 with SMTP id
 2adb3069b0e04-54e8ffb7faamr2101731e87.8.1745837135525; Mon, 28 Apr 2025
 03:45:35 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
Date: Mon, 28 Apr 2025 06:45:23 -0400
X-Gm-Features: ATxdqUFZADCywMaauCFkENmXEuugnLju2Q0nGDuqACq6tCSoak1UGtbmpPtazGk
Message-ID: <CADL_X_dfaBQJDXu=urRn40J7fCkDAPi-sdnnCwAZd4RUgr68fw@mail.gmail.com>
Subject: Re: [bitcoindev] Unbreaking testnet4
To: Saint Wenhao <saintwenhao@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000004c7fad0633d46242"
X-Original-Sender: jameson.lopp@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b="gTmL+/es";       spf=pass
 (google.com: domain of jameson.lopp@gmail.com designates 2a00:1450:4864:20::12a
 as permitted sender) smtp.mailfrom=jameson.lopp@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.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.5 (/)

--0000000000004c7fad0633d46242
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 28, 2025 at 2:11=E2=80=AFAM Saint Wenhao <saintwenhao@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
> much"?
>

Because signet isn't testnet? It gives up permissionless block creation in
return for predictability.


> Or why unlimited supply is not "too much"?
>

It might be, but it might not be, given that the point of testnet is for
coins to be free for developers to acquire and use without fear of
financial loss. Thus scarcity isn't really an inviolable property of
testnet.


> All of these changes were put in the same basket of "Require unanimous
> consent", so why one kind of change is better or worse than the others? A=
ll
> of them deviates from the mainnet, and we probably wouldn't want anything
> 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
> rules? Because when nothing like that is present, then testnets can
> potentially run forever. Testnet3 is becoming an altcoin, and new testnet=
s
> will also be, if no significant changes will be made. Signet is not trade=
d
> yet, mainly because of centralized mining, but there already are
> centralized altcoin federations, so it may change in the future.
>
>
Encoding an "end of life date" into testnets is actually an interesting
idea worth discussing. As far as I'm aware it's never been done before on
any network.

And again, the word "reset" should be replaced by "abandon", unless you
> really want to reorganize the whole old chain of some existing testnet, b=
y
> producing a stronger alternative chain in testnet5, which would replace t=
he
> old network in a backward-compatible way, by mining everything on top of
> the same Genesis Block, and eventually producing a bigger chainwork.
>
> pon., 28 kwi 2025 o 00:50 Jameson Lopp <jameson.lopp@gmail.com>
> napisa=C5=82(a):
>
>>
>>
>> On Sun, Apr 27, 2025 at 12:47=E2=80=AFPM Saint Wenhao <saintwenhao@gmail=
.com>
>> wrote:
>>
>>> What about introducing demurrage in testnet5 consensus rules?
>>>
>> In general it seems desirable for a testnet to be as close as possible t=
o
>> mainnet's rules. Demurrage might be asking a bit much in terms of deviat=
ion.
>>
>> I'd suggest simply disabling the halving logic and making it a perpetual
>> 50 TBTC issuance. At that rate, it would still take ~8 years or so to
>> surpass the 21M limit and I'd think that testnets should be reset more
>> frequently than that.
>>
>>>
>>> Testnet coins were supposed to be worthless. But it failed in both
>>> testnet3 and testnet4. In the meanwhile, signet was introduced, to make=
 a
>>> more stable test network. However, signing blocks was listed on wiki pa=
ge
>>> https://en.bitcoin.it/wiki/Prohibited_changes as something, that
>>> "Require unanimous consent". And, as the history can tell us, people st=
ill
>>> wanted to test mining anyway, which is why testnet3 and testnet4 have m=
uch
>>> more chainwork than signet (and when it comes to signet, sending
>>> signed-but-unmined blocks to the miners was never implemented, so they =
had
>>> no chance to provide more hashing power).
>>>
>>> Another kind of change on the list, that would require consent, was
>>> increasing the total number of coins beyond 21 million. But then, testi=
ng
>>> supply limits would be harder, and it could cause integer overflows in =
some
>>> cases. But: in all test networks, including testnet3, testnet4, and sig=
net,
>>> there was never a problem of "not enough coins for miners", so that cha=
nge
>>> probably wouldn't solve any problems (and seeing it in action would tak=
e
>>> years anyway; testnet4 is still far from the first halving, and it is
>>> traded anyway, so that change won't fix it).
>>>
>>> Then, we have the third option, which was not yet tried in test
>>> networks: demurrage. There are two main options: burning 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 t=
o
>>> 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.
>>>
>>> Also, when it comes to maintaining testnet nodes, if it would be
>>> possible to automatically remove things from the UTXO set, then it woul=
d
>>> make Initial Blockchain Download easier, just because new nodes wouldn'=
t
>>> need to synchronize everything, if old coins would be automatically
>>> invalidated. In practice, all nodes could be just running in pruned mod=
e
>>> all the time, and everything beyond the pruning point, could be simply
>>> ignored on consensus level (which would also prevent the UTXO set from
>>> exploding). And then, if we would keep for example the last 2,016 block=
s,
>>> then the whole chain would never take more than 2016 * 4 MB =3D 8.064 G=
B of
>>> storage, and that's all we would need to send during Initial Blockchain
>>> Download to other nodes.
>>>
>>> poniedzia=C5=82ek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot napis=
a=C5=82(a):
>>>
>>>> Good point on not having the flag day on a holiday. One or two weeks
>>>> sounds good to me.
>>>>
>>>>
>>>>
>>>>
>>>> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch.one> wrote:
>>>>
>>>> >
>>>> >
>>>> > Errr, I wrote the same date as you, but I meant a week later,
>>>> 2026-01-08
>>>> > instead.
>>>> >
>>>> > -Murch
>>>> >
>>>> > On 2025-03-21 14:20, Murch wrote:
>>>> >
>>>> > > Hey Antoine and everyone,
>>>> > >
>>>> > > What you suggest makes sense to me. Since the 20-minute difficulty
>>>> > > exception is now exploited perpetually, it doesn=E2=80=99t serve i=
ts
>>>> intended
>>>> > > purpose of allowing developers to mine themselves a few coins
>>>> easily or
>>>> > > confirm their own non-standard transactions. In that case, it woul=
d
>>>> be
>>>> > > better to not have it at all.
>>>> > >
>>>> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development
>>>> Mailing
>>>> > > List wrote:
>>>> > >
>>>> > > > I propose to fix this by removing the difficulty reset rule from
>>>> > > > testnet4 through a flag day hard fork on 2026-01-01.
>>>> > >
>>>> > > I would suggest to pick a date that=E2=80=99s not a holiday in man=
y places
>>>> to
>>>> > > avoid disrupting people=E2=80=99s holiday, how about 2026-01-01 in=
stead?
>>>> > >
>>>> > > Cheers,
>>>> > > Murch
>>>> >
>>>> >
>>>> > --
>>>> > 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+...@googlegroups.com.
>>>> > To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2=
506a2410b29%40murch.one.
>>>>
>>>>
>>> --
>>> 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 visit
>>> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-45=
08d39cfd7dn%40googlegroups.com
>>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4=
508d39cfd7dn%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/=
CADL_X_dfaBQJDXu%3DurRn40J7fCkDAPi-sdnnCwAZd4RUgr68fw%40mail.gmail.com.

--0000000000004c7fad0633d46242
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 28,=
 2025 at 2:11=E2=80=AFAM Saint Wenhao &lt;<a href=3D"mailto:saintwenhao@gma=
il.com">saintwenhao@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"ltr">&gt; Demurrage might be askin=
g a bit much in terms of deviation.<br><br>If that&#39;s the case, then why=
 signing all blocks in signet is not &quot;too much&quot;? </div></blockquo=
te><div><br></div><div>Because signet isn&#39;t testnet? It gives up permis=
sionless block creation in return for predictability.</div><div>=C2=A0</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">Or why =
unlimited supply is not &quot;too much&quot;? </div></blockquote><div><br><=
/div><div>It might be, but it might not be, given that the point of testnet=
 is for coins to be free for developers to acquire and use without fear of =
financial loss. Thus scarcity isn&#39;t really an inviolable property of te=
stnet.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">All of these changes were put in the same basket of &q=
uot;Require unanimous consent&quot;, so why one kind of change is better or=
 worse than the others? All of them deviates from the mainnet, and we proba=
bly wouldn&#39;t want anything like that on the original chain anyway.<br><=
br>&gt; I&#39;d think that testnets should be reset more frequently than th=
at.<br><br>Then why don&#39;t we put any kind of reset logic into testnet5 =
consensus rules? Because when nothing like that is present, then testnets c=
an potentially run forever. Testnet3 is becoming an altcoin, and new testne=
ts will also be, if no significant changes will be made. Signet is not trad=
ed yet, mainly because of centralized mining, but there already are central=
ized altcoin federations, so it may change in the future.<br><br></div></bl=
ockquote><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">A=
nd again, the word &quot;reset&quot; should be replaced by &quot;abandon&qu=
ot;, unless you really want to reorganize the whole old chain of some exist=
ing testnet, by producing a stronger alternative chain in testnet5, which w=
ould replace the old network in a backward-compatible way, by mining everyt=
hing on top of the same Genesis Block, and eventually producing a bigger ch=
ainwork.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">pon., 28 kwi 2025 o 00:50=C2=A0Jameson Lopp &lt;<a href=3D"mailto:j=
ameson.lopp@gmail.com" target=3D"_blank">jameson.lopp@gmail.com</a>&gt; nap=
isa=C5=82(a):<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 27, 2025 at 12:47=E2=80=AFP=
M Saint Wenhao &lt;<a href=3D"mailto:saintwenhao@gmail.com" target=3D"_blan=
k">saintwenhao@gmail.com</a>&gt; wrote:<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">What about introducing demurrage in testnet5 consen=
sus rules?<br></blockquote><div>In general it seems desirable for a testnet=
 to be as close as possible to mainnet&#39;s rules. Demurrage might be aski=
ng a bit much in terms of deviation.</div><div><br></div><div>I&#39;d sugge=
st simply disabling the halving logic and making it a perpetual 50 TBTC iss=
uance. At that rate, it would still take ~8 years or so to surpass the 21M =
limit and I&#39;d think that testnets should be reset more frequently than =
that.</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"><br>Testnet co=
ins were supposed to be worthless. But it failed in both testnet3 and testn=
et4. In the meanwhile, signet was introduced, to make a more stable test ne=
twork. However, signing blocks was listed on wiki page <a href=3D"https://e=
n.bitcoin.it/wiki/Prohibited_changes" target=3D"_blank">https://en.bitcoin.=
it/wiki/Prohibited_changes</a> as something, that &quot;Require unanimous c=
onsent&quot;. And, as the history can tell us, people still wanted to test =
mining anyway, which is why testnet3 and testnet4 have much more chainwork =
than signet (and when it comes to signet, sending signed-but-unmined blocks=
 to the miners was never implemented, so they had no chance to provide more=
 hashing power).<br><br>Another kind of change on the list, that would requ=
ire consent, was increasing the total number of coins beyond 21 million. Bu=
t then, testing supply limits would be harder, and it could cause integer o=
verflows in some cases. But: in all test networks, including testnet3, test=
net4, and signet, there was never a problem of &quot;not enough coins for m=
iners&quot;, so that change probably wouldn&#39;t solve any problems (and s=
eeing it in action would take years anyway; testnet4 is still far from the =
first halving, and it is traded anyway, so that change won&#39;t fix it).<b=
r><br>Then, we have the third option, which was not yet tried in test netwo=
rks: demurrage. There are two main options: burning 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 them on consensus level.<br><=
br>Also, when it comes to maintaining testnet nodes, if it would be possibl=
e to automatically remove things from the UTXO set, then it would make Init=
ial Blockchain Download easier, just because new nodes wouldn&#39;t need to=
 synchronize everything, if old coins would be automatically invalidated. I=
n practice, all nodes could be just running in pruned mode all the time, an=
d everything beyond the pruning point, could be simply ignored on consensus=
 level (which would also prevent the UTXO set from exploding). And then, if=
 we would keep for example the last 2,016 blocks, then the whole chain woul=
d 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 Blockchain 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 napi=
sa=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">Goo=
d point on not having the flag day on a holiday. One or two weeks sounds go=
od 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">https://groups.google.com/d/msgid/bitcoinde=
v/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=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.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">https://groups.googl=
e.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegrou=
ps.com</a>.<br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></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/CADL_X_dfaBQJDXu%3DurRn40J7fCkDAPi-sdnnCwAZd4RUgr68fw%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CADL_X_dfaBQJDXu%3DurRn40J7fCkDAPi-sdnnCwAZd4RUgr68fw%40ma=
il.gmail.com</a>.<br />

--0000000000004c7fad0633d46242--