summaryrefslogtreecommitdiff
path: root/90/1d929e2071978577bffd98561c24946a439672
blob: d1eddded10a89793843abb27088901c797b02091 (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
Delivery-date: Fri, 03 May 2024 17:04:34 -0700
Received: from mail-yb1-f187.google.com ([209.85.219.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCY3VBMZVAMRBCXX2WYQMGQEXTJBE5Q@googlegroups.com>)
	id 1s32tF-0007zx-UJ
	for bitcoindev@gnusha.org; Fri, 03 May 2024 17:04:34 -0700
Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-de468af2b73sf515155276.0
        for <bitcoindev@gnusha.org>; Fri, 03 May 2024 17:04:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1714781068; x=1715385868; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=yhckZmBxdTu6JOZmiYgPk+4fK8vry4AQoH04HglhZCY=;
        b=K5ZYwCk7u+X4muvMwoz0Kf87DAL2jovLfwNNWA8KgdDeDxBcGVThahQZPOpnCNpMRb
         BJxPZ0u7ruN87KW8DTg6RhhOcAIhRu3NbdyN+eu0elq5J+onfyeSH35OWuJLR1mimbj0
         fAymYMHUFu/sInS4oameZIHzNeqJ1Owrjp3NsOzY4YskpwwlEgEpDSvdHwSB3Fsrefvo
         1cVGISWURmjNBT+fKYt4pISqjR66DdUKoqfIvsepyNt7kkl6fEw6xBV2zhUfyI0arBJx
         cVDfA3NTX8FJ2mGaz+jE+cIa8yiIx8GIPJfXZB/mIVdnlr3qFLX1gX3SWKibdUZuJNOE
         TT6g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1714781068; x=1715385868; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence: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=yhckZmBxdTu6JOZmiYgPk+4fK8vry4AQoH04HglhZCY=;
        b=TyA24MyIh0Od2eSy34SxChDDwoIF+9bs9AslM0u53WH5Fj+UdVXJ8KyRf9lvOQrzv3
         yGmnQeFXIXhAeW+EHxNSuJNWPMoCx6aCRzuro7Ov8BU01/5uaqbHyScbfciQGQI6i0wg
         t8aug3QHVbA48f7YV8BBI/GvtoCcsLx4v4fGMIgfzptKYZsA5cc/O6vnVMGGTBMTmDUt
         FBM0eiz8pG93dKgO5qneySR4Uw9gYQ2TpQlpl0WvF5sp17wcgTCyEb2fe6D+tTS5Hiam
         ACtCf2/dmR7F4U4jAlfykjbpDmuOgrHr6vjvoFfaFXxKJzVC9BWbSkbhshRyMn+ofQ+7
         CoMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1714781068; x=1715385868;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=yhckZmBxdTu6JOZmiYgPk+4fK8vry4AQoH04HglhZCY=;
        b=rt06wPKe4FGDFI5ddi5p72Y8mZ210a2E4apPrzan/xFJTzYYYHsrXJIEUwQeUlZ0cz
         /p/DIZN2LVoXVlRmrDQ1T3tHsTGHUnXEyoTKMaYhaMIFCyAno63fuWjzaUPA7Dcx51eX
         YjM9ne1ucF4btufQ6MMnVvFo0Ba0DzG7Kv29z1vtUsk51btORTKzKcducTj7lpeZw3Pe
         y6Di0Ogi9vwPgIcNZMCzM2FmKjC3A8iG8C2YTFKjyYakYV9gUHuYLKDu9p0esagD6SYE
         /6aAkF3Er5jZHbKoJUwxo99FjNO491TkGlYt7QYFvBhKo9M6I2G9LCLGZvpcgYAEf/42
         4QOw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCULk5CSBhuW34fkOUQyHlHTBhd8M+AElCdGwfqcGqpDxYLUHbAngqp3ABXLPKC9zFGGLJarMYDDGar9OOPvw6FZ/NBrxi0=
X-Gm-Message-State: AOJu0Yy2JKsEwAYu2ZSfYNuUTCvdMJ4T+pGQX5H2GH+I1kp1PpBpCi1n
	CAnBX+IGt0qSjKwpfQG9hn86tUVjZKXhtMs7fICYr3/2BksUFs1X
X-Google-Smtp-Source: AGHT+IFi+uLd1SPE4nuFmIjX4kfDWYfFmEjo9tjyqipbjpJXKoUKKQ/9e9LkJu3x7rFBmcZOJu6gog==
X-Received: by 2002:a05:6902:218c:b0:dd0:3a7a:fb70 with SMTP id dl12-20020a056902218c00b00dd03a7afb70mr5561766ybb.52.1714781067952;
        Fri, 03 May 2024 17:04:27 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:c7c3:0:b0:dcd:202d:6bd6 with SMTP id 3f1490d57ef6-de8b54b9441ls717423276.1.-pod-prod-03-us;
 Fri, 03 May 2024 17:04:26 -0700 (PDT)
X-Received: by 2002:a0d:dbcd:0:b0:61a:d016:60ff with SMTP id d196-20020a0ddbcd000000b0061ad01660ffmr832272ywe.2.1714781066291;
        Fri, 03 May 2024 17:04:26 -0700 (PDT)
Received: by 2002:a05:690c:39c:b0:61b:e8f5:76d6 with SMTP id 00721157ae682-61dfb025199ms7b3;
        Wed, 1 May 2024 08:30:42 -0700 (PDT)
X-Received: by 2002:a0d:e6d5:0:b0:61b:e8a2:6f4a with SMTP id p204-20020a0de6d5000000b0061be8a26f4amr791900ywe.0.1714577441667;
        Wed, 01 May 2024 08:30:41 -0700 (PDT)
Date: Wed, 1 May 2024 08:30:41 -0700 (PDT)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <47e4f1a0-709a-438b-a3ba-9e397c373ea9n@googlegroups.com>
In-Reply-To: <3b1a26a9-acef-496a-8465-c32879d2a833n@googlegroups.com>
References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
 <ZgmJFfXnQddkTQVq@petertodd.org>
 <CAFC_Vt7zKvMEfQLzWHQ6t_9bgv1iqt4Ah8N883CuoSfmLUKdMA@mail.gmail.com>
 <ZgnVtJHn2ikLfwa9@petertodd.org>
 <CADL_X_cmcXxHke089OD_45VRJy5aR+9uj-18bSjXBE7FKwR-Jw@mail.gmail.com>
 <wKrcm6SEjcG_7UmxByP-rDDVajB7-oYJRF9p_BjLe5XVzxVV9nCB8RsTAXcD5vF_rWxUmLK4HOM7zV7U4-kZSUO9Ccj4jEehsbbb7FD45GQ=@wuille.net>
 <ZgzYtZqPcnykqyxK@erisian.com.au>
 <7a67edd1-0182-4170-90f4-998d12431024n@googlegroups.com>
 <3b1a26a9-acef-496a-8465-c32879d2a833n@googlegroups.com>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_66206_578549279.1714577441299"
X-Original-Sender: garlonicon@gmail.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 (/)

------=_Part_66206_578549279.1714577441299
Content-Type: multipart/alternative; 
	boundary="----=_Part_66207_1244780516.1714577441299"

------=_Part_66207_1244780516.1714577441299
Content-Type: text/plain; charset="UTF-8"

> Doubling every 210,000 blocks.

This can potentially increase spam. Why? Because the minimal fee is one 
satoshi per virtual byte. So, if you increase coin amounts, without 
changing anything else, then you also increase the amount of bytes, which 
you can push to the network. Because if you have 50 tBTC, then it means you 
can push 5 GB of data, so if you suddenly would get 100 tBTC per block, 
then it would increase your spamming ability to 10 GB, and then 20 GB, and 
then 40 GB, and so on.

Also, going one bit to the left in every doubling means, that after a few 
doublings, the values in 64-bit numbers will overflow, so that approach 
will recreate the Value Overflow Incident. In general, the value of 50 tBTC 
can be written as 0x12a05f200. That means, after 31 doublings, you will get 
0x9502f90000000000, corresponding to 107,374,182,400 tBTC, and the next 
value will overflow.

> impossible to try to ascribe value to that.

Even if some monetary system has some inflation, some value can always be 
assigned. For example, a lot of fiat coins like dollars, can have unlimited 
inflation. And they still have value, even if there is no max supply. There 
is even a word for what happens in systems with hyperinflation, it is 
called redenomination: https://en.wikipedia.org/wiki/Redenomination

The same with many altcoins, which don't have any upper limit. Also note, 
that in many altcoins, there is a trend of burning coins, to increase their 
value. So, the same could happen in a new testnet: claiming less coins in 
the coinbase transaction, is a perfectly valid no-fork, that would be 
compatible, so even if you type in code "you can get 100 tBTC", then miners 
could still claim only 50 tBTC or 25 tBTC, and their blocks will be valid.

Also, assuming no blockstorms, if you touch any rules, related to halvings, 
then they don't have to hit us immediately. It is possible, that for the 
next four years, everything will be fine, but after that, there will be a 
lot of drama, related to what should be the correct value of the coinbase 
transaction after that period. Note that even in the official signet, we 
are still before the first halving.

Tuesday, 30 April 2024 at 21:00:32 UTC+2 Matthew Bagazinski wrote:

Unfortunately, the current form of Testnet is doomed to have value, just 
like BTC. Its scarcity makes it a valuable asset. And no reset will change 
that. It will only result in repeated resets, multiple versions of testnet, 
and people never learning.

I have to agree with emsit here. Never underestimate the ability for people 
to ascribe value to something with provable scarcity.  I like Peter Todd's 
suggestion of removing the halving completely, so that plenty new coins are 
always coming into circulation, but it received pushback for removing the 
regular 210,000-block events. Here are a few dumb ideas to chew on to see 
if we can come up with something better:

   - Doubling every 210,000 blocks. This leads to the supply growing 
   exponentially; impossible to try to ascribe value to that.
   - Adding 1 to the subsidy every 210,000 blocks. Still an infinite 
   supply, closer to a standard subsidy, but there is still a change happening 
   every 210,000 blocks.
   - Subtracting 1 every 210,000 blocks. This is technically still scarce, 
   but a much gentler decline in admissions. Yes, it eventually drops to 0, 
   but after 50 events instead of the current 33 halvings.
   - Change "half" to some other fraction like "nine-tenths". Still 
   technically scarce, gentler decline in rewards, but still retains the 
   property of having a geometric sequence to the subsidies.

Like I said, dumb ideas, but I think there is a decision to be made between 
avoiding a future reset by mitigating reasons people add value to tBTC 
(such as scarcity) and expecting/planning for more regular resets when 
people start inevitably valuing tBTC.

-- 
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/47e4f1a0-709a-438b-a3ba-9e397c373ea9n%40googlegroups.com.

------=_Part_66207_1244780516.1714577441299
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

&gt; Doubling every 210,000 blocks.<br /><br />This can potentially increas=
e spam. Why? Because the minimal fee is one satoshi per virtual byte. So, i=
f you increase coin amounts, without changing anything else, then you also =
increase the amount of bytes, which you can push to the network. Because if=
 you have 50 tBTC, then it means you can push 5 GB of data, so if you sudde=
nly would get 100 tBTC per block, then it would increase your spamming abil=
ity to 10 GB, and then 20 GB, and then 40 GB, and so on.<br /><br />Also, g=
oing one bit to the left in every doubling means, that after a few doubling=
s, the values in 64-bit numbers will overflow, so that approach will recrea=
te the Value Overflow Incident. In general, the value of 50 tBTC can be wri=
tten as 0x12a05f200. That means, after 31 doublings, you will get 0x9502f90=
000000000, corresponding to 107,374,182,400 tBTC, and the next value will o=
verflow.<br /><br />&gt; impossible to try to ascribe value to that.<br /><=
br />Even if some monetary system has some inflation, some value can always=
 be assigned. For example, a lot of fiat coins like dollars, can have unlim=
ited inflation. And they still have value, even if there is no max supply. =
There is even a word for what happens in systems with hyperinflation, it is=
 called redenomination: https://en.wikipedia.org/wiki/Redenomination<br /><=
br />The same with many altcoins, which don't have any upper limit. Also no=
te, that in many altcoins, there is a trend of burning coins, to increase t=
heir value. So, the same could happen in a new testnet: claiming less coins=
 in the coinbase transaction, is a perfectly valid no-fork, that would be c=
ompatible, so even if you type in code "you can get 100 tBTC", then miners =
could still claim only 50 tBTC or 25 tBTC, and their blocks will be valid.<=
br /><br />Also, assuming no blockstorms, if you touch any rules, related t=
o halvings, then they don't have to hit us immediately. It is possible, tha=
t for the next four years, everything will be fine, but after that, there w=
ill be a lot of drama, related to what should be the correct value of the c=
oinbase transaction after that period. Note that even in the official signe=
t, we are still before the first halving.<br /><br /><div><div dir=3D"auto"=
>Tuesday, 30 April 2024 at 21:00:32 UTC+2 Matthew Bagazinski wrote:<br /></=
div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid =
rgb(204, 204, 204); padding-left: 1ex;"><div><blockquote style=3D"margin: 0=
px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: =
1ex;"><p style=3D"border: 0px solid rgb(227, 227, 227); box-sizing: border-=
box; margin: 0px 0px 1.25em; color: rgb(13, 13, 13); font-family: S=C3=B6hn=
e, ui-sans-serif, system-ui, -apple-system, &quot;Segoe UI&quot;, Roboto, U=
buntu, Cantarell, &quot;Noto Sans&quot;, sans-serif, &quot;Helvetica Neue&q=
uot;, Arial, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &qu=
ot;Segoe UI Symbol&quot;, &quot;Noto Color Emoji&quot;; font-size: 16px;">U=
nfortunately, the current form of Testnet is doomed to have value, just lik=
e BTC. Its scarcity makes it a valuable asset. And no reset will change tha=
t. It will only result in repeated resets, multiple versions of testnet, an=
d people never learning.</p></blockquote></div><div><div>I have to agree wi=
th emsit here. Never underestimate the ability for people to ascribe value =
to something with provable scarcity.=C2=A0 I like Peter Todd's suggestion o=
f removing the halving completely, so that plenty new coins are always comi=
ng into circulation, but it received pushback for removing the regular 210,=
000-block events. Here are a few dumb ideas to chew on to see if we can com=
e up with something better:</div><div><ul><li>Doubling every 210,000 blocks=
. This leads to the supply growing exponentially; impossible to try to ascr=
ibe value to that.</li><li>Adding 1 to the subsidy every 210,000 blocks. St=
ill an infinite supply, closer to a standard subsidy, but there is still a =
change happening every 210,000 blocks.</li><li>Subtracting 1 every 210,000 =
blocks. This is technically still scarce, but a much gentler decline in adm=
issions. Yes, it eventually drops to 0, but after 50 events instead of the =
current 33 halvings.</li><li>Change "half" to some other fraction like "nin=
e-tenths". Still technically scarce, gentler decline in rewards, but still =
retains the property of having a geometric sequence to the subsidies.</li><=
/ul><div>Like I said, dumb ideas, but I think there is a decision to be mad=
e between avoiding a future reset by mitigating reasons people add value to=
 tBTC (such as scarcity) and expecting/planning for more regular resets whe=
n people start inevitably valuing tBTC.</div></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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/47e4f1a0-709a-438b-a3ba-9e397c373ea9n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/47e4f1a0-709a-438b-a3ba-9e397c373ea9n%40googlegroups.com</a>.=
<br />

------=_Part_66207_1244780516.1714577441299--

------=_Part_66206_578549279.1714577441299--