From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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" To: Bitcoin Development Mailing List Message-Id: <47f218f0-4c7d-464c-a68c-04bcfeb5b76dn@googlegroups.com> In-Reply-To: References: <5c13e130-aaa2-4866-be26-7498100e868b@murch.one> <7c6800f0-7b77-4aca-a4f9-2506a2410b29@murch.one> <672cb527-9005-46fc-be2c-4508d39cfd7dn@googlegroups.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 Reply-To: emsit 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: -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 = 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 napisa=C5= =82(a): >> >>> >>> >>> On Sun, Apr 27, 2025 at 12:47=E2=80=AFPM Saint Wenhao =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 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 >>>> >>>> . >>>> >>> --=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.
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.
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.
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.
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.
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.

<= 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
On Mon, Apr 28, 20= 25 at 2:11=E2=80=AFAM Saint Wenhao <saint...@gmail.com> wrote:
> Demurrage might be asking a bit much in terms o= f deviation.

If that's the case, then why signing all blocks in signet i= s not "too much"?

Because = signet isn't testnet? It gives up permissionless block creation in retu= rn for predictability.
=C2=A0
Or why unlimited supply is not "t= oo much"?

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't really an inviolable property of testnet.
=C2=A0
All of the= se changes were put in the same basket of "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't want anything = like that on the original chain anyway.


> I'd think that testnets sho= uld be reset more frequently than that.

Then why don'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.


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.=C2=A0

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 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.

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


On Sun, Apr 27, 2025 at 12:47=E2=80=AFPM Saint Wenhao <<= a href data-email-masked rel=3D"nofollow">saint...@gmail.com> wrote:=
What about intr= oducing demurrage in testnet5 consensus rules?
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.

I'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'd think that testnets s= hould 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 intro= duced, to make a more stable test network. However, signing blocks was list= ed on wiki page https://en.bitcoin.it/wiki/Prohibited_changes as something, tha= t "Require unanimous consent". 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).

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", so that change probably wouldn'= 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't fix it).

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.

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'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's all we would need to send during Initial Blockch= ain 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 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> 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.goog= le.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one<= /a>.

--
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+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7= dn%40googlegroups.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/msgid/bitcoind= ev/47f218f0-4c7d-464c-a68c-04bcfeb5b76dn%40googlegroups.com.
------=_Part_198753_1071964476.1745841549056-- ------=_Part_198752_1119539221.1745841549056--