summaryrefslogtreecommitdiff
path: root/72/50086ed052c2081487fbd3e3567e3500e0eef5
blob: 6ade1fcfcad025041324fe8f162c0f03261adec6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
Delivery-date: Tue, 29 Apr 2025 07:15:35 -0700
Received: from mail-qt1-f190.google.com ([209.85.160.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABB6V5YPAAMGQEM7ZSXHA@googlegroups.com>)
	id 1u9lkD-0002bS-RZ
	for bitcoindev@gnusha.org; Tue, 29 Apr 2025 07:15:35 -0700
Received: by mail-qt1-f190.google.com with SMTP id d75a77b69052e-47ae87b5182sf113064821cf.2
        for <bitcoindev@gnusha.org>; Tue, 29 Apr 2025 07:15:34 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1745936127; cv=pass;
        d=google.com; s=arc-20240605;
        b=CAC0pqGzb+SGefd8eQbcHLTgItNcxovkC/TINg7nvui+HI43IwUqSCTaDyTg2zmR8M
         aslXnoGluZYwmpdn5ZPeB/OheMQGw836y5Twr03cHIBDsPUF2JLJjvxJPVmoETh89+er
         u2Hx+EDiHyycPEp0bSY0mGC4/dThHppDYZKieI/TO2ODY2dCyqMAtzrUUMJNO+hWIWcG
         mwXIXgHaoQqWnAhgm9ETFTaXiLBMX5pv1A/5P4dwsz5yLMyEQhnfiYv+h3DMCFNruTUR
         BsDke0Uwt7a/SoMGM1fvaeoNmqm6jEZUX6XMn6SyJw73TYHMKpn4nNON0ZNzl9dkpV0k
         h61g==
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:date:message-id
         :content-transfer-encoding:mime-version:references:in-reply-to
         :subject:to:from:sender:dkim-signature;
        bh=sMpnTn+PfsmQNE56G3AnaWAiO22+2QkHSN1L7j5AA3c=;
        fh=vyeV+ICBaTNB4A+Du1HAbpudksOQxIvNSOSprJA0sIA=;
        b=ew6Le0syzfZKXYx/TkzG13xDGC5RHvHqU8SI6ENdORpJbTU+jSpGvZvaRt4VFNgl05
         XALGS/219VDl+sly8Pygn7bGB/YipOEqXrAf49PNz/EX9BRQF986kOoPztTl6Uds/GdZ
         EO+1Plm5kQdWC9+guVSgeqkOk4m8Z6bbo6RIF+nFiXO478P0AWoRjwfe4MVUtWNaMOsE
         nNExQ0OGQ2wlqnY7soVd6m0NELteDDEL8ogc/5xbpPOIxA6oW+fGMLAOUW+Vz612Ja2a
         9CIezD6bU8gZDU8qu7cCwI4VPzNWKrdo68nOWHn/8HVEw3Es2If1PmY2CeJaaMgNKIdC
         mZpA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org
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:x-original-authentication-results
         :x-original-sender:date:message-id:content-transfer-encoding
         :mime-version:references:in-reply-to:subject:to:from:sender:from:to
         :cc:subject:date:message-id:reply-to;
        bh=sMpnTn+PfsmQNE56G3AnaWAiO22+2QkHSN1L7j5AA3c=;
        b=Ua0w4t4UDjGp/+D259gI8KNr74ELtmWYNxDrzz7Qd3AUPLG6VlnBmt4ymqecpuutBR
         nMHlE6urPngBlLWHOi60Uej/EiT71bSgnXBItCyGiHDbzdeNcu3+DjXLBfcTAF8a5FJH
         h5r3Wqho5OWDMz6z4KvEhUO6U+E/1Zy69SimtR4Ijrv0U62lbH1PVeKTbxSmzG37M7XG
         IOpHN1b/hqSFqp3D8+Zm/1Z7pqZyGUmtWAQnQPExyqB0X7wFbbR5hINDgGal6+KpaQVf
         ILdVrw53ow4Ins/Tgj5Bd19Fi29pRVHorQed3BeFtttOfZU/PbYCoznRijiWzicfENIa
         kiMA==
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:x-original-authentication-results
         :x-original-sender:date:message-id:content-transfer-encoding
         :mime-version:references:in-reply-to:subject:to:from:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=sMpnTn+PfsmQNE56G3AnaWAiO22+2QkHSN1L7j5AA3c=;
        b=WHCLgeSt6n/7lGwHt3FURW/h581KzaVNwe3pkYk1tmlGG6ZNcEJ2X6AG9GvTGipVlT
         znJsx3UvVMcn92loMCiTVlPZNPfz7IQpTjb1Kc+HwKTScg5sx3hslJwh9e3P8qmfr7pn
         Zwubp2MVm5cSESG6w4q9k2pO7qzbTwIlsYJTKrjtn5m6SQaIp7/L/DB7Pq6e4EYcpzaZ
         PNlaMv/cKahxriAoky2UHMpv5uTyU+V9elXE7THc/SdQLJ6d52amIA7chU4tasrMikJH
         O3M2t3i/oS8ymVGnsuExT237kjczo/YxnRKHmSwVFZoxtqPM3wB8ozT/HbX8KcgYAVee
         JYtQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXzm+OYRLR+8SYpxF0MYnlqg3GAxI5xUFVTH+XqcC6jntwZgY7Bgz+owqAm7AFSf+g6KjYQeWckkIHS@gnusha.org
X-Gm-Message-State: AOJu0Yy3BsU0llM3au5nhhgywnLO4taWz92WO02vVu+w2HB2NS1Li8kI
	fSNroW/fZDPm6l+UALrKjWlDISAJBek/XHkOnNJuHfFGl9LC03VL
X-Google-Smtp-Source: AGHT+IEdwUqc3GTUBvr15O4gId4q8gda9E1vteMubGbvucwvOc4WJFFVIoZIuSjZbBcmcRBZxojW0Q==
X-Received: by 2002:a05:622a:259a:b0:476:6b20:2cea with SMTP id d75a77b69052e-4881577034dmr64759271cf.39.1745936126657;
        Tue, 29 Apr 2025 07:15:26 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFYLqYDPqxfdaZnwgHfCEtmmkMJEnl1BEi29VAxoguVBQ==
Received: by 2002:a05:622a:1a23:b0:476:90b0:85b7 with SMTP id
 d75a77b69052e-47e5b43ed73ls7962741cf.2.-pod-prod-09-us; Tue, 29 Apr 2025
 07:15:22 -0700 (PDT)
X-Received: by 2002:a05:620a:3909:b0:7c7:9aed:1f36 with SMTP id af79cd13be357-7cabddb6520mr544877885a.40.1745936122042;
        Tue, 29 Apr 2025 07:15:22 -0700 (PDT)
Received: by 2002:a05:600c:45cf:b0:43d:85ca:231a with SMTP id 5b1f17b1804b1-440a669253cms5e9;
        Mon, 28 Apr 2025 06:30:11 -0700 (PDT)
X-Received: by 2002:a05:600c:524f:b0:43d:2230:300f with SMTP id 5b1f17b1804b1-440a6347ca0mr89687165e9.0.1745847009457;
        Mon, 28 Apr 2025 06:30:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1745847009; cv=none;
        d=google.com; s=arc-20240605;
        b=dOZSh5Z1trP1IfT+o73IWt7vIgrXnnGh2+IJeSbg0JcFGbqpYFCk2lln4jv7eCV1dR
         Dh8PoVERudUpNIvDy/sapVZxhgdRqq0riPUezhBUupOyIabdpwxey9wfxeRcGRyBDkbG
         k5m3YUkkVf7cQ11d64Ez3WxHUxlLKJgHY3nJJPZXNwJcEuoYv6bxBaQcBcegjc2JpNMx
         dKeaEzgoCf9TwpNKLDhiDZcZHzLNbQER23zxUrnc99UGUhgieQEWmqvK76RfE+kAN4vT
         TFjdiMbJtatZSErc3JxJPhp3NMZcIVrqw1yxcEbPhOtCLAVaSVDpBrZy1EjaB+XQTYk1
         0SKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=date:message-id:content-transfer-encoding:mime-version:references
         :in-reply-to:subject:to:from;
        bh=3zJ3W8yBTXppj69fGX7qDy2sSebnjykkCtuvnYkAi38=;
        fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=;
        b=hTiq3d+bhfbsc6MxcQqQn9gzJHXKpDTTwueXMFGE2WEH9aKaNqP8P1NucM1m04TFju
         lya+MGjIGDFZADdUo4buKN3wKx3K4w+2MRinp8PbU2LJpVYK7zl97dIYocNmS6sOqREg
         ulBmCFQYu+hwwzQ8Ef3pKfFg6s2F97T8sfFRBni7+RYj2IoCqVaWR64rX7Bq5jtgcKCg
         ci2z57UiAQwzdZ1RQgned6wz5MaxmLAwdW06xF96aTi5CztWbutoKzfUaupb5akk2laq
         z4/R9Aar6CK3tbYLX/Npkan7SDFVHM1N1bGZFoli77huN5cbQl4kCpBfkD4nyRB5y1qh
         W/xw==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) smtp.mailfrom=pithosian@i2pmail.org
