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
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
|
Return-Path: <john@synonym.to>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id F1FB5C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jul 2022 07:26:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id BD16F41B91
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jul 2022 07:26:20 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BD16F41B91
Authentication-Results: smtp4.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=GgUQf4CH
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 smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NdVTI8cLSXaH
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jul 2022 07:26:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1608741B62
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com
[IPv6:2607:f8b0:4864:20::431])
by smtp4.osuosl.org (Postfix) with ESMTPS id 1608741B62
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Jul 2022 07:26:17 +0000 (UTC)
Received: by mail-pf1-x431.google.com with SMTP id w185so19127401pfb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 08 Jul 2022 00:26:17 -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
:cc; bh=C3CyQiqYCM+BQ04Y35OOWnIQaxuzLn69T1y2UmPQjEc=;
b=GgUQf4CHgqk/uQGEi6mFvLzj1fJHlvFDDM0BhsnRS4rmLEmm0RbrjCKkGXRwso9m7W
pVy12vTo6mHVfFYvo8kXew5uHGoCeRklWa62MdANO4rWmoiu1jtpiza9WM5EjnFkjTTU
d/3nkaR8xv02k47tNkZoBtsrPitjwjzRCquIMfJ3aHrkX9GzLo6tkB+TqJ3vd9/f44op
MHdsL73CdTmX/UFKCT0tk/vja1kV6iWrN5gXnT54KO/u6Phv4hGm5TPWzBcPnQcTwDFI
QjLELrijVvl2pWFqgWgjJM5nPhzWpKXINreLTDDTDjSawuBK5trjodIRcmwE4EOQRhSh
xBpA==
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:cc;
bh=C3CyQiqYCM+BQ04Y35OOWnIQaxuzLn69T1y2UmPQjEc=;
b=oCHfatIbJekk3f99L7s2GZuML+O3Yj7ayNrUpCq6puem4OzdBNBzhPn17S4g47nuNi
WtNEZlVRdNT+hzOZuWFWKfCpJoMfL1L8uTTkZAT8DfTStrHZzIgg5vZP4QvpLX0NTzbg
Qfbq8blEKCck7pXgjv2ovGcVoyzAXTwi3S/TQWc3fGsrhs2gA60Bgu3YCZvpPG2fz11j
+oZi2O8NDxzBeEAIGe0Lw9YLKgdBlQspji3WHEfp4K5/igsyjHRicKofCxTwfRjlmesA
AHR10FWjyLtz4PJXytbEQOiSTq2MaqVr0OEj0lJufqtwv+GMOX848AAgvUbR9VXopgmY
3TWw==
X-Gm-Message-State: AJIora+r8yEcgNLqIfZa+Zz45WltQTrDLNziRFiOT5yf629JwoAn/yAf
u5iNnATdhQcxdOgsoR11XMdopsgttA6NTT9Be4f7rg==
X-Google-Smtp-Source: AGRyM1tclmr0KlZSpgtdW9gwkH+b2ctusyqQF4hfoOT7WvL6qU4F4Jicl/iDOMjD6uW+6RFMA1VoThB3X9tuoo4E4C4=
X-Received: by 2002:a63:7a49:0:b0:40c:ca38:aed7 with SMTP id
j9-20020a637a49000000b0040cca38aed7mr2063257pgn.11.1657265177101; Fri, 08 Jul
2022 00:26:17 -0700 (PDT)
MIME-Version: 1.0
References: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org>
<164031557-1b12d278fcfb3b555675e972f034e87d@pmq7v.m5r2.onet>
In-Reply-To: <164031557-1b12d278fcfb3b555675e972f034e87d@pmq7v.m5r2.onet>
From: John Carvalho <john@synonym.to>
Date: Fri, 8 Jul 2022 08:26:06 +0100
Message-ID: <CAHTn92wOw9GwmN3XxwPOc=V=KMN6aX2v4tq662Uu=mQdxjpAcw@mail.gmail.com>
To: vjudeu@gazeta.pl
Content-Type: multipart/alternative; boundary="0000000000002e18fc05e3461ec4"
X-Mailman-Approved-At: Fri, 08 Jul 2022 08:48:24 +0000
Cc: "Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 08 Jul 2022 07:26:21 -0000
--0000000000002e18fc05e3461ec4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
vjudeu@gazeta.pl, what you describe is not possible without a hard fork,
just like Eric said. There is no atomic way to move Bitcoin off of Bitcoin.
You can use Bitcoin txns, or you can use trust/custody, or you can make a
shitcoin. There is no way to actually divide or transfer sats to another
network.
This talk of inflation is absurd and forced and ignores all understanding
of Bitcoin and economic primitives. You would all do better to listen to
Eric and appreciate him taking the time to elaborate.
In the end, I will reiterate. Proof of work and the difficulty adjustment
scheme already solve all of these issues. When blockspace demand increases,
fees increase, more miners mine, security goes up. Thus any theoretical
supply increase would have the opposite effect.
All of these arguments for inflation amount to "That restaurant is too
popular, nobody goes there anymore." If people are using Bitcoin, miners
will mine. If all Bitcoin users are hodling only, then demand is gone, and
miners will leave. It is elegant.
Stop trying to fix Bitcoin, it isn't broken.
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
On Fri, Jul 8, 2022 at 5:59 AM <vjudeu@gazeta.pl> wrote:
> > Simply fork off an inflation coin and test your theory. I mean, that=E2=
=80=99s
> the only way it can happen anyway.
>
> That would be an altcoin. But it can be done in a simpler way: we have 21
> million coins. It doesn't matter if it is 21 million, if it is 100 millio=
n,
> or if it is in some normalized range from 0 to 1, where you can always
> know, what fraction of the total supply you have. So, if the total supply
> is constant, then it is all about proportions. And that means, you can
> create some system on top of Bitcoin, that would move coins from users to
> miners. It is all about that: if all coins are mined, then they can move
> only if users will move them. So if you want to change that, it is all
> about encouraging them to put their coins in some evil Lightning channel,
> when they will lose their coins over time. That's how inflation works.
>
> So, imagine some evil channel, where you can put for example 0.01 BTC, an=
d
> have a time-based fee, so you will pay 1000 satoshis per day. Guess what:
> 1000 days, and your coins are gone! That means, if anyone want to test
> inflation, it is possible right here and right now. Good luck to convince
> people to use your inflationary system in a non-obfuscated way, because
> that's how it truly looks like: if you double coin supply, you can reach
> the same by halving all amounts.
>
>
> On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> Value is subjective, though a constraint of 1tx per 10 minutes seems
> unlikey to create a fee of 5000x that of 5000tx. This is of course why I
> stated my assumption. Yet this simple example should make clear that at
> some point a reduction in confirmation rate reduces reward. Otherwise a
> rate of zero implies infinite reward.
>
>
> You cannot support the blanket statement (and absent any assumption) that
> lower confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =
=E2=80=9Cbetter security=E2=80=9D.
>
>
> What you call a =E2=80=9Cbidding war=E2=80=9D is merely market pricing, a=
s it occurs with
> any good. People *always* will pay as much as they will pay. This is
> tautological. What you cannot say is how much more someone will pay at an=
y
> given time for any given good, until they have done it. And I=E2=80=99m p=
retty sure
> Bitcoin hasn=E2=80=99t done it.
>
>
> You cannot prove what the price of anything will be, nor can any =E2=80=
=9Cpapers=E2=80=9D.
> The absurdity of S2F should have clearly demonstrated that by now. Value =
is
> an individual human preference.
>
>
> If everyone pays 1 sat, then either miners are profitable at 1 sat, or
> these people are not getting confirmed (economic rationality always
> assumed).
>
>
> The assumption of 1 sat txs filling blocks is based on a
> disproportionately high subsidy. A subsidy of 50btc would imply somewhere
> in the neighborhood of $200 per tx in fees today, and as $680. As that
> falls, fees will continue to keep miners at the same profit level. If
> demand does not rise to compensate (as it always has) then hash rate will
> fall.
>
>
> Propping up hash rate with subsidy will not be =E2=80=9Cinflationary=E2=
=80=9D, as Bitcoin
> is a market money. Like gold it is produced at market cost. Yet it will
> prevent Bitcoin from achieving any meaningful level of censorship
> resistance. This of course should make people look closely at such
> arguments.
>
>
> Of course, once you have a censor, block space gets really small for thos=
e
> who want to resist the censor. Then of course only fees can offset the
> censorship. Without fee-based tx confirmation (for anonymity), and/or wit=
h
> a disproportionate subsidy going to the censor, a censor can operate
> profitably and indefinitely (under the assumption of constant demand).
> There is no reason to assume demand for censored txs wouldn=E2=80=99t eve=
n
> increase, given the white market blessing which so many seem to want.
>
>
> But there is of course no real issue here. Simply fork off an inflation
> coin and test your theory. I mean, that=E2=80=99s the only way it can hap=
pen anyway.
>
>
> e
>
>
> On Jul 7, 2022, at 14:11, Erik Aronesty <erik@q32.com> wrote:
>
>
>
> The relationship between block size and fees is not remotely linear. In
> a restricted environment, the fee rewards are much higher.
>
>
> **the ones moving more sats will win the top spots and will pay as much a=
s
> is reasonable**
>
>
> Smaller blocks produce better security for the network both in validation=
,
> and in fees.
>
>
> Without a bidding war for space, everyone can post 1 SAT/byte
>
>
> With a bidding war for space, larger transactions will pay much higher
> rates. There have been a number of papers written on this but you can
> concoct a trivial example to prove it.
>
>
>
>
> On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric@voskuil.org> wrote:
>
>
>
> 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 rewa=
rd
> remains constant.
>
>
> Any additional cost of processing more or less bytes would not matter,
> because 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 ca=
n
> afford to validate. That=E2=80=99s a threshold criteria.
>
>
> Given unlimited size blocks, miners would still have to fix a point in
> time to mine, gathering as much fee as they can optimize in some time
> period presumably less than 10 minutes. The produces a limit to transacti=
on
> volume, yet neither reward nor profit would be affected given the above
> assumptions. The difference would be in a tradeoff of per tx fee against
> the threshold.
>
>
> Given Moore=E2=80=99s Law, that threshold is constantly decreasing, which=
will
> make it cheaper over time for more individuals to validate. But the
> difference for miners for smaller blocks is largely inconsequential
> relative to their other costs.
>
>
> Increasing demand is the only thing that increases double spend security
> (and censorship resistance assuming fee-based reward). With rising demand
> there is rising overall hash rate, despite block reward and profit
> remaining constant. This makes the cost of attempting to orphan a block
> higher, therefore lowering 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 to subsidize a censorship regime. But the latter requires a
> differential in reward between the censor and non-censoring miners. While
> this could be paid in side fees, that is a significant anonymity issue.
>
>
> e
>
>
> On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32.com> wrote:
>
>
>
> > > We should not imbue real technology with magical qualities.
>
>
> > Precisely. It is economic forces (people), not technology, that provide
> security.
>
>
>
> Yes, and these forces don't prevent double-spend / 51% attacks if the
> amounts involved are greater than the incentives.
>
>
> In addition to "utility", lowering the block size could help prevent this
> issue as well... increasing fee pressure and double-spend security while
> reducing the burden on node operators.
>
>
> Changes to inflation are, very likely, off the table.
>
>
>
>
>
>
> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
>
> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev
> wrote:
> >> Billy,
> >>
> >> Proof of work and the difficulty adjustment function solve literally
> >> everything you are talking about already.
> >
> > Unfortunately you are quite wrong: the difficulty adjustment function
> merely
> > adjusts for changes in the amount of observable, non-51%-attacking,
> hashing
> > 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.
>
> Consider falling hash rate due to a perpetual 51% attack. Difficulty
> falls, possibly to min difficulty if all non-censors stop mining and with
> all censors collaborating (one miner). Yet as difficulty falls, so does t=
he
> cost of countering the censor. At min difficulty everyone can CPU mine
> again.
>
> Given the presumption that fees rise on unconfirmed transactions, there i=
s
> inherent economic incentive to countering at any level of difficulty.
> Consequently the censor is compelled to subsidize the loss resulting from
> forgoing higher fee transactions that are incentivizing its competition.
>
> With falling difficulty this incentive is compounded.
>
> Comparisons of security in different scenarios presume a consistent level
> of demand. If that demand is insufficient to offset the censor=E2=80=99s =
subsidy,
> there is no security in any scenario.
>
> Given that the block subsidy (inflation) is paid equally to censoring and
> non-censoring miners, it offers no security against censorship whatsoever=
.
> Trading fee-based block reward for inflation-based is simply trading
> censorship resistance for the presumption of double-spend security. But o=
f
> course, a censor can double spend profitably in any scenario where the
> double spend value (to the censor) exceeds that of blocks orphaned (as th=
e
> censor earns 100% of all block rewards).
>
> Banks and state monies offer reasonable double spend security. Not sure
> that=E2=80=99s a trade worth making.
>
> 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, once a
> sufficient number of units (to assure divisibility) had been issued, is
> what transitions Bitcoin from a censorable to a censorship resistant mone=
y.
> If one does not believe there is sufficient demand for such a money, ther=
e
> is no way to reconcile that belief with a model of censorship resistance.
>
> > We should not imbue real technology with magical qualities.
>
> Precisely. It is economic forces (people), not technology, that provide
> security.
>
> e
>
> >> Bitcoin does not need active economic governanance by devs or meddlers=
.
> >
> > Yes, active governance would definitely be an exploitable mechanism. On
> the
> > other hand, the status quo of the block reward eventually going away
> entirely
> > is obviously a risky state change too.
> >
> >>>> 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
> >
> > 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%
> is also
> > already an amount low enough that it's much smaller than economic
> volatility.
> >
> > Obviously 0% is too small.
> >
> > There's zero reason to stress about finding an "optimal" amount. An
> amount 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.
> >
> > 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%
> >
> > These are all amounts that are likely to be dwarfed by economic shifts.
> >
> > --
> > 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
>
>
--0000000000002e18fc05e3461ec4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><a href=3D"mailto:vjudeu@gazeta.pl">vjudeu@gazeta.pl</a>, =
what you describe is not possible without a hard fork, just like Eric said.=
There is no atomic way to move Bitcoin off of Bitcoin.=C2=A0<div><br></div=
><div>You can use Bitcoin txns, or you can use trust/custody, or you can ma=
ke a shitcoin. There is no way to actually divide or transfer sats to anoth=
er network.<div><br></div><div>This talk of inflation is absurd and forced =
and ignores all understanding of Bitcoin and economic primitives. You would=
all do better to listen to Eric and appreciate him taking the time to elab=
orate.</div><div><br></div><div>In the end, I will reiterate. Proof of work=
and the difficulty adjustment scheme already solve all of these issues. Wh=
en blockspace demand increases, fees increase, more miners mine, security g=
oes up. Thus any theoretical supply increase would have the opposite effect=
.=C2=A0</div><div><br></div><div>All of these arguments for inflation amoun=
t to "That restaurant is too popular, nobody goes there anymore."=
If people are using Bitcoin, miners will mine. If all Bitcoin users are ho=
dling=C2=A0only, then demand is gone, and miners will leave. It is elegant.=
</div><div><br></div><div>Stop trying to fix Bitcoin, it isn't broken.<=
br><div><table cellpadding=3D"0" class=3D"gmail-cf gmail-gJ" style=3D"borde=
r-collapse:collapse;margin-top:0px;width:auto;font-family:Roboto,RobotoDraf=
t,Helvetica,Arial,sans-serif;font-size:14px;letter-spacing:0.2px;display:bl=
ock"><tbody style=3D"display:block"><tr class=3D"gmail-acZ" style=3D"height=
:auto;display:flex"><td class=3D"gmail-gF gmail-gK" style=3D"white-space:no=
wrap;padding:0px;vertical-align:top;width:772.556px;line-height:20px;displa=
y:block;max-height:20px"><br><table cellpadding=3D"0" class=3D"gmail-cf gma=
il-ix" style=3D"border-collapse:collapse;table-layout:fixed;width:772.556px=
"><tbody></tbody></table></td></tr></tbody></table><div><div dir=3D"ltr" cl=
ass=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"=
><span style=3D"color:rgb(34,34,34)">--</span><br style=3D"color:rgb(34,34,=
34)"><div dir=3D"ltr" style=3D"color:rgb(34,34,34)"><div dir=3D"ltr">John C=
arvalho</div><div dir=3D"ltr">CEO,=C2=A0<a href=3D"http://synonym.to/" styl=
e=3D"color:rgb(17,85,204)" target=3D"_blank">Synonym.to</a><br><div><br></d=
iv></div></div></div></div></div></div></div></div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 8, 2022 at 5=
:59 AM <<a href=3D"mailto:vjudeu@gazeta.pl">vjudeu@gazeta.pl</a>> wro=
te:<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">> Simply =
fork off an inflation coin and test your theory. I mean, that=E2=80=99s the=
only way it can happen anyway.<br>
<br>
That would be an altcoin. But it can be done in a simpler way: we have 21 m=
illion coins. It doesn't matter if it is 21 million, if it is 100 milli=
on, or if it is in some normalized range from 0 to 1, where you can always =
know, what fraction of the total supply you have. So, if the total supply i=
s constant, then it is all about proportions. And that means, you can creat=
e some system on top of Bitcoin, that would move coins from users to miners=
. It is all about that: if all coins are mined, then they can move only if =
users will move them. So if you want to change that, it is all about encour=
aging them to put their coins in some evil Lightning channel, when they wil=
l lose their coins over time. That's how inflation works.<br>
<br>
So, imagine some evil channel, where you can put for example 0.01 BTC, and =
have a time-based fee, so you will pay 1000 satoshis per day. Guess what: 1=
000 days, and your coins are gone! That means, if anyone want to test infla=
tion, it is possible right here and right now. Good luck to convince people=
to use your inflationary system in a non-obfuscated way, because that'=
s how it truly looks like: if you double coin supply, you can reach the sam=
e by halving all amounts.<br>
<br>
<br>
On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
<br>
<br>
Value is subjective, though a constraint of 1tx per 10 minutes seems unlike=
y to create a fee of 5000x that of 5000tx. This is of course why I stated m=
y assumption. Yet this simple example should make clear that at some point =
a reduction in confirmation rate reduces reward. Otherwise a rate of zero i=
mplies infinite reward.=C2=A0<br>
<br>
<br>
You cannot support the blanket statement (and absent any assumption) that l=
ower confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=
=80=9Cbetter security=E2=80=9D.<br>
<br>
<br>
What you call a =E2=80=9Cbidding war=E2=80=9D is merely market pricing, as =
it occurs with any good. People *always* will pay as much as they will pay.=
This is tautological. What you cannot say is how much more someone will pa=
y at any given time for any given good, until they have done it. And I=E2=
=80=99m pretty sure Bitcoin hasn=E2=80=99t done it.<br>
<br>
<br>
You cannot prove what the price of anything will be, nor can any =E2=80=9Cp=
apers=E2=80=9D. The absurdity of S2F should have clearly demonstrated that =
by now. Value is an individual human preference.<br>
<br>
<br>
If everyone pays 1 sat, then either miners are profitable at 1 sat, or thes=
e people are not getting confirmed (economic rationality always assumed).<b=
r>
<br>
<br>
The assumption of 1 sat txs filling blocks is based on a disproportionately=
high subsidy. A subsidy of 50btc would imply somewhere in the neighborhood=
of $200 per tx in fees today, and as $680. As that falls, fees will contin=
ue to keep miners at the same profit level. If demand does not rise to comp=
ensate (as it always has) then hash rate will fall.<br>
<br>
<br>
Propping up hash rate with subsidy will not be =E2=80=9Cinflationary=E2=80=
=9D, as Bitcoin is a market money. Like gold it is produced at market cost.=
Yet it will prevent Bitcoin from achieving any meaningful level of censors=
hip resistance. This of course should make people look closely at such argu=
ments.<br>
<br>
<br>
Of course, once you have a censor, block space gets really small for those =
who want to resist the censor. Then of course only fees can offset the cens=
orship. Without fee-based tx confirmation (for anonymity), and/or with a di=
sproportionate subsidy going to the censor, a censor can operate profitably=
and indefinitely (under the assumption of constant demand). There is no re=
ason to assume demand for censored txs wouldn=E2=80=99t even increase, give=
n the white market blessing which so many seem to want.<br>
<br>
<br>
But there is of course no real issue here. Simply fork off an inflation coi=
n and test your theory. I mean, that=E2=80=99s the only way it can happen a=
nyway.<br>
<br>
<br>
e<br>
<br>
<br>
On Jul 7, 2022, at 14:11, Erik Aronesty <<a href=3D"mailto:erik@q32.com"=
target=3D"_blank">erik@q32.com</a>> wrote:<br>
<br>
<br>
<br>
The relationship between block size and fees is not remotely linear.=C2=A0 =
=C2=A0In a restricted environment, the fee rewards are much higher.<br>
<br>
<br>
**the ones moving=C2=A0more sats will win the top spots and will pay as muc=
h as is reasonable**<br>
<br>
<br>
Smaller blocks produce better security for the network both in validation, =
and in fees.<br>
<br>
<br>
Without=C2=A0a bidding war for space, everyone can post 1 SAT/byte<br>
<br>
<br>
With a bidding war for space, larger transactions will pay much higher rate=
s.=C2=A0 =C2=A0There have been a number of papers written on this but you c=
an concoct a trivial example to prove it.<br>
<br>
<br>
<br>
<br>
On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <<a href=3D"mailto:eric@vosk=
uil.org" target=3D"_blank">eric@voskuil.org</a>> wrote:<br>
<br>
<br>
<br>
It=E2=80=99s not clear how reducing block size changes the fee aspect of th=
e block reward. Assuming=C2=A0half the space implies twice the fee per avg =
tx the reward remains constant.<br>
<br>
<br>
Any additional cost of processing more or less bytes would not matter, beca=
use 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.<br>
<br>
<br>
The reason for smaller vs. larger blocks is to ensure that individuals can =
afford to validate. That=E2=80=99s a threshold criteria.<br>
<br>
<br>
Given unlimited size blocks, miners would still have to fix a point in time=
to mine, gathering as much fee as they can optimize in some time period pr=
esumably less than 10 minutes. The produces a limit to transaction volume, =
yet neither reward nor profit would be affected given the above assumptions=
. The difference would be in a tradeoff of per tx fee against the threshold=
.<br>
<br>
<br>
Given Moore=E2=80=99s Law, that threshold is constantly decreasing, which w=
ill make it =C2=A0cheaper over time for more individuals to validate. But t=
he difference for miners for smaller blocks is largely inconsequential rela=
tive to their other costs.<br>
<br>
<br>
Increasing demand is the only thing that increases double spend security (a=
nd censorship resistance assuming fee-based reward). With rising demand the=
re is rising overall hash rate, despite block reward and profit remaining c=
onstant. This makes the cost of attempting to orphan a block higher, theref=
ore lowering the depth/time requirement implied to secure a given tx amount=
.<br>
<br>
<br>
These are the two factors, demand and time. Less demand implies more time t=
o secure a given amount against double spend, and also implies a lower cost=
to subsidize a censorship regime. But the latter requires a differential i=
n reward between the censor and non-censoring miners. While this could be p=
aid in side fees, that is a significant anonymity issue.<br>
<br>
<br>
e<br>
<br>
<br>
On Jul 7, 2022, at 10:37, Erik Aronesty <<a href=3D"mailto:erik@q32.com"=
target=3D"_blank">erik@q32.com</a>> wrote:<br>
<br>
<br>
<br>
> > We should not imbue real technology with magical qualities.<br>
<br>
<br>
> Precisely. It is economic forces (people), not technology, that provid=
e security.<br>
<br>
<br>
<br>
Yes, and these forces don't prevent double-spend / 51% attacks if the a=
mounts involved are greater than the incentives.<br>
<br>
<br>
In addition to "utility", lowering the block size could help prev=
ent this issue as well... increasing fee pressure and double-spend security=
while reducing the burden on node operators.<br>
<br>
<br>
Changes to inflation are, very likely, off the table.<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>> wrote:<br>
<br>
<br>
<br>
> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>> wrote:<br>
><br>
> On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-de=
v wrote:<br>
>> Billy,<br>
>><br>
>> Proof of work and the difficulty adjustment function solve literal=
ly<br>
>> everything you are talking about already.<br>
><br>
> Unfortunately you are quite wrong: the difficulty adjustment function =
merely<br>
> adjusts for changes in the amount of observable, non-51%-attacking, ha=
shing<br>
> power. In the event of a chain split, the difficulty adjustment functi=
on does<br>
> nothing; against a 51% attacker, the difficulty adjustment does nothin=
g;<br>
> against a censor, the difficulty adjustment does nothing.<br>
<br>
Consider falling hash rate due to a perpetual 51% attack. Difficulty falls,=
possibly to min difficulty if all non-censors stop mining and with all cen=
sors collaborating (one miner). Yet as difficulty falls, so does the cost o=
f countering the censor. At min difficulty everyone can CPU mine again.<br>
<br>
Given the presumption that fees rise on unconfirmed transactions, there is =
inherent economic incentive to countering at any level of difficulty. Conse=
quently the censor is compelled to subsidize the loss resulting from forgoi=
ng higher 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 o=
f demand. If that demand is insufficient to offset the censor=E2=80=99s sub=
sidy, there is no security in any scenario.<br>
<br>
Given that the block subsidy (inflation) is paid equally to censoring and n=
on-censoring miners, it offers no security against censorship whatsoever. T=
rading fee-based block reward for inflation-based is simply trading censors=
hip resistance for the presumption of double-spend security. But of course,=
a censor can double spend profitably in any scenario where the double spen=
d value (to the censor) exceeds that of blocks orphaned (as the censor earn=
s 100% of all block rewards).<br>
<br>
Banks and state monies offer reasonable double spend security. Not sure tha=
t=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=
=99ve 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 what transitions Bitcoin from a censorable to a censorship resistant mo=
ney. If one does not believe there is sufficient demand for such a money, t=
here is no way to reconcile that belief with a model of censorship resistan=
ce.<br>
<br>
> We should not imbue real technology with magical qualities.<br>
<br>
Precisely. It is economic forces (people), not technology, that provide sec=
urity.<br>
<br>
e<br>
<br>
>> Bitcoin does not need active economic governanance by devs or medd=
lers.<br>
><br>
> Yes, active governance would definitely be an exploitable mechanism. O=
n the<br>
> other hand, the status quo of the block reward eventually going away e=
ntirely<br>
> is obviously a risky state change too.<br>
><br>
>>>> There is also zero agreement on how much security would co=
nstitute such<br>
>>> an optimum.<br>
>>><br>
>>> This is really step 1. We need to generate consensus on this l=
ong before<br>
>>> the block subsidy becomes too small. Probably in the next 10-1=
5 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%=
is also<br>
> already an amount low enough that it's much smaller than economic =
volatility.<br>
><br>
> Obviously 0% is too small.<br>
><br>
> There's zero reason to stress about finding an "optimal"=
amount. An amount low<br>
> enough to be easily affordable, but non-zero, is fine. 1% would be fin=
e; 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 3=
1% 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"_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>
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>
</blockquote></div>
--0000000000002e18fc05e3461ec4--
|