From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 29 Apr 2025 07:15:35 -0700 Received: from mail-qt1-f185.google.com ([209.85.160.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1u9lkE-0002bT-FT for bitcoindev@gnusha.org; Tue, 29 Apr 2025 07:15:35 -0700 Received: by mail-qt1-f185.google.com with SMTP id d75a77b69052e-47b36edcdb1sf81315731cf.2 for ; Tue, 29 Apr 2025 07:15:34 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1745936128; cv=pass; d=google.com; s=arc-20240605; b=NsgkJHMU7m+7Vqr1fBbvCrpjNpFK8dUIDBwgVpYKwmqNFtq8hLhjIe+SSwzSCxATtl EZstFeTlTVrEmhpYpegA6oEu1ElfkEhpGqDE4FTjwrxUdR5o0NO1uFpI4jzorDVeeFHo uil67Ib1OeJAHQhKVtRGPflnbAfNEguawYEN1sIKSfr5rcZz/i+au5cjNF0FcgcLS2im OtOBwxDGTLxJXJA5/6feKGoZCEQ5lSp4pC5V00LL9CAr13Z6CYcnKHsxSEMDGjseBf9O rJgDYEPAo+eptH85uafkn+JWTm6qzK+AXoyXJkIUVpt5fH20mYV36i9EZru59HdfLITp ol3g== 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=/EndGOHnzIpt5yd9qZDtkFxlWLV2IIoJkHhkrEpKzUk=; fh=b8LnW7w2iPbqJmUtJbJJgQ6EI4nPLrZJDml8wi0eajw=; b=LPp8dwhPW/3uPxQ+Ip5Ppzt5f3ny//hrIMaL9hnk15QnkLmZ4v+TCrNuUztCk+RwW0 0dLWfbqopu9GvmosYGs9BCFEwjy2WaH+GHzARcTzdj+bfWnACY23/VKAcpbH/f/QSgDr pHu5RBjPzG0PtIy/WKPHClMYcWavSLfBXdnvRXA0sz5aXvn0ZPu4ODXSTbviFmV3dkEa XlCu9UVdAn4J0j7tEUatqkl0zYvtKy+hfH7DvYjSu+zuVx4+d/VQwHSnoyWhKKSNRPWq Yxr6w5o6aLpmKxTVURoWf3dmUWMV7/U4b5KPdncZ4Ik9EJ3GkMf9cKRdWhwgnw1ConYO N1nA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=lQA18a8y; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=saintwenhao@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=1745936128; x=1746540928; 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=/EndGOHnzIpt5yd9qZDtkFxlWLV2IIoJkHhkrEpKzUk=; b=q55uZEDmGIqDifO1FiVfRbywyBsFOjvc2+PM5H98O6Ptn7Uxuj8WPFJgGtQx4rfh95 A724kOQf3FS1w0yRWPFFGkiOLci3tpvbQvB36GOGaJ6wJqukydo+llKZXyi/YXYggRQz x+pB8bOydhfSS8VXamg1k+5psE8KAiypL16PvYUTKSp+QUquRosbwmYydgkR0YiSEabJ Jps9nI0ENGE1jDRCaMKXRAgBEgPg8O3w58abivoRmEnEOuWqMJF9/q+ho8NHRw6aWiMs PVorBOTy4Y29NGDvjRVXmWBGFNYhZa36hp5aa2qr2oOp/BZEgJa4qZuJJuAigZKYMD3v Eh8g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745936128; x=1746540928; 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=/EndGOHnzIpt5yd9qZDtkFxlWLV2IIoJkHhkrEpKzUk=; b=TrHvoEIGv2WiOL9no6zksHAZH5//YJvn63DZ25nSCIpXxT7y76KAJsJqVX7DbFJ8GG ttms0Q9vZoxjHJsSeiJv5cegAWcYRQZ1/G10XTkUkpTaJx5IofwU6tatROKJUmGyCUl0 p/x5phhmKKDTwy3GtuSnFqfcN6g3ysJH24BC98e6nU7Hwb4xDBwfKU7qXkUAaBG3su57 iF1sm66reT9TG3XrsLuAL10zBvZZHhhF/IrFZC9/gLoVgByIdBQr4P/K46Gb8LKz1aUu Lkwo0yttGa88OE/clJbO5i/FK36ZPbCLj4zJXjXeshm+GUJ+djvR2Mddb2525FaX4i3Z BDvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745936128; x=1746540928; 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=/EndGOHnzIpt5yd9qZDtkFxlWLV2IIoJkHhkrEpKzUk=; b=vxAGe0Ua6E28Faskfh4Q6u7loa9j4QO5LDavcWQIhVau1h+/cCAYa0CS06cftGnrp0 sssRu8DUXQ5HIhfS+hMMYaVFnroBF6JAGXAygekHmib+YlCSLRiyU0hkgLmbCjyoZd8D Gb/Hzb3dg9jikry5rLAF6kzaYJ1V7EKpkdBYTpqMBy4J6/V4pABpdH4AKmichig8lipk a+snj97Pl9VDmR3yYVCcpCgvIuLoZ3jWkxYQ6/Ro25jf69BuaifXtT4KF0M6Wuqu0Dh/ fpY/MjXXpXmnrDXrWWHe8qmr3EP8I+yG1dNA8SdXCz7LdilhQnZ7g9cZextGQeYTr6Hz EKkw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUXASwWrC2EZmLDAXTp2Uv8jF94YJNcB1Wq1+QxG0QhWyADk23cAvBqIOPShaNcwPhGILsax17Kf8fm@gnusha.org X-Gm-Message-State: AOJu0Ywa16mMS8BQ21jtB+wLAQJAfyAgDAUULmxKn2syOUdOHPw0/j6X rcjJ62DmUGw6pctKYdPO7E6NmynmLn4I/PSYvCWYpOoO+KIc2kwl X-Google-Smtp-Source: AGHT+IEFtg+p9aCM+OX6mhd6gehsfodQJX2bNQjc73fZAWckyvrf9AFaSxQ53IEpPAZz24QsDSmHEw== X-Received: by 2002:ac8:5f87:0:b0:476:b06a:716e with SMTP id d75a77b69052e-48133177341mr226374291cf.34.1745936126791; Tue, 29 Apr 2025 07:15:26 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHaGY343aXXwVILHjgK/IB6ZH99NMHloVBJP8TADpX4aQ== Received: by 2002:a05:622a:1f11:b0:476:7e35:1cd5 with SMTP id d75a77b69052e-47e5b535e28ls31050951cf.0.-pod-prod-04-us; Tue, 29 Apr 2025 07:15:22 -0700 (PDT) X-Received: by 2002:a05:620a:298d:b0:7c5:4a3a:bc12 with SMTP id af79cd13be357-7c96687d6f6mr2104157285a.32.1745936121818; Tue, 29 Apr 2025 07:15:21 -0700 (PDT) Received: by 2002:ab3:73cb:0:b0:293:32b4:31b9 with SMTP id a1c4a302cd1d6-2a8b77d9ab3msc7a; Sun, 27 Apr 2025 23:11:23 -0700 (PDT) X-Received: by 2002:a2e:8717:0:b0:31a:466a:4746 with SMTP id 38308e7fff4ca-31a466a49cemr20144401fa.28.1745820681237; Sun, 27 Apr 2025 23:11:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1745820681; cv=none; d=google.com; s=arc-20240605; b=lLTqnVTlfjb4uTNDnizq/w6KnDKfHHtB2l7ncOH16+HFneNYJgs2a4UAPxYNCvpVPG FdroELHeZIbzTyGs8CqRKN6/e0agR3XbslpgOabzX8IIebdPLK2kneQZ7iZ+L4h1tZWE DN/HhyOKXjvurFaEyg+jlSFW1UIcJ2Y1aA25yc458W1w5/qIX5t9QeGf9pmj70e0MR9l vbVyf2jA8HLsjtw/WiRu1OC4J87RBGUG6RfPF0RnMQUyG0NI+MEjX4hDCVumkvgqt8ni GVyKKXHiiGtXLTA62O7oP9XqBhiqnaQ7OBL1uY8eyKZIrcbT6z1s/yGoDJwCzld8FyM/ It2A== 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=XxW9v2CWaH1U8zAn8FsYDa/agucF+4djROQSEkB5clQ=; fh=dEDbYMbbYyDNRr1LOwMlw2+lJDEDNk0XskwzeS3uI5o=; b=k0IkbcIecvEAncOpKNyJx9AW2EOcjbF2ZILbOY6lYZ6fnddJDTa62Q7XP3GMgTmLPB ZQ7ZPKMbrM8hed1tathySlxdqD3PxtzFDa29foYZaKjNo/SiHWbDPi6jBw+p79ix/fgm nCSfFrZo30L0pPkXLBwtRFYIZ+6+DXIRCsJX4XFBmv1N1DS2Pk90ZfZtHJvXRQ64hHwV we9No3L1oAwHFo3NVqAzpXOqGfFJov5GcTzJMJgJ2QLBbxBAQHhRs+aU1uchivDsRnTg Eqt+zia4XMya32yapJefEWJcnD8y1D4F1EBDsYMcFr/pnicTu10mUjcPJTYF2KoZkQeB Zlcg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=lQA18a8y; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com. [2a00:1450:4864:20::536]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-318b49b4b4asi2742171fa.0.2025.04.27.23.11.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Apr 2025 23:11:21 -0700 (PDT) Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) client-ip=2a00:1450:4864:20::536; Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5e8be1c6ff8so7151081a12.1 for ; Sun, 27 Apr 2025 23:11:21 -0700 (PDT) X-Gm-Gg: ASbGncuCYHQwMBecJbklZ1yIaX0HtUgZsvKUL7fY37gaQtxCruOCcXJLrZsGFqIoEQP znGe0hLBPE0/gNVJ7FZrRGSp8Lc+4J9CaUBBRDWi2ng3EC+gaGGssJr3iFMPMNJCiHo/qCj3gJE EU6v/2uv3Vxg9p44kflDGS X-Received: by 2002:a05:6402:13c8:b0:5ed:1d8d:c6d8 with SMTP id 4fb4d7f45d1cf-5f72267c079mr7872612a12.9.1745820679613; Sun, 27 Apr 2025 23:11:19 -0700 (PDT) MIME-Version: 1.0 References: <5c13e130-aaa2-4866-be26-7498100e868b@murch.one> <7c6800f0-7b77-4aca-a4f9-2506a2410b29@murch.one> <672cb527-9005-46fc-be2c-4508d39cfd7dn@googlegroups.com> In-Reply-To: From: Saint Wenhao Date: Mon, 28 Apr 2025 08:11:08 +0200 X-Gm-Features: ATxdqUFKSWPhoY29is-jgVXmQ-FdsTu1Welc-O09zfX-jj2s9trOt48EEuqBrv4 Message-ID: Subject: Re: [bitcoindev] Unbreaking testnet4 To: Jameson Lopp Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000732ef50633d08d44" X-Original-Sender: saintwenhao@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=lQA18a8y; spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::536 as permitted sender) smtp.mailfrom=saintwenhao@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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) --000000000000732ef50633d08d44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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"? Or why unlimited supply is not "too much"? 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? All 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 testnets will also be, if no significant changes will be made. Signet is not traded yet, mainly because of centralized mining, but there already are centralized altcoin federations, so it may change in the future. And again, the word "reset" should be replaced by "abandon", unless you really want to reorganize the whole old chain of some existing testnet, by producing a stronger alternative chain in testnet5, which would replace the 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 napisa=C5= =82(a): > > > On Sun, Apr 27, 2025 at 12:47=E2=80=AFPM Saint Wenhao > wrote: > >> What about introducing demurrage in testnet5 consensus rules? >> > In general it seems desirable for a testnet to be as close as possible to > mainnet's rules. Demurrage might be asking a bit much in terms of deviati= on. > > 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 pag= e >> https://en.bitcoin.it/wiki/Prohibited_changes as something, that >> "Require unanimous consent". And, as the history can tell us, people sti= ll >> wanted to test mining anyway, which is why testnet3 and testnet4 have mu= ch >> more chainwork than signet (and when it comes to signet, sending >> signed-but-unmined blocks to the miners was never implemented, so they h= ad >> 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, testin= g >> supply limits would be harder, and it could cause integer overflows in s= ome >> cases. But: in all test networks, including testnet3, testnet4, and sign= et, >> there was never a problem of "not enough coins for miners", so that chan= ge >> probably wouldn't solve any problems (and seeing it in action would take >> 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 th= em >> 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 burnin= g, >> and just treat all coins older than N blocks in the same way, as OP_RETU= RN, >> by simply invalidating transactions spending them on consensus level. >> >> 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 >> 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 mode all the time, a= nd >> everything beyond the pruning point, could be simply ignored on consensu= s >> 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 wo= uld >> never take more than 2016 * 4 MB =3D 8.064 GB 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 napisa= =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 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 it= s >>> intended >>> > > purpose of allowing developers to mine themselves a few coins easil= y >>> or >>> > > confirm their own non-standard transactions. In that case, it would >>> 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 many= places >>> to >>> > > avoid disrupting people=E2=80=99s holiday, how about 2026-01-01 ins= tead? >>> > > >>> > > 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, sen= d >>> an email to bitcoindev+...@googlegroups.com. >>> > To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-25= 06a2410b29%40murch.one. >>> >>> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-450= 8d39cfd7dn%40googlegroups.com >> >> . >> > --=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/= CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A%40mail.gmail.com. --000000000000732ef50633d08d44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Demurrage might be asking a bit much in terms of devi= ation.

If that's the case, then why signing all blocks in signet= is not "too much"? Or why unlimited supply is not "too much= "? All of these changes were put in the same basket of "Require u= nanimous consent", so why one kind of change is better or worse than t= he others? All of them deviates from the mainnet, and we probably wouldn= 9;t want anything like that on the original chain anyway.

> I'= ;d think that testnets should be reset more frequently than that.

Th= en why don't we put any kind of reset logic into testnet5 consensus rul= es? Because when nothing like that is present, then testnets can potentiall= y run forever. Testnet3 is becoming an altcoin, and new testnets will also = be, if no significant changes will be made. Signet is not traded yet, mainl= y because of centralized mining, but there already are centralized altcoin = federations, so it may change in the future.

And again, the word &qu= ot;reset" should be replaced by "abandon", unless you really= want to reorganize the whole old chain of some existing testnet, by produc= ing a stronger alternative chain in testnet5, which would replace the old n= etwork in a backward-compatible way, by mining everything on top of the sam= e Genesis Block, and eventually producing a bigger chainwork.

pon., 28 kwi 2025 o 00:50=C2=A0Jameson Lopp <jameson.lopp@gmail.com> napisa=C5=82(a):
<= /div>


On Sun, Apr 27, 2025 at 12:47=E2=80=AFPM Saint Wenhao <= ;saintwenhao@gma= il.com> wrote:
What about introducing demurrage in testnet5 consensus rules?
In general it seems desirable for a testnet to be as close as= possible to mainnet's rules. Demurrage might be asking a bit much in t= erms of deviation.

I'd suggest simply disablin= g the halving logic and making it a perpetual 50 TBTC issuance. At that rat= e, 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 meanwh= ile, signet was introduced, to make a more stable test network. However, si= gning blocks was listed on wiki page https://en.bitcoin.it/wiki/Prohibited= _changes as something, that "Require unanimous consent". And,= as the history can tell us, people still wanted to test mining anyway, whi= ch is why testnet3 and testnet4 have much more chainwork than signet (and w= hen 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 i= ncreasing the total number of coins beyond 21 million. But then, testing su= pply limits would be harder, and it could cause integer overflows in some c= ases. But: in all test networks, including testnet3, testnet4, and signet, = there was never a problem of "not enough coins for miners", so th= at change probably wouldn't solve any problems (and seeing it in action= would take years anyway; testnet4 is still far from the first halving, and= it is traded anyway, so that change won't fix it).

Then, we hav= e the third option, which was not yet tried in test networks: demurrage. Th= ere are two main options: burning coins, or re-assigning them to someone el= se. To make a soft-fork out of it, re-assigning would be backward-incompati= ble, 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 invalid= ating transactions spending them on consensus level.

Also, when it c= omes to maintaining testnet nodes, if it would be possible to automatically= remove things from the UTXO set, then it would make Initial Blockchain Dow= nload easier, just because new nodes wouldn't need to synchronize every= thing, if old coins would be automatically invalidated. In practice, all no= des could be just running in pruned mode all the time, and everything beyon= d the pruning point, could be simply ignored on consensus level (which woul= d also prevent the UTXO set from 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's all we would need = to send during Initial Blockchain Download to other nodes.

poniedzia=C5=82ek,= 31 marca 2025 o=C2=A022:50:27 UTC+2 Antoine Poinsot napisa=C5=82(a):
Good point on not hav= ing 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> w= rote:

>=20
>=20
> Errr, I wrote the same date as you, but I meant a week later, 2026= -01-08
> instead.
>=20
> -Murch
>=20
> On 2025-03-21 14:20, Murch wrote:
>=20
> > Hey Antoine and everyone,
> >=20
> > What you suggest makes sense to me. Since the 20-minute diffi= culty
> > exception is now exploited perpetually, it doesn=E2=80=99t se= rve its intended
> > purpose of allowing developers to mine themselves a few coins= easily or
> > confirm their own non-standard transactions. In that case, it= would be
> > better to not have it at all.
> >=20
> > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin De= velopment Mailing
> > List wrote:
> >=20
> > > I propose to fix this by removing the difficulty reset r= ule from
> > > testnet4 through a flag day hard fork on 2026-01-01.
> >=20
> > I would suggest to pick a date that=E2=80=99s not a holiday i= n many places to
> > avoid disrupting people=E2=80=99s holiday, how about 2026-01-= 01 instead?
> >=20
> > Cheers,
> > Murch
>=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 email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.

--
You received this message because you are subscribed to the Google Groups &= quot;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.googl= e.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegrou= ps.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/ms= gid/bitcoindev/CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A%40mail.g= mail.com.
--000000000000732ef50633d08d44--