Received: from mail.i2pproject.net (mail.i2pproject.net. [91.143.83.7])
        by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4408d059ef2si3570435e9.1.2025.04.28.06.30.09
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 28 Apr 2025 06:30:09 -0700 (PDT)
Received-SPF: pass (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as permitted sender) client-ip=91.143.83.7;
Received: from i2prouter.i2p.net ([81.7.8.99] helo=smtp.postman.i2p)
	by mail.i2pproject.net with esmtp (Exim 4.96)
	(envelope-from <pithosian@i2pmail.org>)
	id 1u9OYg-00ATsD-1i
	for bitcoindev@googlegroups.com;
	Mon, 28 Apr 2025 15:30:08 +0200
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: pithosian <pithosian@i2pmail.org>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Unbreaking testnet4
In-Reply-To: <20250428110655.D4A1C7C0AE9@smtp.postman.i2p>
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>
	<20250428110655.D4A1C7C0AE9@smtp.postman.i2p>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.103.X on milter.postman.i2p
Message-Id: <20250428114858.46B477C1126@smtp.postman.i2p>
Date: Mon, 28 Apr 2025 11:48:58 +0000 (UTC)
X-Spam-Score: -4.4 (----)
X-Original-Sender: pithosian@i2pmail.org
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of pithosian@i2pmail.org designates 91.143.83.7 as
 permitted sender) smtp.mailfrom=pithosian@i2pmail.org
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.8 (/)

