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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id E0303C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 18:43:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id AAEBC60D73
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 18:43:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org AAEBC60D73
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=dsM7LtE0
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no 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 uQmmN_vT2XZG
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 18:43:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 381AB60F12
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com
[IPv6:2a00:1450:4864:20::12e])
by smtp3.osuosl.org (Postfix) with ESMTPS id 381AB60F12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 18:43:41 +0000 (UTC)
Received: by mail-lf1-x12e.google.com with SMTP id n18so8458107lfq.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 11:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=4+HkiOIzPkgOzXV+aZmiivmnuv3XFlAjzTN8//+3It8=;
b=dsM7LtE0lRBWoCUbDI8iDgckiEPq9P9/y3OnZWUqLPTxXqeadGPNwbVecEbx/64kxV
dfSOPveVu4zRjvUC76wh+gp2Zz8cWRKcwNzf8jkKx6yldsz9cMhvWeoNTD7C6mb5Py5t
MzDw6bVF1P4p8j8HfQ4ZbHJM6RqDZy0t9QH4Or5wJNAK/PNN87qrtha9e9uhVanjxk17
yEEMB0Rn/JvWiwsehxLmsrvMPWQEmMfTfLNNzNhiu70lTNnBYICihr5l4SuCPbkQgFQl
pF+ljVvapgW3vqZ0aN9pzuGs5qNk0PTBFwhCocMCrUo/e9LVAQP1ao2L8YgidccdHcGg
mrDg==
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=4+HkiOIzPkgOzXV+aZmiivmnuv3XFlAjzTN8//+3It8=;
b=xNOMiuJy3GFtNmulxS0D33B/fZU87QGxmhZE7u9PmdtAY7Bd2PGwBERXugqfzY9UFn
YxhVbVq2Hn0SqVZv9nS3tldgCfW8QRrMlNM51WRt4T7NNl86cDLCiROAAJ9ujOcI3ity
lcAJF9Q7MmnTW5bkNunnHpvvU1OngnzyFjR+H0uBX3Z6TYlgzxbAPzoswcC8DPL0Z50T
Qm/tXe7q74mRlAlAKQjXdA8V5dRBoeO9J2s3/s8Lrl+9ekfvvKGlTkNAGAFzsKLd6D8v
JbVGjXs7Wv+I6+xNhkaI7hw8kzoiIoievL4SCjjlwm8CJX73zWf9kKGOrXPJUIFf11II
DETg==
X-Gm-Message-State: AJIora8omovPuT1UXC8DWRm1pp93Fx2u/s2xi/SG9VbiWP7a1ej35orH
eNO0VR/h6mx4tHg1k7Xvj8XUeV3zD8rP5eU7HM+h1l+LR5ReuqE=
X-Google-Smtp-Source: AGRyM1svaMldsMHYVxyqVIJVnwkEEkQjNyN3/aIX41Lg0P3mMGSfW/1+V2ZdO/RIhApIvmem4Td8qWS8bQHdj3wiZjA=
X-Received: by 2002:a05:6512:308b:b0:489:32f8:426c with SMTP id
z11-20020a056512308b00b0048932f8426cmr13216968lfd.270.1657565018944; Mon, 11
Jul 2022 11:43:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 11 Jul 2022 14:43:27 -0400
Message-ID: <CAJowKgLXU8fFduDu5=ZQt7j585weHN5Bj_Rqs3jnPbghzV474Q@mail.gmail.com>
To: Bram Cohen <bram@chia.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002578d105e38beeed"
X-Mailman-Approved-At: Mon, 11 Jul 2022 23:05:26 +0000
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
fees for security
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: Mon, 11 Jul 2022 18:43:47 -0000
--0000000000002578d105e38beeed
Content-Type: text/plain; charset="UTF-8"
> If in the future Bitcoin is entirely dependent on fees for security
(scheduled very strongly) and this pattern keeps up (overwhelmingly likely)
then this is going to become a serious problem.
We should carefully define "when" this becomes an issue.
Suppose the reward is 1.5625 BTC. That's not very far away. Assume you
need a 12-month investment in hardware. One-year * 100% mining capacity
at that time is thus incentivised with 82125 bitcoin in losses against a
double spend. If the price remains the same as it is now, that's 1.6
billion. Is that a sufficient security budget?
As the rewards drop, the security of Bitcoin increasingly relies on "price
increases" and "fee pressure". Obviously "price increases" isn't something
anyone should rely on. Therefore the correct thing to address is "fee
pressure".
> There are a few possible approaches to fixes. One would be to drag most
of east asia eastward to a later time zone thus smoothing out the day/night
cycle but that's probably unrealistic. Another would be to hard fork in
fixed rewards in perpetuity...
There is abundant evidence that modifying on-chain utility alters fees.
There is little doubt that the lightning network has cut into the security
budget. Future privacy protocols, such as mweb, will cut in even further.
Therefore another solution would be to simply *increase on-chain utility*,
driving up fees in response to the growth of layered transactions.
Proposals like "payment codes" and protocols like "omni" and "omnibolt" all
use on-chain resources without needing a soft fork. Other proposals, like
covenants, may increase fee pressure more. And, of course, promoting the
use of Bitcoin & Lightning in transactions - not just "holding", helps
promote fee growth and helps maintain the security budget.
Even if it's less fixed and predictable than tail-emissions, this approach
seems to make much more sense.
On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If transaction fees came in at an even rate over time all at the exact
> same level then they work fine for security, acting similarly to fixed
> block rewards. Unfortunately that isn't how it works in the real world.
> There's a very well established day/night cycle with fees going to zero
> overnight and even longer gaps on weekends and holidays. If in the future
> Bitcoin is entirely dependent on fees for security (scheduled very
> strongly) and this pattern keeps up (overwhelmingly likely) then this is
> going to become a serious problem.
>
> What's likely to happen is that at first there will simply be no or very
> few blocks mined overnight. There are likely to be some, as miners at first
> turn off their mining rigs completely overnight then adopt the more
> sophisticated strategy of waiting until there are enough fees in the
> mempool to warrant attempting to make a block and only then doing it.
> Unfortunately the gaming doesn't end there. Eventually the miners with
> lower costs of operation will figure out that they can collectively reorg
> the last hour (or some time period) of the day overnight and this will be
> profitable. That's likely to cause the miners with more expensive
> operations to stop attempting mining the last hour of the day preemptively.
>
> What happens after that I'm not sure. There are a small enough number of
> miners with a quirky enough distribution of costs of operation and
> profitability that the dynamic is heavily dependent on those specifics, but
> the beginnings of a slippery slope to a mining cabal which reorgs everyone
> else out of existence and eventually 51% attacks the whole thing have
> begun. It even gets worse than that because once there's a cabal
> aggressively reorging anyone else out when they make a block other miners
> will shut down and rapidly lose the ability to quickly spin up again, so
> the threshold needed for that 51% attack will keep going down.
>
> In short, relying completely on transaction fees for security is likely to
> be a disaster. What we can say from existing experience is that having
> transaction fees be about 10% of rewards on average works well. It's enough
> to incentivize collecting fees but not so much that it makes incentives get
> all weird. 90% transaction fees is probably very bad. 50% works but runs
> the risk of spikes getting too high.
>
> There are a few possible approaches to fixes. One would be to drag most of
> east asia eastward to a later time zone thus smoothing out the day/night
> cycle but that's probably unrealistic. Another would be to hard fork in
> fixed rewards in perpetuity, which is slightly less unrealistic but still
> extremely problematic.
>
> Much more actionable are measures which smooth out fees over time. Having
> wallets opportunistically collect their dust during times of low
> transaction fees would help and would save users on fees. Also making UX
> which clarifies when things are likely to take a day or week but that it's
> reliable would be a reasonable thing to do, but users unfortunately are
> very averse to transactions taking a while.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000002578d105e38beeed
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> If in the future Bitcoin is entirely dependent on fee=
s for security (scheduled very strongly) and this pattern keeps up (overwhe=
lmingly likely) then this is going to become a serious problem.<div><br>We =
should carefully define "when" this becomes an issue.=C2=A0 =C2=
=A0=C2=A0<br><br>Suppose the reward is=C2=A01.5625 BTC.=C2=A0 =C2=A0That=
9;s not very far away.=C2=A0 =C2=A0Assume you need a 12-month investment in=
hardware.=C2=A0 =C2=A0One-year * 100% mining capacity at that time is thus=
incentivised with 82125 bitcoin in losses against a double spend.=C2=A0 =
=C2=A0If the price remains the same as it is now, that's 1.6 billion.=
=C2=A0 Is that a sufficient security budget?<br><br>As the rewards drop, th=
e security of Bitcoin increasingly relies on "price increases" an=
d "fee pressure".=C2=A0 Obviously "price increases" isn=
't something anyone should rely on.=C2=A0 =C2=A0Therefore the correct t=
hing to address is "fee pressure".</div><div><br><div>> There =
are a few possible approaches to fixes. One would be to drag most of east a=
sia eastward to a later time zone thus smoothing out the day/night cycle bu=
t that's probably unrealistic. Another would be to hard fork in fixed r=
ewards in perpetuity...</div><div><br>
There is abundant=C2=A0evidence that modifying on-chain utility alters fees=
.=C2=A0 There is little doubt that the lightning network has cut into the s=
ecurity budget.=C2=A0 Future privacy protocols, such as mweb, will cut in e=
ven further.=C2=A0 <br><br>Therefore another solution would be to simply *i=
ncrease on-chain utility*, driving up fees in response to the growth of lay=
ered transactions.=C2=A0 =C2=A0<br><br>Proposals like "payment codes&q=
uot; and protocols like "omni" and "omnibolt" all use o=
n-chain resources without needing a soft fork.=C2=A0 =C2=A0Other proposals,=
like covenants, may increase fee pressure more.=C2=A0 =C2=A0And, of course=
, promoting the use of Bitcoin & Lightning in transactions - not just &=
quot;holding", helps promote fee growth and helps maintain the securit=
y budget.<br></div><div><br>Even if it's less fixed and=C2=A0predictabl=
e than tail-emissions, this approach seems to make much more sense.<br></di=
v></div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitco=
in-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin=
-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr">If transaction fees came in =
at an even rate over time all at the exact same level then they work fine f=
or security, acting similarly to fixed block rewards. Unfortunately that is=
n't how it works in the real world. There's a very well established=
day/night cycle with fees going to zero overnight and even longer gaps on =
weekends and holidays. If in the future Bitcoin is entirely dependent on fe=
es for security (scheduled very strongly) and this pattern keeps up (overwh=
elmingly likely) then this is going to become a serious problem.<div><br></=
div><div>What's likely to happen is that at first there will simply be =
no or very few blocks mined overnight. There are likely to be some, as mine=
rs at first turn off their mining rigs completely overnight then adopt the =
more sophisticated strategy of waiting until there are enough fees in the m=
empool to warrant attempting to make a block and only then doing it. Unfort=
unately the gaming doesn't end there. Eventually the miners with lower =
costs of operation will figure out that they can collectively reorg the las=
t hour (or some time period) of the day overnight and this will be profitab=
le. That's likely to cause the miners with more expensive operations to=
stop attempting mining the last hour of the day preemptively.=C2=A0</div><=
div><br></div><div>What happens after that I'm not sure. There are a sm=
all enough number of miners with a quirky enough distribution of costs of o=
peration and profitability that the dynamic is heavily dependent on those s=
pecifics, but the beginnings of a slippery slope to a mining cabal which re=
orgs everyone else out of existence and eventually 51% attacks the whole th=
ing have begun. It even gets worse than that because once there's a cab=
al aggressively reorging anyone else out when they make a block other miner=
s will shut down and rapidly lose the ability to quickly spin up again, so =
the threshold needed for that 51% attack will keep going down.</div><div><b=
r></div><div>In short, relying completely on transaction fees for security =
is likely to be a disaster. What we can say from existing experience is tha=
t having transaction fees be about 10% of rewards on average works well. It=
's enough to incentivize collecting fees but not so much that it makes =
incentives get all weird. 90% transaction fees is probably very bad. 50% wo=
rks but runs the risk of spikes getting too high.</div><div><br></div><div>=
There are a few possible approaches to fixes. One would be to drag most of =
east asia eastward to a later time zone thus smoothing out the day/night cy=
cle but that's probably unrealistic. Another would be to hard fork in f=
ixed rewards in perpetuity, which is slightly less unrealistic but still ex=
tremely problematic.=C2=A0</div><div><br></div><div>Much more actionable ar=
e measures which smooth out fees over time. Having wallets opportunisticall=
y collect their dust during times of low transaction fees would help and wo=
uld save users on fees. Also making UX which clarifies when things are like=
ly to take a day or week but that it's reliable would be a reasonable t=
hing to do, but users unfortunately are very averse to transactions taking =
a while.</div></div>
_______________________________________________<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>
</blockquote></div>
--0000000000002578d105e38beeed--
|