summaryrefslogtreecommitdiff
path: root/09/de6ffb79dd2280e6d04c98ca5a3db88c5c2018
blob: 4b18695f2c931b1c7e2919924ffca0973a40a205 (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
Return-Path: <zhiguang53846@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 261EBC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 Jan 2023 23:22:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E1AB560B51
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 Jan 2023 23:22:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E1AB560B51
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=Xl6QV2VN
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level: 
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MONEY_PERCENT=0.01]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id r6RgV8kvdEWP
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 Jan 2023 23:22:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8F0AD60B2E
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com
 [IPv6:2607:f8b0:4864:20::730])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 8F0AD60B2E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  7 Jan 2023 23:22:15 +0000 (UTC)
Received: by mail-qk1-x730.google.com with SMTP id pa22so2469851qkn.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 07 Jan 2023 15:22:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=ilA1Grls3UH8vwhb7jluoQnPLdxdfU95uPYIFWBrZCY=;
 b=Xl6QV2VNjDrsKIRagnB094T1N2o+OSN7BXh+bR+5kk44TKekrQrdaT4CIirJN/uAZB
 MT2woa6A4vlJuBRzqN7jaIpl3cPanw1kXxZ7YN2Xf817X5oGtf+7FiyD20TLTGW+dxoQ
 5H1Hnonvaku0nkIX4/4QKe674QBXXp1I810xH+R0248SdMfi3mSbi1xGVUTTq6gdv3R4
 /dxynTC69tQoiyFr4ll+F7LdIaO1xuGU8gCpAvBzrCgxO18JP+rZqtFgyxeTSoomnOpM
 cUNbi5YfWq56jHP2Qfyws1DB6UzNh6gud/zgzouSyRKd9WChwNeESlN70sze/9Qcwjmf
 m1MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=ilA1Grls3UH8vwhb7jluoQnPLdxdfU95uPYIFWBrZCY=;
 b=dJ84p4ftDH/s5OwMfHnb2wn8RtU0UlxAEb0BYVY4zE+oCsttN/8ZkxH+14QUvje/c1
 B8zziQcwRBuQxKJkeQHZrMxbGVU9/V34NX4lA/p2l4lSr1avPR2pjj9vQqm+RXmr5Qoe
 ccuOArQQEofK/kGyKo8RGteLj4tTWBPQzsRtFU3OZ358pnQqp5gpNm1qoLy4ZUSZ4cMR
 quuFfrDHnsDd7r4bK4saJR1Kzhz+p/vXT64vgqsLWCGozUjei2d5dQJulXY6H5fGLqfY
 hh1h7MEtxvdz/lqGw5J1x4qg4Q415C02kpBKsfa1EIaueBdZEaCnyfZ/6KFGtI9bsfJR
 9O8A==
X-Gm-Message-State: AFqh2krqybpWNNWRStldAdqIkz5JMNUCtME2JLBT9zISP6v7yRcThKt0
 lBVS20f0rEMXduu+zfzhA+WDzf/Sy0FbKf0K5lWBFiq8VCBT1g==
X-Google-Smtp-Source: AMrXdXu3dJg5mE90XZlkbMEYanzYiHJpTOj93iNWeA+D3r9GwjSnojVfip3On1O4Rh2W/tgOF+xZUXDER6PRnfleHvw=
X-Received: by 2002:a05:620a:8321:b0:6ff:9724:cbee with SMTP id
 pa33-20020a05620a832100b006ff9724cbeemr4031210qkn.702.1673133734168; Sat, 07
 Jan 2023 15:22:14 -0800 (PST)
MIME-Version: 1.0
References: <174889786-7eefd505bbf223af3d3a1101c7c3044d@pmq3v.m5r2.onet>
In-Reply-To: <174889786-7eefd505bbf223af3d3a1101c7c3044d@pmq3v.m5r2.onet>
From: Eric <zhiguang53846@gmail.com>
Date: Sat, 7 Jan 2023 18:22:02 -0500
Message-ID: <CADv3YEbRX7fsG5ci6HH2RvU=PRZ=QQFkcEYY-dLQAaRsGHOi6A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e30cba05f1b4cd5d"
X-Mailman-Approved-At: Thu, 12 Jan 2023 10:00:27 +0000
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jan 2023 23:22:17 -0000

--000000000000e30cba05f1b4cd5d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

if by security you mean the security of the currency, i don't think people
have much to worry about

coinbase as far as i know is starting to behave more bank-like.  i think
there is a nostr bot that does block updates and doesn't factor in coinbase
at all