On Sun, 27 Apr 2025 22:54:54 +0000 (UTC)
Jameson Lopp <jameson.lopp@gmail.com> wrote:
> 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.

On Mon, 28 Apr 2025 11:06:55 +0000 (UTC)
Jameson Lopp <jameson.lopp@gmail.com> wrote:
> 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.
What about having the halving act as a reset? Eg: don't reduce the
mining reward AND disallow spends of UTXOs from before the last halving.

> On Mon, Apr 28, 2025 at 2:11=E2=80=AFAM Saint Wenhao <saintwenhao@gmail.c=
om>
> wrote:
>=20
> > > 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"?
> >
>=20
> Because signet isn't testnet? It gives up permissionless block
> creation in return for predictability.
>=20
>=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 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.
>=20
>=20
> > 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.
> >
> >
> 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.
>=20
> 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 <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 to mainnet's rules. Demurrage might be asking a bit much
> >> in terms of deviation.
> >>
> >> 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 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,
> >>> 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).
> >>>
> >>> Another kind of change on the list, that would require consent,
> >>> was increasing the total number of coins beyond 21 million. But
> >>> then, testing supply limits would be harder, and it could cause
> >>> integer overflows in some cases. But: in all test networks,
> >>> including testnet3, testnet4, and signet, there was never a
> >>> problem of "not enough coins for miners", so that 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 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 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.
> >>>
> >>> Also, when it comes to maintaining testnet nodes, if it would be
> >>> possible 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, 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 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 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 <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 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.
> >>>> > >
> >>>> > > 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 m=
any
> >>>> > > places
> >>>> to
> >>>> > > avoid disrupting people=E2=80=99s holiday, how about 2026-01-01
> >>>> > > instead?
> >>>> > >
> >>>> > > 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=
-2506a2410b29%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-=
4508d39cfd7dn%40googlegroups.com
> >>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c=
-4508d39cfd7dn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> >>> .
> >>>
> >>
>=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/=
20250428114858.46B477C1126%40smtp.postman.i2p.