summaryrefslogtreecommitdiff
path: root/b5/d358865c673a39a4192c1f88a617ac79401aa0
blob: 585bcf067221d4fb0cfaeb80da29d3ce5459ee22 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
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
Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B7ADDC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  4 Jan 2023 16:03:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 8488380B0C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  4 Jan 2023 16:03:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8488380B0C
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=BIbqE9Kd
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level: 
X-Spam-Status: No, score=-2.087 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_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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id p3nZrmWWJ-zk
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  4 Jan 2023 16:03:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 49C348186E
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
 [IPv6:2a00:1450:4864:20::533])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 49C348186E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  4 Jan 2023 16:03:33 +0000 (UTC)
Received: by mail-ed1-x533.google.com with SMTP id c34so42596665edf.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 04 Jan 2023 08:03:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=91MmkAamfCCP/v0J2/TcLvm3SahWwlbybHAPO/ShLBA=;
 b=BIbqE9KdOWB/ecXtxd4tb1thxgjaCC3k6VcF3ULt0UkReXqi/ay4W4vc7YHKT1773E
 tkeG43cPogrR2uEFsXZORc3gzt2VjJ8LMsrGZMBJEixvA0GlUlma9X9mc6Dj+uMYkgA7
 7W62XQVtcJvDfXUUDtfkAZ/3Jk67jSD8Tmguc6/0ZRifgQQnyrM3taDymeKMJer7lEOD
 /LPgryznLPErIIp3Oj1vLxNBOfBwZjfcO0hcvhZ3B/kSgQWGNb3YGv1p3x9wCaDcPWa9
 Pz3tXNdTcwW0UyqjPO5mku0gEGgBizfm6H2JE+YZFXwDHqDGZrb9ghxPcXQqaq/xJzCH
 Nj3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc: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=91MmkAamfCCP/v0J2/TcLvm3SahWwlbybHAPO/ShLBA=;
 b=Dk6evkd3FuOUQr6/zU9fsWkl4wbUpYppZTitSzutYUPgZqzsQonPT8yvTpNyHLb/tN
 vGKeiqdY+J2oIsSdxDVlNCW+mFF2kqTAHeDuvO60gY0RkO8nSliRqLrpRzXmEEvL+to+
 oNqzLMqIUpUaIloWDtFmVU9XaUH5EUP9MKY4RrboIyyxfH76a4dxCfpGNxtK/s1tch3d
 Yc7Nmw1fryQFP/BJc8pOIkqbBgdfv8jzqQQfBwiZ/JqD1XACd1fcn0NkPtqGT2WG3jYb
 fgS3w53BmguGjKnMWyLtui+XlKU5RhZ3fnz3ejHJJqskMr429UprQvDWDivBuNGoUwc6
 9YRA==
X-Gm-Message-State: AFqh2kqu/wFAFloi9RPYp5PhBLjdDPGAqvXtjIisTeE1OYN8lxFedCwH
 H8rtujmwRSn+DDG1t8OT0e3yENXMR1wJ6kc3+upjHpa3
X-Google-Smtp-Source: AMrXdXvWa7Exj9QtPOymICjbQbbT6qQb1gWYG0Ko8x3+5zGvl5RDidKzhpYP2ksb5YxtznqGQ6NCjpliSSVoVUJFy/Y=
X-Received: by 2002:aa7:d992:0:b0:482:b5b3:9130 with SMTP id
 u18-20020aa7d992000000b00482b5b39130mr3578397eds.177.1672848211099; Wed, 04
 Jan 2023 08:03:31 -0800 (PST)