On Sat, Jan 7, 2023 at 2:13 PM Jaroslaw via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > Anyways if it turns out that fees alone don't look like they're
> supporting enough security, we have a good amount of time to come to that
> conclusion and do something about it.
>
> The worst-case scenario is that the first global hashrate regression may
> take place in 2028.
> Instead of the average price increase at least x2 every halving - the
> global hashrate may gradually decrease from that point. Again, it would b=
e
> the worst-case scenario.
>
> In my proposal you don't need to think about any calculations - just
> simple logic which we have right now. No hardcoded values and the free
> market in its finest - self-regulating the level of taxation of parties
> involved, but with opposite interests. And the mechanism would try to fix=
 a
> global hashrate regression if appear.
> In other words: let's be optimistic regarding fees, but with emergency
> mechanism built-in just in case.
> The only drawback here is that the system is already running.
>
> In my personal opinion avoiding long-term global hashrate regression is
> more important for store of value feature than the 21M schelling point (o=
r
> trap...)
>
>
>
>
> W dniu 2023-01-04 17:03:33 u=C5=BCytkownik Billy Tetrud <billy.tetrud@gma=
il.com>
> napisa=C5=82:
> > In Bitcoin "the show must go on" and someone must pay for it. Active
> [and/or] passive users
>
>
> I certainly agree.
>
>
> > or more precisely: tiny inflation
>
>
> =F0=9F=91=8D
>
>
> > Right now security comes from almost fully from ~1.8% inflation.
>
>
> Best I could find, fees make up about 13% of miner revenue. So yes, the
> vast majority of security comes from coinbase rewards. I assume you're
> implying that ~13% of today's security is not enough? I would love to see
> any quantitative thoughts you have on how one might determine that.
>
>
> Have there been any thoughts put out in the community as to what size of
> threat is unlikely enough to arise that we don't need to worry about it?
> Maybe 1% of the yearly government budgets of the world would be an upper
> bound on how much anyone would expect could realistically be brought to
> bear? Today that would be maybe around $350 billion.
>
>
> Or perhaps a better way to estimate would be calculating the size of the
> motivation of an attacker. For example, this paper seems to conclude that
> the US government was extracting a maximum of ~$20 billion/year in 1982
> dollars (so maybe $60 billion/year in 2022 dollars if you go by CPI). If =
we
> scale this up to the entire world of governments, this seems like it woul=
d
> place an upper bound of $180 billion/year of seigniorage extraction that
> would be at risk if bitcoin might put the currencies they gain seigniorag=
e
> from out of business. Over 10 years (about as far as we can expect any
> government to think), that's almost $2 trillion.
>
>
> Whereas it would currently cost probably less than $7 billion to purchase
> a 50% share of bitcoin miners. To eventually reach a level of $350 billio=
n,
> bitcoin's price would need to reach about $800,000 / bitcoin. That seems
> within the realm of possibility. To reach a level of $2 trillion, you'd
> need a price of $4.3 million/bitcoin. That's still probably within the
> realm of possibility, but certainly not as likely.  If you then assume we
> won't have significant coinbase rewards by that point, and only 13% of th=
e
> equivalent revenue (from fees) would be earned, then a price of ~$6 milli=
on
> would be needed to support a $350 billion and $34 million to support a $2
> trillion security. I think that second one is getting up towards the real=
m
> of impossibility, so if we think that much security is necessary, we migh=
t
> have to rethink things. Its also quite possible, as the network of people
> who accept and use bitcoin as payment grows, that the fee market will gro=
w
> superlinearly in comparison to market cap, which would make these kind of
> high levels of security more realistic.
>
>
> Anyways if it turns out that fees alone don't look like they're supportin=
g
> enough security, we have a good amount of time to come to that conclusion
> and do something about it.
>
>
> > Deflation in Bitcoin is not 1:1 matter like in gold, for example...
> Deflation in Bitcoin is more complex issue
>
>
> It's helpful to keep our language precise here. Price inflation and
> deflation act identically in bitcoin and gold and anything else. What you
> seem to be talking about at this point is monetary inflation (specificall=
y,
> a reduction in it) which of course operates differently on the machinery =
of
> bitcoin than it does in the machinery of gold or other things. Whereas my
> comment about you mentioning Gresham's law was specifically talking about
> price inflation, not the effects of the coin emission machinery in bitcoi=
n.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">if by security you mean the security of the currency, i do=
n&#39;t think people have much to worry about<div><br></div><div>coinbase a=
s far as i know is starting to behave more bank-like.=C2=A0 i think there i=
s a nostr bot that does block updates and doesn&#39;t factor in coinbase at=
 all</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Sat, Jan 7, 2023 at 2:13 PM Jaroslaw via bitcoin-dev &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><br>
&gt; Anyways if it turns out that fees alone don&#39;t look like they&#39;r=
e supporting enough security, we have a good amount of time to come to that=
 conclusion and do something about it.=C2=A0<br>
