summaryrefslogtreecommitdiff
path: root/15/fd093d723718b874fcb360d6ddb99bdc77b9d8
blob: e74a1acd6587a1f03931f4a7be87ca13dc019693 (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
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
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 <bitcoindev+bncBC7YL44NVYFRB6V5YPAAMGQE3PRIV5I@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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: <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>
In-Reply-To: <CADL_X_eXcmD8fEpL9Sqqwt6EfwtdjG+Aaqk+pgSBhPmaVT3gEw@mail.gmail.com>
From: Saint Wenhao <saintwenhao@gmail.com>
Date: Mon, 28 Apr 2025 08:11:08 +0200
X-Gm-Features: ATxdqUFKSWPhoY29is-jgVXmQ-FdsTu1Welc-O09zfX-jj2s9trOt48EEuqBrv4
Message-ID: <CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A@mail.gmail.com>
Subject: Re: [bitcoindev] Unbreaking testnet4
To: Jameson Lopp <jameson.lopp@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <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 (/)

--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 <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 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 <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 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
>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-45=
08d39cfd7dn%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/=
CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A%40mail.gmail.com.

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

<div dir=3D"ltr">&gt; Demurrage might be asking a bit much in terms of devi=
ation.<br><br>If that&#39;s the case, then why signing all blocks in signet=
 is not &quot;too much&quot;? Or why unlimited supply is not &quot;too much=
&quot;? All of these changes were put in the same basket of &quot;Require u=
nanimous consent&quot;, 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&#3=
9;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 that.<br><br>Th=
en why don&#39;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.<br><br>And again, the word &qu=
ot;reset&quot; should be replaced by &quot;abandon&quot;, 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.</div><br><div=
 class=3D"gmail_quote gmail_quote_container"><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">jameson.lopp@gmail.com</a>&gt; napisa=C5=82(a):<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Sun, Apr 27, 2025 at 12:47=E2=80=AFPM Saint Wenhao &lt=
;<a href=3D"mailto:saintwenhao@gmail.com" target=3D"_blank">saintwenhao@gma=
il.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">What about introducing demurrage in testnet5 consensus rules?<br></bl=
ockquote><div>In general 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 t=
erms of deviation.</div><div><br></div><div>I&#39;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&#39;d =
think that testnets should be reset more frequently than that.</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><br>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 <a href=3D"https://en.bitcoin.it/wiki/=
Prohibited_changes" target=3D"_blank">https://en.bitcoin.it/wiki/Prohibited=
_changes</a> as something, that &quot;Require unanimous consent&quot;. 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).<b=
r><br>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 &quot;not enough coins for miners&quot;, so th=
at change probably wouldn&#39;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&#39;t fix it).<br><br>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.<br><br>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&#39;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&#39;s all we would need =
to send during Initial Blockchain Download to other nodes.<br><br><div clas=
s=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">poniedzia=C5=82ek,=
 31 marca 2025 o=C2=A022:50:27 UTC+2 Antoine Poinsot napisa=C5=82(a):<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">Good point on not hav=
ing the flag day on a holiday. One or two weeks sounds good to me.
<br>
<br>
<br>
<br>
<br>On Monday, March 24th, 2025 at 8:25 AM, Murch &lt;mu...@murch.one&gt; w=
rote:
<br>
<br>&gt;=20
<br>&gt;=20
<br>&gt; Errr, I wrote the same date as you, but I meant a week later, 2026=
-01-08
<br>&gt; instead.
<br>&gt;=20
<br>&gt; -Murch
<br>&gt;=20
<br>&gt; On 2025-03-21 14:20, Murch wrote:
<br>&gt;=20
<br>&gt; &gt; Hey Antoine and everyone,
<br>&gt; &gt;=20
<br>&gt; &gt; What you suggest makes sense to me. Since the 20-minute diffi=
culty
<br>&gt; &gt; exception is now exploited perpetually, it doesn=E2=80=99t se=
rve its intended
<br>&gt; &gt; purpose of allowing developers to mine themselves a few coins=
 easily or
<br>&gt; &gt; confirm their own non-standard transactions. In that case, it=
 would be
<br>&gt; &gt; better to not have it at all.
<br>&gt; &gt;=20
<br>&gt; &gt; On 2025-03-18 07:29, &#39;Antoine Poinsot&#39; via Bitcoin De=
velopment Mailing
<br>&gt; &gt; List wrote:
<br>&gt; &gt;=20
<br>&gt; &gt; &gt; I propose to fix this by removing the difficulty reset r=
ule from
<br>&gt; &gt; &gt; testnet4 through a flag day hard fork on 2026-01-01.
<br>&gt; &gt;=20
<br>&gt; &gt; I would suggest to pick a date that=E2=80=99s not a holiday i=
n many places to
<br>&gt; &gt; avoid disrupting people=E2=80=99s holiday, how about 2026-01-=
01 instead?
<br>&gt; &gt;=20
<br>&gt; &gt; Cheers,
<br>&gt; &gt; Murch
<br>&gt;=20
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a rel=3D"nofollow">bitcoindev+...@googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one" rel=
=3D"nofollow" target=3D"_blank">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>

<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/CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A%40mail.g=
mail.com</a>.<br />

--000000000000732ef50633d08d44--