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
|
Return-Path: <eric@voskuil.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 23466C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jul 2022 19:58:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id DDD9E418D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jul 2022 19:58:02 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DDD9E418D9
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com
header.i=@voskuil-org.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=AG2mh1oS
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id p0Lf3F3wmdSg
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jul 2022 19:58:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C388F418CC
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com
[IPv6:2607:f8b0:4864:20::534])
by smtp4.osuosl.org (Postfix) with ESMTPS id C388F418CC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jul 2022 19:58:00 +0000 (UTC)
Received: by mail-pg1-x534.google.com with SMTP id bh13so14457495pgb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Jul 2022 12:58:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20210112.gappssmtp.com; s=20210112;
h=content-transfer-encoding:from:mime-version:subject:date:message-id
:references:cc:in-reply-to:to;
bh=gX+fFUswloSEnq4rxfK4F4JCUj31JYAZEhs0yMeXFh4=;
b=AG2mh1oSVT28kp4gElm2iO6LGuxRr908woLDMPL7f6l2K4F6uORZ7Q2Mp+Wt02Wi6E
W180uAk+UqFHBSFXqrzOHfS7bgRMdGNiswyOMAI8PTSBi1AI2NWwdF7IjgEHXx6ThwJk
KIFG/h4FCns/+rHqcjIbl4ZXIuh4numem/buWppF3TqOPHLT10DAag1Chmib8VK6muVH
jbcHlj6EeGno0UitDywzcdVcaJHPCkNXB2G2nkAuQAEXAondIrc1dyKjcVinHsHivN64
PjBXEsrx7F8JPDSqSQMe7WZg+OZs8OaDZI+2Pr3fZJDY0MNLlDLtdDaQUKBGnnb/fofn
HDtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:content-transfer-encoding:from:mime-version
:subject:date:message-id:references:cc:in-reply-to:to;
bh=gX+fFUswloSEnq4rxfK4F4JCUj31JYAZEhs0yMeXFh4=;
b=0MW6CKUWR/6k28N3CMwInRN8goQT4YjK0wm31s4MVa0Y5h6MkafAwqsikN3NiON0EO
NCvYbPySWKLgAVphubowHS+NSExMvm5eZV+a3urze8fkrZ8lbpg1Tq6rIJMeG3jigmzs
zPS9OJA746DY6uTo2Q8Mp9D8pU576u/qjo8zbZhcGDEXEOrf5N3C6tUr5gqfDfCxY4Vm
pGo7i1jUgUWwuDrRdwexlduiZz/hDD9Mmrxg/IcPJhTiiv1GmpJhLRjS4lbc6I5GyHZz
V60BNu0OdUvdy5A6J27k+xsRL7ASx6AdNvxLbGXKWH3TNrDKROX1M729nDuIjLQrFVFY
5Eyg==
X-Gm-Message-State: AJIora/7A4bnbi952p3xOVyQ3qgk5ewdSZaCgpyoLusQ//ZBSQPOXIHe
95e1v1QkwyUxOzdTm4OZsk6CupGUst8VXQ==
X-Google-Smtp-Source: AGRyM1vcSNCzNEG5zznIxBnhwsJwUp3xtS+kUJa6Fs9ZlNhAtgZ5g/3TUae+8G/N5PvDxOgvpYg+0Q==
X-Received: by 2002:a17:902:d708:b0:16b:d655:e15a with SMTP id
w8-20020a170902d70800b0016bd655e15amr29597237ply.34.1657223879631;
Thu, 07 Jul 2022 12:57:59 -0700 (PDT)
Received: from smtpclient.apple ([2600:380:801f:6202:f47e:c7ca:fad6:7d1])
by smtp.gmail.com with ESMTPSA id
l3-20020a17090a408300b001eab99a42efsm19781328pjg.31.2022.07.07.12.57.57
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 07 Jul 2022 12:57:58 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 7 Jul 2022 12:57:56 -0700
Message-Id: <8438F081-D085-4491-8C1C-4D83FFC7DE84@voskuil.org>
References: <CAJowKg+OP92w+zHjy4T79tMDL5O0gboUEurhBAuWbp+npsv94A@mail.gmail.com>
In-Reply-To: <CAJowKg+OP92w+zHjy4T79tMDL5O0gboUEurhBAuWbp+npsv94A@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
X-Mailer: iPhone Mail (19F77)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
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: Thu, 07 Jul 2022 19:58:03 -0000
--Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
It=E2=80=99s not clear how reducing block size changes the fee aspect of the=
block reward. Assuming half the space implies twice the fee per avg tx the r=
eward remains constant.
Any additional cost of processing more or less bytes would not matter, becau=
se of course this is just a cost that gets nulled out by difficulty =E2=80=94=
average profit (net income) is the cost of capital.
The reason for smaller vs. larger blocks is to ensure that individuals can a=
fford to validate. That=E2=80=99s a threshold criteria.
Given unlimited size blocks, miners would still have to fix a point in time t=
o mine, gathering as much fee as they can optimize in some time period presu=
mably less than 10 minutes. The produces a limit to transaction volume, yet n=
either reward nor profit would be affected given the above assumptions. The d=
ifference would be in a tradeoff of per tx fee against the threshold.
Given Moore=E2=80=99s Law, that threshold is constantly decreasing, which wi=
ll make it cheaper over time for more individuals to validate. But the diff=
erence for miners for smaller blocks is largely inconsequential relative to t=
heir other costs.
Increasing demand is the only thing that increases double spend security (an=
d censorship resistance assuming fee-based reward). With rising demand there=
is rising overall hash rate, despite block reward and profit remaining cons=
tant. This makes the cost of attempting to orphan a block higher, therefore l=
owering the depth/time requirement implied to secure a given tx amount.
These are the two factors, demand and time. Less demand implies more time to=
secure a given amount against double spend, and also implies a lower cost t=
o subsidize a censorship regime. But the latter requires a differential in r=
eward between the censor and non-censoring miners. While this could be paid i=
n side fees, that is a significant anonymity issue.
e
> On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32.com> wrote:
>=20
> =EF=BB=BF
> > > We should not imbue real technology with magical qualities.
>=20
> > Precisely. It is economic forces (people), not technology, that provide s=
ecurity.
>=20
> Yes, and these forces don't prevent double-spend / 51% attacks if the amou=
nts involved are greater than the incentives.
>=20
> In addition to "utility", lowering the block size could help prevent this i=
ssue as well... increasing fee pressure and double-spend security while redu=
cing the burden on node operators.
>=20
> Changes to inflation are, very likely, off the table.
>=20
> =20
>=20
>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org> wrote:
>>=20
>>=20
>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>> >=20
>> > =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bi=
tcoin-dev wrote:
>> >> Billy,
>> >>=20
>> >> Proof of work and the difficulty adjustment function solve literally
>> >> everything you are talking about already.
>> >=20
>> > Unfortunately you are quite wrong: the difficulty adjustment function m=
erely
>> > adjusts for changes in the amount of observable, non-51%-attacking, has=
hing
>> > power. In the event of a chain split, the difficulty adjustment functio=
n does
>> > nothing; against a 51% attacker, the difficulty adjustment does nothing=
;
>> > against a censor, the difficulty adjustment does nothing.
>>=20
>> Consider falling hash rate due to a perpetual 51% attack. Difficulty fall=
s, possibly to min difficulty if all non-censors stop mining and with all ce=
nsors collaborating (one miner). Yet as difficulty falls, so does the cost o=
f countering the censor. At min difficulty everyone can CPU mine again.
>>=20
>> Given the presumption that fees rise on unconfirmed transactions, there i=
s inherent economic incentive to countering at any level of difficulty. Cons=
equently the censor is compelled to subsidize the loss resulting from forgoi=
ng higher fee transactions that are incentivizing its competition.
>>=20
>> With falling difficulty this incentive is compounded.
>>=20
>> Comparisons of security in different scenarios presume a consistent level=
of demand. If that demand is insufficient to offset the censor=E2=80=99s su=
bsidy, there is no security in any scenario.
>>=20
>> Given that the block subsidy (inflation) is paid equally to censoring and=
non-censoring miners, it offers no security against censorship whatsoever. T=
rading fee-based block reward for inflation-based is simply trading censorsh=
ip resistance for the presumption of double-spend security. But of course, a=
censor can double spend profitably in any scenario where the double spend v=
alue (to the censor) exceeds that of blocks orphaned (as the censor earns 10=
0% of all block rewards).
>>=20
>> Banks and state monies offer reasonable double spend security. Not sure t=
hat=E2=80=99s a trade worth making.
>>=20
>> It=E2=80=99s not clear to me that Satoshi understood this relation. I=E2=80=
=99ve seen no indication of it. However the decision to phase out subsidy, o=
nce a sufficient number of units (to assure divisibility) had been issued, i=
s what transitions Bitcoin from a censorable to a censorship resistant money=
. If one does not believe there is sufficient demand for such a money, there=
is no way to reconcile that belief with a model of censorship resistance.
>>=20
>> > We should not imbue real technology with magical qualities.
>>=20
>> Precisely. It is economic forces (people), not technology, that provide s=
ecurity.
>>=20
>> e
>>=20
>> >> Bitcoin does not need active economic governanance by devs or meddlers=
.
>> >=20
>> > Yes, active governance would definitely be an exploitable mechanism. On=
the
>> > other hand, the status quo of the block reward eventually going away en=
tirely
>> > is obviously a risky state change too.
>> >=20
>> >>>> There is also zero agreement on how much security would constitute s=
uch
>> >>> an optimum.
>> >>>=20
>> >>> This is really step 1. We need to generate consensus on this long bef=
ore
>> >>> the block subsidy becomes too small. Probably in the next 10-15 years=
. I
>> >>> wrote a paper
>> >=20
>> > The fact of the matter is that the present amount of security is about 1=
.7% of
>> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7% i=
s also
>> > already an amount low enough that it's much smaller than economic volat=
ility.
>> >=20
>> > Obviously 0% is too small.
>> >=20
>> > There's zero reason to stress about finding an "optimal" amount. An amo=
unt low
>> > enough to be easily affordable, but non-zero, is fine. 1% would be fine=
; 0.5%
>> > would probably be fine; 0.1% would probably be fine.
>> >=20
>> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31=
% tax on
>> > savings; 0.1% works out to be 7.2%
>> >=20
>> > These are all amounts that are likely to be dwarfed by economic shifts.=
>> >=20
>> > --=20
>> > https://petertodd.org 'peter'[:-1]@petertodd.org
>> > _______________________________________________
>> > 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
--Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">It=E2=
=80=99s not clear how reducing block size changes the fee aspect of the bloc=
k reward. Assuming <span style=3D"caret-color: rgb(0, 0, 0); color: rgb=
(0, 0, 0);">half the space implies twice the fee per avg tx the reward remai=
ns constant.</span></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Any add=
itional cost of processing more or less bytes would not matter, because of c=
ourse this is just a cost that gets nulled out by difficulty =E2=80=94 avera=
ge profit (net income) is the cost of capital.</div><div dir=3D"ltr"><br></d=
iv><div dir=3D"ltr">The reason for smaller vs. larger blocks is to ensure th=
at individuals can afford to validate. That=E2=80=99s a threshold criteria.<=
/div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Given unlimited size blocks=
, miners would still have to fix a point in time to mine, gathering as much f=
ee as they can optimize in some time period presumably less than 10 minutes.=
The produces a limit to transaction volume, yet neither reward nor profit w=
ould be affected given the above assumptions. The difference would be in a t=
radeoff of per tx fee against the threshold.</div><div dir=3D"ltr"><br></div=
><div dir=3D"ltr">Given Moore=E2=80=99s Law, that threshold is constantly de=
creasing, which will make it cheaper over time for more individuals to=
validate. But the difference for miners for smaller blocks is largely incon=
sequential relative to their other costs.</div><div dir=3D"ltr"><br></div><d=
iv dir=3D"ltr">Increasing demand is the only thing that increases double spe=
nd security (and censorship resistance assuming fee-based reward). With risi=
ng demand there is rising overall hash rate, despite block reward and profit=
remaining constant. This makes the cost of attempting to orphan a block hig=
her, therefore lowering the depth/time requirement implied to secure a given=
tx amount.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">These are the t=
wo factors, demand and time. Less demand implies more time to secure a given=
amount against double spend, and also implies a lower cost to subsidize a c=
ensorship regime. But the latter requires a differential in reward between t=
he censor and non-censoring miners. While this could be paid in side fees, t=
hat is a significant anonymity issue.</div><div dir=3D"ltr"><br></div><div d=
ir=3D"ltr">e</div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Jul 7, 2=
022, at 10:37, Erik Aronesty <erik@q32.com> wrote:<br><br></blockquote=
></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr">=
<div><span style=3D"color:rgb(80,0,80)">> > We should not imbue real t=
echnology with magical qualities.</span><br></div><div><span class=3D"gmail-=
im" style=3D"color:rgb(80,0,80)"><br></span>> Precisely. It is economic f=
orces (people), not technology, that provide security.<font color=3D"#888888=
"><br></font></div><div><br></div><div>Yes, and these forces don't prevent d=
ouble-spend / 51% attacks if the amounts involved are greater than the incen=
tives.</div><div><br></div><div>In addition to "utility", lowering the block=
size could help prevent this issue as well... increasing fee pressure and d=
ouble-spend security while reducing the burden on node operators.</div><div>=
<br></div><div>Changes to inflation are, very likely, off the table.</div><d=
iv><br></div><div> </div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via b=
itcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><br>
<br>
> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>> wrote:<br>
> <br>
> =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bi=
tcoin-dev wrote:<br>
>> Billy,<br>
>> <br>
>> Proof of work and the difficulty adjustment function solve literall=
y<br>
>> everything you are talking about already.<br>
> <br>
> Unfortunately you are quite wrong: the difficulty adjustment function m=
erely<br>
> adjusts for changes in the amount of observable, non-51%-attacking, has=
hing<br>
> power. In the event of a chain split, the difficulty adjustment functio=
n does<br>
> nothing; against a 51% attacker, the difficulty adjustment does nothing=
;<br>
> against a censor, the difficulty adjustment does nothing.<br>
<br>
Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, p=
ossibly to min difficulty if all non-censors stop mining and with all censor=
s collaborating (one miner). Yet as difficulty falls, so does the cost of co=
untering the censor. At min difficulty everyone can CPU mine again.<br>
<br>
Given the presumption that fees rise on unconfirmed transactions, there is i=
nherent economic incentive to countering at any level of difficulty. Consequ=
ently the censor is compelled to subsidize the loss resulting from forgoing h=
igher fee transactions that are incentivizing its competition.<br>
<br>
With falling difficulty this incentive is compounded.<br>
<br>
Comparisons of security in different scenarios presume a consistent level of=
demand. If that demand is insufficient to offset the censor=E2=80=99s subsi=
dy, there is no security in any scenario.<br>
<br>
Given that the block subsidy (inflation) is paid equally to censoring and no=
n-censoring miners, it offers no security against censorship whatsoever. Tra=
ding fee-based block reward for inflation-based is simply trading censorship=
resistance for the presumption of double-spend security. But of course, a c=
ensor can double spend profitably in any scenario where the double spend val=
ue (to the censor) exceeds that of blocks orphaned (as the censor earns 100%=
of all block rewards).<br>
<br>
Banks and state monies offer reasonable double spend security. Not sure that=
=E2=80=99s a trade worth making.<br>
<br>
It=E2=80=99s not clear to me that Satoshi understood this relation. I=E2=80=99=
ve seen no indication of it. However the decision to phase out subsidy, once=
a sufficient number of units (to assure divisibility) had been issued, is w=
hat transitions Bitcoin from a censorable to a censorship resistant money. I=
f one does not believe there is sufficient demand for such a money, there is=
no way to reconcile that belief with a model of censorship resistance.<br>
<br>
> We should not imbue real technology with magical qualities.<br>
<br>
Precisely. It is economic forces (people), not technology, that provide secu=
rity.<br>
<br>
e<br>
<br>
>> Bitcoin does not need active economic governanance by devs or meddl=
ers.<br>
> <br>
> Yes, active governance would definitely be an exploitable mechanism. On=
the<br>
> other hand, the status quo of the block reward eventually going away en=
tirely<br>
> is obviously a risky state change too.<br>
> <br>
>>>> There is also zero agreement on how much security would con=
stitute such<br>
>>> an optimum.<br>
>>> <br>
>>> This is really step 1. We need to generate consensus on this lo=
ng before<br>
>>> the block subsidy becomes too small. Probably in the next 10-15=
years. I<br>
>>> wrote a paper<br>
> <br>
> The fact of the matter is that the present amount of security is about 1=
.7% of<br>
> the total coin supply/year, and Bitcoin seems to be working fine. 1.7% i=
s also<br>
> already an amount low enough that it's much smaller than economic volat=
ility.<br>
> <br>
> Obviously 0% is too small.<br>
> <br>
> There's zero reason to stress about finding an "optimal" amount. An amo=
unt low<br>
> enough to be easily affordable, but non-zero, is fine. 1% would be fine=
; 0.5%<br>
> would probably be fine; 0.1% would probably be fine.<br>
> <br>
> Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31=
% tax on<br>
> savings; 0.1% works out to be 7.2%<br>
> <br>
> These are all amounts that are likely to be dwarfed by economic shifts.=
<br>
> <br>
> -- <br>
> <a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">=
https://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D=
"noreferrer" target=3D"_blank">petertodd.org</a><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/m=
ailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></blockquote></body></html>=
--Apple-Mail-635FE9B0-6D7D-4035-98CB-4EB148897C34--
|