<br>
The worst-case scenario is that the first global hashrate regression may ta=
ke place in 2028.<br>
Instead of the average price increase at least x2 every halving - the globa=
l hashrate may gradually decrease from that point. Again, it would be the w=
orst-case scenario.<br>
<br>
In my proposal you don&#39;t need to think about any calculations - just si=
mple logic which we have right now. No hardcoded values and the free market=
 in its finest - self-regulating the level of taxation of parties involved,=
 but with opposite interests. And the mechanism would try to fix a global h=
ashrate regression if appear.<br>
In other words: let&#39;s be optimistic regarding fees, but with emergency =
mechanism built-in just in case.<br>
The only drawback here is that the system is already running.<br>
<br>
In my personal opinion avoiding long-term global hashrate regression is mor=
e important for store of value feature than the 21M schelling point (or tra=
p...)<br>
<br>
<br>
<br>
<br>
W dniu 2023-01-04 17:03:33 u=C5=BCytkownik Billy Tetrud &lt;<a href=3D"mail=
to:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>&gt;=
 napisa=C5=82:<br>
&gt; In Bitcoin &quot;the show must go on&quot; and someone must pay for it=
. Active [and/or] passive users=C2=A0<br>
<br>
<br>
I certainly=C2=A0agree.=C2=A0<br>
<br>
<br>
&gt; or more precisely: tiny inflation<br>
<br>
<br>
=F0=9F=91=8D<br>
<br>
<br>
&gt; Right now security comes from almost fully from ~1.8% inflation.<br>
<br>
<br>
Best I could find, fees make up about 13% of miner revenue. So yes, the vas=
t majority of security comes from coinbase rewards. I assume you&#39;re imp=
lying that ~13% of today&#39;s security is not enough? I would love to see =
any quantitative=C2=A0thoughts you have on how one might determine that.=C2=
=A0<br>
<br>
<br>
Have there been any thoughts put out in the community as to what size of th=
reat is unlikely enough to arise=C2=A0that we don&#39;t need to worry about=
 it? Maybe 1% of the yearly=C2=A0government budgets=C2=A0of the world=C2=A0=
would be an upper bound on how much anyone would expect could realistically=
 be brought to bear? Today that would be maybe around $350 billion.=C2=A0<b=
r>
<br>
<br>
Or perhaps a better way to estimate would be calculating the size of the mo=
tivation of an attacker. For example, this paper=C2=A0seems to conclude tha=
t the US government was extracting a maximum of ~$20 billion/year in 1982 d=
ollars (so maybe $60 billion/year in 2022 dollars if you go by CPI). If we =
scale this up to the entire world of governments, this seems like it would =
place an upper bound of $180 billion/year of seigniorage extraction that wo=
uld be at risk if bitcoin might put the currencies they gain seigniorage fr=
om out of business. Over 10 years (about as far as we can expect any govern=
ment to think), that&#39;s almost $2 trillion.=C2=A0<br>
<br>
<br>
Whereas it would currently cost probably less than $7 billion=C2=A0to purch=
ase a 50% share of bitcoin miners. To eventually reach a level of $350 bill=
ion, bitcoin&#39;s price would need to reach about $800,000 / bitcoin. That=
 seems within the realm of possibility. To reach a level of $2 trillion, yo=
u&#39;d need a price of $4.3 million/bitcoin. That&#39;s still probably wit=
hin the realm of possibility, but certainly not as likely.=C2=A0 If you the=
n assume we won&#39;t have significant coinbase rewards by that point, and =
only 13% of the equivalent revenue (from fees) would be earned, then a pric=
e of ~$6 million would be needed to support a $350 billion and $34 million =
to support a $2 trillion security. I think that second one is getting up to=
wards the realm of impossibility, so if we think that much security is nece=
ssary, we might have to rethink things. Its also quite possible, as the net=
work of people who accept and use bitcoin as payment grows, that the fee ma=
rket will grow superlinearly in comparison to market cap, which would make =
these kind of high levels of security more realistic.=C2=A0<br>
<br>
<br>
Anyways if it turns out that fees alone don&#39;t look like they&#39;re sup=
porting enough security, we have a good amount of time to come to that conc=
lusion and do something about it.=C2=A0<br>
<br>
<br>
&gt; Deflation in Bitcoin is not 1:1 matter like in gold, for example...=C2=
=A0 Deflation in Bitcoin is more complex issue<br>
<br>
<br>
It&#39;s helpful to keep our language precise here. Price inflation and def=
lation act identically in bitcoin and gold and anything else. What you seem=
 to be talking about at this point is monetary inflation (specifically, a r=
eduction in it) which of course operates differently on the machinery of bi=
tcoin than it does in the machinery of gold or other things. Whereas my com=
ment about you mentioning Gresham&#39;s law was specifically talking about =
price inflation, not the effects of the coin emission machinery in bitcoin.=
=C2=A0<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000e30cba05f1b4cd5d--