MIME-Version: 1.0
References: <174713476-5bd35a73599a0a65335d70e99a1bb44e@pmq1v.m5r2.onet>
In-Reply-To: <174713476-5bd35a73599a0a65335d70e99a1bb44e@pmq1v.m5r2.onet>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 4 Jan 2023 10:03:10 -0600
Message-ID: <CAGpPWDbpKXHMhOm_hTiJ+LPeWQff1T9GTDe8xKM0i8gGDfiwVg@mail.gmail.com>
To: jk_14@op.pl
Content-Type: multipart/alternative; boundary="00000000000062c35105f1725315"
X-Mailman-Approved-At: Thu, 05 Jan 2023 11:07:57 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Wed, 04 Jan 2023 16:03:35 -0000

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

> 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
<https://decrypt.co/57740/bitcoin-miners-now-earn-1-btc-in-fees-per-block>.
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
<https://en.wikipedia.org/wiki/List_of_countries_by_government_budget> 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
<https://files.stlouisfed.org/files/htdocs/publications/review/92/03/Seigni=
orage_Mar_Apr1992.pdf>
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 would place an upper bound of $180 billion/year of
seigniorage extraction that would be at risk if bitcoin might put the
currencies they gain seigniorage 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 billion,
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 the
equivalent revenue (from fees) would be earned, then a price 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 towards the realm
of impossibility, so if we think that much security is necessary, we might
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 grow
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 supporting
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 (specifically,
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 bitcoin.

On Mon, Jan 2, 2023 at 5:02 PM <jk_14@op.pl> wrote:

>
>
> Right now security comes from almost fully from ~1.8% inflation.
> In November mempool was inflated to ~150MB and people were rather waiting
> for cheap transactions back.
> Instead of being happy that system is closer for a while to default
> working area.
>
> Deflation in Bitcoin is not 1:1 matter like in gold, for example.
> If all plain gold available to mine would be finished - gold mines as
> unprofitable enterprices are immediately closed.
> And it doesn't affect security of gold already in circulation.
> In Bitcoin "the show must go on" and someone must pay for it.
> Active and passive users together (balanced by market play) or: only
> active users (in current scenario, long-term).
>
> Deflation (or more precisely: tiny inflation) in Bitcoin is more complex
> issue with more repercussions than in gold.
> In case of drop of network security - the tax will be paid anyway, in
> Bitcoin price.
> So, there is an self-regulating mechanism here. The harsh one, but still.
>
>
>
> W dniu 2023-01-02 05:53:57 u=C5=BCytkownik Billy Tetrud <billy.tetrud@gma=
il.com>
> napisa=C5=82:
> > is surely better than not delaying it.
>
> I might agree, but I don't think it really solves the problem well enough
> to be worth it. Any solution that would solve the problem better would ma=
ke
> delaying halvings unnecessary.
>
> > there is non-zero risk that people will hoard it more and more,
> according to old Gresham's law
>
>
> Gresham's law doesn't apply here. Gresham's law is about the interaction
> between two currencies with a fixed, usually government-enforced exchange
> rate. You seem to be saying that Bitcoin will be hoarded because Bitcoin
> inflation reduces every halving. But even with 0 inflation, it certainly
> won't cause all Bitcoin to be hoarded. Also, "hoarding" is also known as
> "saving", and there's nothing wrong with saving. The spectre of deflation
> comes from a misunderstanding of deflation and why it happens during bad
> economic times. It is an effect, not a cause.
>
>
> On Sun, Jan 1, 2023, 15:23 <jk_14@op.pl> wrote:
>
> Yes, the idea is:
> if mining activity is growing - let's execute consecutive halvings
> but if miner exodus has happened - let's delay next halving until mining
> activity is recovered to previous levels
>
> If it gets to the point where a sudden drop in mining difficulty happens =
-
> delaying the next halving may be not sufficient to correct, but is surely
> better than not delaying it.
>
> While Bitcoin is better and better money with every halving in comparisio=
n
> to other types of money - there is non-zero risk that people will hoard i=
t
> more and more, according to old Gresham's law ("HODL"). And this way
> decreasing liquidity / transactions volume. The positive feedback loop - =
is
> my real concern here.
>
> Regarding the relationship between difficulty and security - I fully agre=
e.
> But ASIC technology is already matured. And also any technology
> breakthrough is a short event within 4 years period.
> So growth of difficulty could be gained by technology breakthrough, but
> any sudden drop of difficulty would be always an issue, while there is no
> such thing as: ASIC technology regression.
>
> Obviously, not complicated solution would be better than complicated one.
>
>
>
>
> W dniu 2022-12-30 19:21:10 u=C5=BCytkownik Billy Tetrud <billy.tetrud@gma=
il.com>
> napisa=C5=82:
> If the idea is to ensure that a catastrophic miner exodus doesn't happen,
> the "difference" you're calculating should only care about downward
> differences. Upward differences indicate more mining activity and so
> shouldn't cause a halving skip.
>
>
> But I don't think any scheme like this that only acts on the basis of
> difficulty will be sufficient. If it gets to the point where a sudden dro=
p
> in mining difficulty happens, it is very likely that simply delaying the
> next halving or even ending halving all together will not be sufficient t=
o
> correct for whatever is causing hashrate to tank. There is also the dange=
r
> of simple difficulty stagnation, which this mechanism wouldn't detect.
>
>
> The relationship between difficulty and security becomes less and less
> predictable the longer you want to look ahead. There's no long term
> relation between difficulty and any reasonable security target. A securit=
y
> target might be something like "no colluding group with less than $1
> trillion dollars at their disposal could successfully 51% attack the
> network (with a probability of blah blah)". There is no way to today
> program in any code that detects based on difficult alone when that
> criteria is violated. You would have to program in assumptions about the
> cost of hashrate projected into the future.
>
>
> I can't think of any robust automatic way to do this. I think to a certai=
n
> degree, it will have to be a change that happens in a fork of some kind
> (soft or hard) periodically (every 10 years? 30 years?). The basic
> relations needed is really the cost in Bitcoin of the security target (ie
> the minimum number of Bitcoin it should take to 51% attack the system) an=
d
> the cost in Bitcoin of acquiring a unit of hashrate. This could be simply
> input into the code, or could use some complicated oracle system. But wit=
h
> that relation, the system could be programmed to calculate the difficulty
> necessary to keep the system secure.
>
>
> Once that is in place, the system could automatically adjust the subsidy
> up or down to attract more or less miners, or it could adjust the block
> size up or down to change the fee market such that more or less total fee=
s
> are collected each block to attract more or less miners.
>
>
> On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> It seems like the more elegant solution could be by using a chainwork
> parameter instead.
> i.e. comparison just before halving - if the last 210,000 block interval
> has a higher chainwork difference between the begining and the end of
> interval
> than any other such inter-halving interval before.
>
> LIttle digression yet:
> A system in which all users participate in ensuring its security looks
> better than one in which only some (i.e. active) of them participate (and
> passive stakeholders are de facto free riders)
> In my opinion this concept above is only the complement of currently
> missing mechanism: achieving equilibrium regarding costs of security
> between two parties with opposing interests.
> It's easy to understand and - most important - it has no hardcoded value
> of tail emission - what is the clear proof it is based on a free market.
> And last but not least, if someone is 100% sure that income from
> transactions will takeover security support from block subsidy - acceptin=
g
> such proposal is like putting the money where the mouth is: this safety
> measure will never be triggered, then (no risk of fork)
>
>
> Best Regards
> Jaroslaw
>
>
>
> W dniu 2022-12-23 20:29:20 u=C5=BCytkownik Jaroslaw via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> napisa=C5=82:
> >
> Necessary or not - it doesn't hurt to plan the robust model, just in case=
.
> The proposal is:
>
> Let every 210,000 the code calculate the average difficulty of 100 last
> retargets (100 fit well in 210,000 / 2016 =3D 104.166)
> and compare with the maximum of all such values calculated before, every
> 210,000 blocks:
>
>
> if average_diff_of_last_100_retargets >
> maximum_of_all_previous_average_diffs
>         do halving
> else
>         do nothing
>
>
> This way:
>
> 1. system cannot be played
> 2. only in case of destructive halving: system waits for the recovery of
> network security
>
>
> Best Regards
> Jaroslaw
> _______________________________________________
> 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
>
>
>

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

<div dir=3D"ltr"><div><div>&gt; In Bitcoin &quot;the show must go on&quot; =
and someone must pay for it. Active [and/or] passive users=C2=A0</div><div>=
<br></div><div>I certainly=C2=A0agree.=C2=A0</div><div><br></div><div>&gt; =
or more precisely: tiny inflation</div><div><br></div><div>=F0=9F=91=8D</di=
v></div><div><br></div><div>&gt; Right now security comes from almost fully=
 from ~1.8% inflation.</div><div><br></div>Best I could find, fees make up =
<a href=3D"https://decrypt.co/57740/bitcoin-miners-now-earn-1-btc-in-fees-p=
er-block" target=3D"_blank">about 13% of miner revenue</a>. 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<div><br></div><div>Have there been any thoughts put out in the communit=
y as to what size of threat is unlikely enough to arise=C2=A0that we don&#3=
9;t need to worry about it? Maybe 1% of the yearly=C2=A0<a href=3D"https://=
en.wikipedia.org/wiki/List_of_countries_by_government_budget" target=3D"_bl=
ank">government budgets</a>=C2=A0of the world=C2=A0would be an upper bound =
on how much anyone would expect could realistically be brought to bear? Tod=
ay that would be maybe around $350 billion.=C2=A0</div><div><br></div><div>=
Or perhaps a better way to estimate would be calculating the size of the mo=
tivation of an attacker. For example, <a href=3D"https://files.stlouisfed.o=
rg/files/htdocs/publications/review/92/03/Seigniorage_Mar_Apr1992.pdf" targ=
et=3D"_blank">this paper</a>=C2=A0seems 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 would place an upper bound=
 of $180 billion/year of seigniorage extraction that would be at risk if bi=
tcoin might put the currencies they gain seigniorage from out of business. =
Over 10 years (about as far as we can expect any government to think), that=
&#39;s almost $2 trillion.=C2=A0</div><div><br></div><div>Whereas it would =
currently cost probably less than $7 billion=C2=A0to purchase a 50% share o=
f bitcoin miners. To eventually reach a level of $350 billion, 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, you&#39;d need a pr=
ice of $4.3 million/bitcoin. That&#39;s still probably within the realm of =
possibility, but certainly not as likely.=C2=A0

If you then assume we won&#39;t have significant coinbase rewards by that p=
oint, and only 13% of the equivalent revenue (from fees) would be earned, t=
hen a price of ~$6 million would be needed to support a $350 billion and $3=
4 million to support a $2 trillion security. I think that second one is get=
ting up towards the realm of impossibility, so if we think that much securi=
ty is necessary, we might 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 grow superlinearly in comparison to market cap, which w=
ould make these kind of high levels of security more realistic.=C2=A0</div>=
<div><div><br></div><div>Anyways if it turns out that fees alone don&#39;t =
look like they&#39;re supporting enough security, we have a good amount of =
time to come to that conclusion and do something about it.=C2=A0</div></div=
><div><br></div><div>&gt; Deflation in Bitcoin is not 1:1 matter like in go=
ld, for example...=C2=A0

Deflation in Bitcoin is more complex issue<br><br></div><div>It&#39;s helpf=
ul to keep our language precise here. Price inflation and deflation act ide=
ntically in bitcoin and gold and anything else. What you seem to be talking=
 about at this point is monetary inflation (specifically, 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&#39;s law was specifically talking about price inflatio=
n, not the effects of the coin emission machinery in bitcoin.=C2=A0</div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Mon, Jan 2, 2023 at 5:02 PM &lt;<a href=3D"mailto:jk_14@op.pl" target=3D"_=
blank">jk_14@op.pl</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><br>
<br>
Right now security comes from almost fully from ~1.8% inflation.<br>
In November mempool was inflated to ~150MB and people were rather waiting f=
or cheap transactions back.<br>
Instead of being happy that system is closer for a while to default working=
 area.<br>
<br>
Deflation in Bitcoin is not 1:1 matter like in gold, for example.<br>
If all plain gold available to mine would be finished - gold mines as unpro=
fitable enterprices are immediately closed.<br>
And it doesn&#39;t affect security of gold already in circulation.<br>
In Bitcoin &quot;the show must go on&quot; and someone must pay for it.<br>
Active and passive users together (balanced by market play) or: only active=
 users (in current scenario, long-term).<br>
<br>
Deflation (or more precisely: tiny inflation) in Bitcoin is more complex is=
sue with more repercussions than in gold.<br>
In case of drop of network security - the tax will be paid anyway, in Bitco=
in price.<br>
So, there is an self-regulating mechanism here. The harsh one, but still.<b=
r>
<br>
<br>
<br>
W dniu 2023-01-02 05:53:57 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;=C2=A0is surely better than not delaying it.<br>
=C2=A0<br>
I might agree, but I don&#39;t think it really solves the problem well enou=
gh to be worth it. Any solution that would solve the problem better would m=
ake delaying halvings unnecessary.=C2=A0<br>
=C2=A0<br>
&gt;=C2=A0there is non-zero risk that people will hoard it more and more, a=
ccording to old Gresham&#39;s law<br>
<br>
<br>
Gresham&#39;s law doesn&#39;t apply here. Gresham&#39;s law is about the in=
teraction between two currencies with a fixed, usually government-enforced =
exchange rate. You seem to be saying that Bitcoin will be hoarded because B=
itcoin inflation reduces every halving. But even with 0 inflation, it certa=
inly won&#39;t cause all Bitcoin to be hoarded. Also, &quot;hoarding&quot; =
is also known as &quot;saving&quot;, and there&#39;s nothing wrong with sav=
ing. The spectre of deflation comes from a misunderstanding of deflation an=
d why it happens during bad economic times. It is an effect, not a cause.<b=
r>
<br>
<br>
On Sun, Jan 1, 2023, 15:23 &lt;<a href=3D"mailto:jk_14@op.pl" target=3D"_bl=
ank">jk_14@op.pl</a>&gt; wrote:<br>
<br>
Yes, the idea is:<br>
if mining activity is growing - let&#39;s execute consecutive halvings<br>
but if miner exodus has happened - let&#39;s delay next halving until minin=
g activity is recovered to previous levels<br>
<br>
If it gets to the point where a sudden drop in mining difficulty happens - =
delaying the next halving may be not sufficient to correct, but is surely b=
etter than not delaying it.<br>
<br>
While Bitcoin is better and better money with every halving in comparision =
to other types of money - there is non-zero risk that people will hoard it =
more and more, according to old Gresham&#39;s law (&quot;HODL&quot;). And t=
his way decreasing liquidity / transactions volume. The positive feedback l=
oop - is my real concern here.<br>
<br>
Regarding the relationship between difficulty and security - I fully agree.=
<br>
But ASIC technology is already matured. And also any technology breakthroug=
h is a short event within 4 years period.<br>
So growth of difficulty could be gained by technology breakthrough, but any=
 sudden drop of difficulty would be always an issue, while there is no such=
 thing as: ASIC technology regression.<br>
<br>
Obviously, not complicated solution would be better than complicated one.<b=
r>
<br>
<br>
<br>
<br>
W dniu 2022-12-30 19:21:10 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>
If the idea is to ensure that a catastrophic miner exodus doesn&#39;t happe=
n, the &quot;difference&quot; you&#39;re calculating should only care about=
 downward differences. Upward differences indicate more mining activity and=
 so shouldn&#39;t cause a halving skip.<br>
<br>
<br>
But I don&#39;t think any scheme like this that only acts on the basis of d=
ifficulty will be sufficient. If it gets to the point where a sudden drop i=
n mining difficulty happens, it is very likely that simply delaying the nex=
t halving or even ending halving all together will not be sufficient to cor=
rect for whatever is causing hashrate to tank. There is also the danger of =
simple difficulty stagnation, which this mechanism wouldn&#39;t detect.=C2=
=A0<br>
<br>
<br>
The relationship between difficulty and security becomes less and less pred=
ictable the longer you want to look ahead. There&#39;s no long term relatio=
n between difficulty and any reasonable security target. A security target =
might be something like &quot;no colluding group with less than $1 trillion=
 dollars at their disposal could successfully 51% attack the network (with =
a probability of blah blah)&quot;. There is no way to today program in any =
code that detects based on difficult alone when that criteria is violated. =
You would have to program in assumptions about the cost of hashrate project=
ed into the future.<br>
<br>
<br>
I can&#39;t think of any robust automatic way to do this. I think to a cert=
ain degree, it will have to be a change that happens in a fork of some kind=
 (soft or hard) periodically (every 10 years? 30 years?). The basic relatio=
ns needed is really the cost in Bitcoin of the security target (ie the mini=
mum number of Bitcoin it should take to 51% attack the system) and the cost=
 in Bitcoin of acquiring a unit of hashrate. This could be simply input int=
o the code, or could use some complicated oracle system. But with that rela=
tion, the system could be programmed to calculate the difficulty necessary =
to keep the system secure.<br>
<br>
<br>
Once that is in place, the system could automatically adjust the subsidy up=
 or down to attract more or less miners, or it could adjust the block size =
up or down to change the fee market such that more or less total fees are c=
ollected each block to attract more or less miners.=C2=A0<br>
<br>
<br>
On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev &lt;<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br>
<br>
It seems like the more elegant solution could be by using a chainwork param=
eter instead.<br>
i.e. comparison just before halving - if the last 210,000 block interval ha=
s a higher chainwork difference between the begining and the end of interva=
l<br>
than any other such inter-halving interval before.<br>
<br>
LIttle digression yet:<br>
A system in which all users participate in ensuring its security looks bett=
er than one in which only some (i.e. active) of them participate (and passi=
ve stakeholders are de facto free riders)<br>
In my opinion this concept above is only the complement of currently missin=
g mechanism: achieving equilibrium regarding costs of security between two =
parties with opposing interests.<br>
It&#39;s easy to understand and - most important - it has no hardcoded valu=
e of tail emission - what is the clear proof it is based on a free market.<=
br>
And last but not least, if someone is 100% sure that income from transactio=
ns will takeover security support from block subsidy - accepting such propo=
sal is like putting the money where the mouth is: this safety measure will =
never be triggered, then (no risk of fork)<br>
<br>
<br>
Best Regards<br>
Jaroslaw<br>
<br>
<br>
<br>
W dniu 2022-12-23 20:29:20 u=C5=BCytkownik Jaroslaw via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; napisa=C5=82:<br>
&gt;<br>
Necessary or not - it doesn&#39;t hurt to plan the robust model, just in ca=
se. The proposal is:<br>
<br>
Let every 210,000 the code calculate the average difficulty of 100 last ret=
argets (100 fit well in 210,000 / 2016 =3D 104.166)<br>
and compare with the maximum of all such values calculated before, every 21=
0,000 blocks:<br>
<br>
<br>
if average_diff_of_last_100_retargets &gt; maximum_of_all_previous_average_=
diffs<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do halving<br>
else<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do nothing<br>
<br>
<br>
This way:<br>
<br>
1. system cannot be played<br>
2. only in case of destructive halving: system waits for the recovery of ne=
twork security<br>
<br>
<br>
Best Regards<br>
Jaroslaw<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>
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>
</blockquote></div>

--00000000000062c35105f1725315--