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
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
|
Return-Path: <john@synonym.to>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 11D2DC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jul 2022 13:24:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id E779F60C30
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jul 2022 13:24:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E779F60C30
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com
header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=ZlQk60EF
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_NONE=0.001] 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 CW0lWTXTsE-A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jul 2022 13:24:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E78F560A70
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com
[IPv6:2607:f8b0:4864:20::42e])
by smtp3.osuosl.org (Postfix) with ESMTPS id E78F560A70
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jul 2022 13:24:51 +0000 (UTC)
Received: by mail-pf1-x42e.google.com with SMTP id e16so6581846pfm.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 07 Jul 2022 06:24:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=synonym-to.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=uh3d5jXDLw5A5GNp4MiWm02laFBX6h3aR2NRFzpYJ/4=;
b=ZlQk60EFYXL9VWCkvmKCMrG+k+TGxX4E0MoY2OOTfdRptrVLZPtwucrWucjooMDp0H
1ApXqyGn1Yp5XEnX9PwwsgUr4FAYaoS3FIr+1S/dO6eLNc82FuR5GISfkd+W2ozY0c91
qqbY70eY2NrHsT90VWIvg/e8RmnY/SxXr+4/5zgz9QhoT+oUo6fTrwnwRNkLiCyKDbQG
wqJVQ980j9PZ9JylLAhhSsi9lgrAy6UmANoyBoG5INlms5rubqgm//Pd+TcuDhLP73Xs
C9xQpzjMM06UW+UeZEQIQh/WGVQm+cFYYbN8BOY0WLBn9qfA6LuKJczTT2riv/mbrDEe
gE/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=uh3d5jXDLw5A5GNp4MiWm02laFBX6h3aR2NRFzpYJ/4=;
b=6GImAih0m1q9I8OZ5fYhcd95arRJlmN7R+r27uoXwxjah9C0ofbZtt5j8A3d6i/i7t
qFKv/DspMPaJIxeqJTy1ieNthlclCQZltLbh3SBSYYMMYv2hJh44xFVtlQJNN/l61/LW
jxrNWfuSb2l4H00iyX0yvfKkkXaVhBXCL9WjxtxaFoPNnSKt6TIXaL2Ht7YpXmrQtp6q
MYFv4PiNYItKwjxKiO9M8aEu+RzPsm1TYAYnYSmgwlD8GI1MFyCDZZb+srONys6OR8QL
O5Vn1MyeTDWNOo5XHE05Fr5axTu2oudb25K7NTRwe/+ixB/jPXzYvwS+qOXi858U5LwN
9rqA==
X-Gm-Message-State: AJIora+SP49H7GLSR0inw8/wRQDqDXkf1TNyptly1YGD8lEKftURzLRc
EUrLpIrMLwoYxtxb4Q7fqkHC3MpedL/L6HaS1kxg2gZwmzQ3ZNrX
X-Google-Smtp-Source: AGRyM1u07y1YsEsKPwRFZ/UbLMmFJgPBrjzED176pTUlP8h3Lxtq926hOlZKpgAgaPfL4voPHH6ORvEZnPpXa6FWxo0=
X-Received: by 2002:a17:90b:3ec5:b0:1ef:688:8568 with SMTP id
rm5-20020a17090b3ec500b001ef06888568mr5287544pjb.38.1657200290405; Thu, 07
Jul 2022 06:24:50 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>
From: John Carvalho <john@synonym.to>
Date: Thu, 7 Jul 2022 14:24:39 +0100
Message-ID: <CAHTn92wR+D=2FLAc7vhhm4kNT6NwDfyKdRj32=E9H3UJ4QcE+Q@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000a1b84b05e33702f5"
X-Mailman-Approved-At: Thu, 07 Jul 2022 13:55:43 +0000
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 13:24:54 -0000
--000000000000a1b84b05e33702f5
Content-Type: text/plain; charset="UTF-8"
Billy,
Proof of work and the difficulty adjustment function solve literally
everything you are talking about already.
Bitcoin does not need active economic governanance by devs or meddlers.
Please stop spamming this list with this nonsensical thread.
Love,
John
On Thu, Jul 7, 2022 at 1:00 PM <
bitcoin-dev-request@lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Bitcoin covenants are inevitable (Billy Tetrud)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 6 Jul 2022 17:46:15 -0700
> From: Billy Tetrud <billy.tetrud@gmail.com>
> To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
> Message-ID:
> <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeCG2=
> 3GgLQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> @Corey
>
> > Currently there is zero feedback in the Bitcoin system between what we
> might think is the optimum amount of security and what actually exists.
>
> I basically agree with this. The pedantic part of my mind does want to
> point out that the link between block subsidy and bitcoin's price does
> actually give somewhat of a feedback loop, in that the higher the price,
> the more valuable bitcoin is as a whole (at least as viewed by the active
> market), and therefore the more investment in security is appropriate.
> However, in the long run when the subsidy reduces to insignificance, we
> basically lose this link. And even with this link, it's not very direct.
> Fees retain only a little bit of this behavior, because presumably a more
> valuable bitcoin is more valuable to spend, but the link to security is
> very tenuous there.
>
> > There is also zero agreement on how much security would constitute such
> an optimum.
>
> This is really step 1. We need to generate consensus on this long before
> the block subsidy becomes too small. Probably in the next 10-15 years. I
> wrote a paper
> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity>
> that uses a framework for thinking about how much security bitcoin might
> need. The concept is that we should figure out what bitcoin's bottlenecks
> are, and figure out the minimum requirements we want to place on running a
> node based on how many (public) nodes we think we need and what percentage
> of machines out there are likely to run a node. The goals I chose to
> explore in that paper are totally up for debate, and I think its an
> important debate to have. But they are basically a first stab at setting up
> what we would need to determine optimum security. I would very much
> appreciate your review of that part of the paper, Corey.
>
> > Figuring out how much security is needed, or even better, figuring out a
> way to have a market mechanism to answer that question, will be an
> important project.
>
> My thoughts on this are that we will need to periodically make some
> software change to adjust a *target amount of investment in security*,
> because the components of bitcoin's blockchain security are not all
> predictable. Many unpredictable things factor into bitcoin's security (eg
> miner behavior, pools, how many people generally run public nodes on their
> own, what features require running public nodes, value of bitcoin, etc.
>
> The primary mechanism we have to change how much security we have is to
> change the block size, which changes how much fees miners can collect each
> block. This isn't a linear thing. Its probably a parabola with a peak,
> where at that peak, making the block either smaller and larger would both
> reduce total fees paid. This is because when blocksize is higher, more
> transactions (and thus more fees) can be collected, but at the same time
> average fees will be lower. The pull of those two forces should define that
> parabola.
>
> So my suggestion here would be that we should target a certain amount of
> security and have programmatic adjustments to the block size in order to
> stay near enough to the parabolic maximum so that we pay miners enough to
> give us sufficient blockchain security. Conversely, it should also attempt
> to minimize how much "extra" security we pay for. It would be wasteful to
> pay 3 times as much for 3 times the security we actually need. Such a thing
> is a very real form of devaluation that basically represents a tax on
> bitcoin and users of bitcoin. And its very possible for the position of
> this parabola to change over time. We could never say with certainty
> whether we're on one side of the parabola's maximum or the other. This
> would make it rather complex to track well.
>
> Additionally, there's no clear trustless way to determine the market value
> of bitcoin at any given time, which makes it difficult to maintain this
> target over time. As the market value of bitcoin changes, that target could
> become quite inaccurate. This implies that we would need to do periodic
> adjustments to the target, either through periodic forks or through some
> other mechanism for changing the target.
>
> If there were a good trustless way to determine the market value of
> bitcoin, we would have to "manually" change this target potentially much
> less often. Transaction fees kind of have an association with market value.
> Perhaps some kind of analysis can be done on that to make a reasonable
> prediction of what market value is based on fees. Or maybe blocks can
> commit to a market price similarly to how they commit to a timestamp (which
> is also only verifiable to an approximation and can only be verified close
> to when it was mined but not eg years later).
>
>
>
>
> On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > > If the only realistic (fair, efficient & proportionate) way to pay for
> > Bitcoin's security was by having some inflation scheme that violated the
> 21
> > million cap, then agreeing to break the limit would probably be what
> makes
> > sense, and in the economic interest of its users and holders.
> >
> > So, Paul Sztorc was right again, there are three options: Enormous Block
> > Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come
> > From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png.
> > And I think using Merged Mining is the best option. More about that:
> > https://www.truthcoin.info/blog/security-budget-ii-mm/
> >
> > > Another option, if we were to decide we are over-secured in the short
> > term, would be to soft-fork in a reduction in the current and near-future
> > mining rewards, by somehow locking the coins in a contract that deprived
> > the miner of the full reward, and then using that contract to pay the
> > rewards out far in the future, should at some point we feel the security
> > budget was insufficient.
> >
> > Yes, that's also possible, RSK uses that. And making some kind of
> > soft-fork for that is also possible, but I don't know if miners will
> agree
> > to send some coinbase reward to "<futureBlockNumber>
> OP_CHECKLOCKTIMEVERIFY
> > OP_DROP OP_TRUE".
> >
> > On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > >Bitcoin's finite supply is the main argument for people investing in it,
> > the whole narrative around bitcoin is based on its finite supply. While
> it
> > has its flaws and basically condemns bitcoin to be only used as a store
> >of
> > value (and not as a currency), I don't think it's worth questioning it at
> > this point.
> > >
> > >Just my 2 sats.
> > >
> > >Giuseppe.
> >
> >
> > A finite supply alone is not enough to give something value, as it must
> > also be useful in some way. In the case of Bitcoin, various forms of
> > cryptographic security must all work - and work together - to make
> Bitcoin
> > useful. If the only realistic (fair, efficient & proportionate) way to
> pay
> > for Bitcoin's security was by having some inflation scheme that violated
> > the 21 million cap, then agreeing to break the limit would probably be
> what
> > makes sense, and in the economic interest of its users and holders.
> >
> > There will always be competitive pressures with respect to efficiency,
> and
> > both being over-secured and under-secured would be economically
> inefficient
> > for a crypto currency, and thereby laving room for a more
> optimally-secured
> > competitor to gain ground. Currently there is zero feedback in the
> Bitcoin
> > system between what we might think is the optimum amount of security and
> > what actually exists. There is also zero agreement on how much security
> > would constitute such an optimum. Figuring out how much security is
> needed,
> > or even better, figuring out a way to have a market mechanism to answer
> > that question, will be an important project.
> >
> > Another option, if we were to decide we are over-secured in the short
> > term, would be to soft-fork in a reduction in the current and near-future
> > mining rewards, by somehow locking the coins in a contract that deprived
> > the miner of the full reward, and then using that contract to pay the
> > rewards out far in the future, should at some point we feel the security
> > budget was insufficient. Anthony Towns presented a form of this concept
> in
> > greater detail at a Scaling Bitcoin conference some years ago. While this
> > solution, if employed, would only work for some finite amount of time, it
> > is possible that could give additional decades before the accumulated
> > security budget was exhausted.
> >
> >
> > Corey
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220706/d5a48a69/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 86, Issue 7
> ******************************************
>
--
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
Schedule: https://calendly.com/bitcoinerrorlog
Chat: https://t.me/bitcoinerrorlog
Social: https://twitter.com/bitcoinerrorlog
--000000000000a1b84b05e33702f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Billy,</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Proof of work and the difficulty adjustment function solve literally every=
thing you are talking about already.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Bitcoin does not need active economic governanance by devs or =
meddlers.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Please stop sp=
amming this list with this nonsensical thread.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Love,=C2=A0</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">John</div><div dir=3D"auto"><br></div><div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 7, 2022 at 1:00=
PM <<a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org">bi=
tcoin-dev-request@lists.linuxfoundation.org</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,=
204,204)">Send bitcoin-dev mailing list submissions to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundati=
on.org</a><br>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev-owner@lists.linuxfoundation.o=
rg</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of bitcoin-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
=C2=A0 =C2=A01. Re: Bitcoin covenants are inevitable (Billy Tetrud)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 6 Jul 2022 17:46:15 -0700<br>
From: Billy Tetrud <<a href=3D"mailto:billy.tetrud@gmail.com" target=3D"=
_blank">billy.tetrud@gmail.com</a>><br>
To: <a href=3D"mailto:vjudeu@gazeta.pl" target=3D"_blank">vjudeu@gazeta.pl<=
/a>,=C2=A0 Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeC=
G2=3D<a href=3D"mailto:3GgLQ@mail.gmail.com" target=3D"_blank">3GgLQ@mail.g=
mail.com</a>><br>
Content-Type: text/plain; charset=3D"utf-8"<br>
<br>
@Corey<br>
<br>
>=C2=A0 Currently there is zero feedback in the Bitcoin system between w=
hat we<br>
might think is the optimum amount of security and what actually exists.<br>
<br>
I basically agree with this. The pedantic part of my mind does want to<br>
point out that the link between block subsidy and bitcoin's price does<=
br>
actually give somewhat of a feedback loop, in that the higher the price,<br=
>
the more valuable bitcoin is as a whole (at least as viewed by the active<b=
r>
market), and therefore the more investment in security is appropriate.<br>
However, in the long run when the subsidy reduces to insignificance, we<br>
basically lose this link. And even with this link, it's not very direct=
.<br>
Fees retain only a little bit of this behavior, because presumably a more<b=
r>
valuable bitcoin is more valuable to spend, but the link to security is<br>
very tenuous there.<br>
<br>
> There is also zero agreement on how much security would constitute suc=
h<br>
an optimum.<br>
<br>
This is really step 1. We need to generate consensus on this long before<br=
>
the block subsidy becomes too small. Probably in the next 10-15 years. I<br=
>
wrote a paper<br>
<<a href=3D"https://github.com/fresheneesz/quantificationOfConsensusProt=
ocolSecurity" rel=3D"noreferrer" target=3D"_blank">https://github.com/fresh=
eneesz/quantificationOfConsensusProtocolSecurity</a>><br>
that uses a framework for thinking about how much security bitcoin might<br=
>
need. The concept is that we should figure out what bitcoin's bottlenec=
ks<br>
are, and figure out the minimum requirements we want to place on running a<=
br>
node based on how many (public) nodes we think we need and what percentage<=
br>
of machines out there are likely to run a node. The goals I chose to<br>
explore in that paper are totally up for debate, and I think its an<br>
important debate to have. But they are basically a first stab at setting up=
<br>
what we would need to determine optimum security. I would very much<br>
appreciate your review of that part of the paper, Corey.<br>
<br>
> Figuring out how much security is needed, or even better, figuring out=
a<br>
way to have a market mechanism to answer that question, will be an<br>
important project.<br>
<br>
My thoughts on this are that we will need to periodically make some<br>
software change to adjust a *target amount of investment in security*,<br>
because the components of bitcoin's blockchain security are not all<br>
predictable. Many unpredictable things factor into bitcoin's security (=
eg<br>
miner behavior, pools, how many people generally run public nodes on their<=
br>
own, what features require running public nodes, value of bitcoin, etc.<br>
<br>
The primary mechanism we have to change how much security we have is to<br>
change the block size, which changes how much fees miners can collect each<=
br>
block. This isn't a linear thing. Its probably a parabola with a peak,<=
br>
where at that peak, making the block either smaller and larger would both<b=
r>
reduce total fees paid. This is because when blocksize is higher, more<br>
transactions (and thus more fees) can be collected, but at the same time<br=
>
average fees will be lower. The pull of those two forces should define that=
<br>
parabola.<br>
<br>
So my suggestion here would be that we should target a certain amount of<br=
>
security and have programmatic adjustments to the block size in order to<br=
>
stay near enough to the parabolic maximum so that we pay miners enough to<b=
r>
give us sufficient blockchain security. Conversely, it should also attempt<=
br>
to minimize how much "extra" security we pay for. It would be was=
teful to<br>
pay 3 times as much for 3 times the security we actually need. Such a thing=
<br>
is a very real form of devaluation that basically represents a tax on<br>
bitcoin and users of bitcoin. And its very possible for the position of<br>
this parabola to change over time. We could never say with certainty<br>
whether we're on one side of the parabola's maximum or the other. T=
his<br>
would make it rather complex to track well.<br>
<br>
Additionally, there's no clear trustless way to determine the market va=
lue<br>
of bitcoin at any given time, which makes it difficult to maintain this<br>
target over time. As the market value of bitcoin changes, that target could=
<br>
become quite inaccurate. This implies that we would need to do periodic<br>
adjustments to the target, either through periodic forks or through some<br=
>
other mechanism for changing the target.<br>
<br>
If there were a good trustless way to determine the market value of<br>
bitcoin, we would have to "manually" change this target potential=
ly much<br>
less often. Transaction fees kind of have an association with market value.=
<br>
Perhaps some kind of analysis can be done on that to make a reasonable<br>
prediction of what market value is based on fees. Or maybe blocks can<br>
commit to a market price similarly to how they commit to a timestamp (which=
<br>
is also only verifiable to an approximation and can only be verified close<=
br>
to when it was mined but not eg years later).<br>
<br>
<br>
<br>
<br>
On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev <<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
<br>
> > If the only realistic (fair, efficient & proportionate) way t=
o pay for<br>
> Bitcoin's security was by having some inflation scheme that violat=
ed the 21<br>
> million cap, then agreeing to break the limit would probably be what m=
akes<br>
> sense, and in the economic interest of its users and holders.<br>
><br>
> So, Paul Sztorc was right again, there are three options: Enormous Blo=
ck<br>
> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues =
Come<br>
> From Merged Mining: <a href=3D"https://www.truthcoin.info/images/sb-tr=
ilemma.png" rel=3D"noreferrer" target=3D"_blank">https://www.truthcoin.info=
/images/sb-trilemma.png</a>.<br>
> And I think using Merged Mining is the best option. More about that:<b=
r>
> <a href=3D"https://www.truthcoin.info/blog/security-budget-ii-mm/" rel=
=3D"noreferrer" target=3D"_blank">https://www.truthcoin.info/blog/security-=
budget-ii-mm/</a><br>
><br>
> > Another option, if we were to decide we are over-secured in the s=
hort<br>
> term, would be to soft-fork in a reduction in the current and near-fut=
ure<br>
> mining rewards, by somehow locking the coins in a contract that depriv=
ed<br>
> the miner of the full reward, and then using that contract to pay the<=
br>
> rewards out far in the future, should at some point we feel the securi=
ty<br>
> budget was insufficient.<br>
><br>
> Yes, that's also possible, RSK uses that. And making some kind of<=
br>
> soft-fork for that is also possible, but I don't know if miners wi=
ll agree<br>
> to send some coinbase reward to "<futureBlockNumber> OP_CHE=
CKLOCKTIMEVERIFY<br>
> OP_DROP OP_TRUE".<br>
><br>
> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> >Bitcoin's finite supply is the main argument for people invest=
ing in it,<br>
> the whole narrative around bitcoin is based on its finite supply. Whil=
e it<br>
> has its flaws and basically condemns bitcoin to be only used as a stor=
e >of<br>
> value (and not as a currency), I don't think it's worth questi=
oning it at<br>
> this point.<br>
> ><br>
> >Just my 2 sats.<br>
> ><br>
> >Giuseppe.<br>
><br>
><br>
> A finite supply alone is not enough to give something value, as it mus=
t<br>
> also be useful in some way. In the case of Bitcoin, various forms of<b=
r>
> cryptographic security must all work - and work together - to make Bit=
coin<br>
> useful. If the only realistic (fair, efficient & proportionate) wa=
y to pay<br>
> for Bitcoin's security was by having some inflation scheme that vi=
olated<br>
> the 21 million cap, then agreeing to break the limit would probably be=
what<br>
> makes sense, and in the economic interest of its users and holders.<br=
>
><br>
> There will always be competitive pressures with respect to efficiency,=
and<br>
> both being over-secured and under-secured would be economically ineffi=
cient<br>
> for a crypto currency, and thereby laving room for a more optimally-se=
cured<br>
> competitor to gain ground. Currently there is zero feedback in the Bit=
coin<br>
> system between what we might think is the optimum amount of security a=
nd<br>
> what actually exists. There is also zero agreement on how much securit=
y<br>
> would constitute such an optimum. Figuring out how much security is ne=
eded,<br>
> or even better, figuring out a way to have a market mechanism to answe=
r<br>
> that question, will be an important project.<br>
><br>
> Another option, if we were to decide we are over-secured in the short<=
br>
> term, would be to soft-fork in a reduction in the current and near-fut=
ure<br>
> mining rewards, by somehow locking the coins in a contract that depriv=
ed<br>
> the miner of the full reward, and then using that contract to pay the<=
br>
> rewards out far in the future, should at some point we feel the securi=
ty<br>
> budget was insufficient. Anthony Towns presented a form of this concep=
t in<br>
> greater detail at a Scaling Bitcoin conference some years ago. While t=
his<br>
> solution, if employed, would only work for some finite amount of time,=
it<br>
> is possible that could give additional decades before the accumulated<=
br>
> security budget was exhausted.<br>
><br>
><br>
> Corey<br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">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=
/mailman/listinfo/bitcoin-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20220706/d5a48a69/attachment-0001.html" rel=3D"noreferrer" targ=
et=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attach=
ments/20220706/d5a48a69/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<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>
End of bitcoin-dev Digest, Vol 86, Issue 7<br>
******************************************<br>
</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:rg=
b(34,34,34)">--</span><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" st=
yle=3D"color:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D=
"ltr">CEO,=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rgb(17,85,204=
)" target=3D"_blank">Synonym.to</a><br><div><font size=3D"1"><br>Schedule:=
=C2=A0<a href=3D"https://calendly.com/bitcoinerrorlog" style=3D"color:rgb(1=
7,85,204)" target=3D"_blank">https://calendly.com/bitcoinerrorlog</a><br></=
font></div><div><font size=3D"1">Chat:=C2=A0<a href=3D"https://t.me/bitcoin=
errorlog" style=3D"color:rgb(17,85,204)" target=3D"_blank">https://t.me/bit=
coinerrorlog</a></font></div><div><font size=3D"1">Social:=C2=A0<a href=3D"=
https://twitter.com/bitcoinerrorlog" style=3D"color:rgb(17,85,204)" target=
=3D"_blank">https://twitter.com/bitcoinerrorlog</a></font></div></div></div=
></div></div>
--000000000000a1b84b05e33702f5--
|