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
|
Return-Path: <jk_14@op.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id B0A2CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Jan 2023 10:20:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 83A0D82B81
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Jan 2023 10:20:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 83A0D82B81
Authentication-Results: smtp1.osuosl.org;
dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
header.s=2011 header.b=VlpWnZDt
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] 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 bj3yl6Z0CySZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Jan 2023 10:20:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D046482B49
Received: from smtpo90.poczta.onet.pl (smtpo90.poczta.onet.pl
[213.180.149.143])
by smtp1.osuosl.org (Postfix) with ESMTPS id D046482B49
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 21 Jan 2023 10:20:13 +0000 (UTC)
Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4NzXRn0vw4z2K3B05;
Sat, 21 Jan 2023 11:20:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
t=1674296405; bh=eiqQ3LawuQ4FokFNubbDX6eq7y5IAP8FzMl8G60m6Q8=;
h=From:Cc:To:Date:Subject:From;
b=VlpWnZDtdjGERxl4YiGDbKquqRl11CpkB1DipEEwuYrHhFCZNYn0JwKRK4SiD6RY0
WYThrXPwmqE1xSRLMOFh9qt6WV1rcDh7R0QgP999+u0eV1dsuzK5gFW4OBRMFCyfL3
ZqFrrAmJvwpaXakTtPQQbvnB80eSiC/7ahowUN4M=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [89.64.64.219] by pmq6v.m5r2.onet via HTTP id ;
Sat, 21 Jan 2023 11:20:05 +0100
From: jk_14@op.pl
X-Priority: 3
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Date: Sat, 21 Jan 2023 11:20:02 +0100
Message-Id: <82931557-3188a24755a7c83182882dc9296aa6e0@pmq6v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <jk_144@onet.pl>;89.64.64.219;PL;3
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Sat, 21 Jan 2023 15:09:30 +0000
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Jan 2023 10:20:15 -0000
This is the phrase that should be recalled very often:
"the total reward per transaction is Three Orders of Magnitude
higher than typical fees. Sufficient fee increases to bring back hashing po=
wer
in a scenario like that would cause Enormous Disruption to many things,
including Lightning channels"
> Your proposal does not address that problem as it can only measure diffic=
ulty prior to the halving point
Yes, my proposal of fixing the inevitable (but only spreaded over the long =
time) failure - is quite conservative, surprisingly.
Simplifying it to the edge case:
If in a four-year perspective there is no the average price +100% increase =
- to properly compensate last halving,
but instead there is a hashrate -50% drop - another possible and "proper" (=
!) compensation
- absolutely don't worse the situation by executing next halving,
accept such drop because there is nothing you can do about it
and wait with halvings for the hashrate to recover. As long as it takes.
Maybe even 20 years if necessary (fortunately we are at mature phase of ASI=
C technology right now),
And iterate.
This way we land at lowest possible annual inflation and set by a free mark=
et.
As I said this is quite conservative approach. It would suit bitcoin,.
Too bad it wasn't foreseen at the beginning...
W dniu 2023-01-18 21:58:15 u=C5=BCytkownik Peter Todd <pete@petertodd.org> =
napisa=C5=82:
> On Sun, Jan 01, 2023 at 11:42:50PM +1100, Alfie John wrote:
> On 31 Dec 2022, at 10:28 am, Peter Todd via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
> > =
> >> This way:
> >> =
> >> 1. system cannot be played
> >> 2. only in case of destructive halving: system waits for the recovery =
of network security
> > =
> > The immediate danger we have with halvings is that in a competitive mar=
ket,
> > profit margins tend towards marginal costs - the cost to produce an add=
itional
> > unit of production - rather than total costs - the cost necessary to re=
cover
> > prior and future expenses. Since the halving is a sudden shock to the s=
ystem,
> > under the right conditions we could have a significant amount of hashin=
g power
> > just barely able to afford to hash prior to the halving, resulting in a=
ll that
> > hashing power immediately having to shut down and fees increasing drama=
tically,
> > and likely, chaotically. Your proposal does not address that problem a=
s it can
> > only measure difficulty prior to the halving point.
> =
> =
> > ... Since the halving is a sudden shock to the system
> =
> Is it though? Since everyone knows of the possible outcomes, wouldn't a p=
ossible halving be priced in? =
Re-read that I said. That explains why despite the halving being a forseeab=
le
event, there's no mechanism to "price it in" when it comes to hashing power.
> > resulting in all that hashing power immediately having to shut down and=
fees increasing dramatically
> =
> Which should cause that hashing power to come back because of this fee in=
creases.
Right now the total reward per transaction is $63, three orders of magnitude
higher than typical fees. Sufficient fee increases to bring back hashing po=
wer
in a scenario like that would cause enormous disruption to many things,
including Lightning channels.
-- =
https://petertodd.org 'peter'[:-1]@petertodd.org
|
