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: micaroni@gmail.com
Date: Mon, 11 Jul 2022 15:38:34 -0300
Message-ID: <CAHvMVPTi5wLzNvW6z2F7aEcKd=Sqwqr39_W7rCQMbSN_hWApYQ@mail.gmail.com>
To: Bram Cohen <bram@chia.net>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003f30ec05e38bde5f"
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
 fees for security
Precedence: list

--0000000000003f30ec05e38bde5f
Content-Type: text/plain; charset="UTF-8"

The expectation is that in a few years a space in the block will be very
competitive / expensive and be used only as a bridge for second layers or
big transactions. Who would have thought in 2017 that one day we would be
worried about cheap rates!

Anyway, it seems like a good point and I suggest giving this issue some
name for easy and later reference.


On Mon, Jul 11, 2022 at 3:20 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
>

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

<div dir=3D"ltr"><div><span class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span>The expec=
tation is that in a few years a space in the block will be very competitive=
 <span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">/</span> expensive<span class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)"> </span>and be used only as a bridge for second layers or=
 big transactions.<span class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"> Who would have thou=
ght in 2017 that one day we would be worried about cheap rates!</span></div=
><div><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)"><br></span></div><div><span clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)">Anyway, it seems like a good point and I suggest=
 giving this issue some name for easy and later reference.</span></div><div=
><span class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)"><br></span></div><div><br></div><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 11,=
 2022 at 3:20 PM Bram Cohen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</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"><div dir=
=3D"ltr">If transaction fees came in at an even rate over time all at the e=
xact same level then they work fine for security, acting similarly to fixed=
 block rewards. Unfortunately that isn&#39;t how it works in the real world=
. There&#39;s a very well established day/night cycle with fees going to ze=
ro overnight and even longer gaps on weekends and holidays. If in the futur=
e Bitcoin is entirely dependent on fees for security (scheduled very strong=
ly) and this pattern keeps up (overwhelmingly likely) then this is going to=
 become a serious problem.<div><br></div><div>What&#39;s likely to happen i=
s 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&#39;t end the=
re. Eventually the miners with lower costs of operation will figure out tha=
t they can collectively reorg the last hour (or some time period) of the da=
y overnight and this will be profitable. That&#39;s likely to cause the min=
ers 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&#39;m not sure. There are a small enough number of miners with a qui=
rky enough distribution of costs of operation and profitability that the dy=
namic is heavily dependent on those specifics, but the beginnings of a slip=
pery slope to a mining cabal which reorgs everyone else out of existence an=
d eventually 51% attacks the whole thing have begun. It even gets worse tha=
n that because once there&#39;s a cabal aggressively reorging anyone else o=
ut 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% atta=
ck will keep going down.</div><div><br></div><div>In short, relying complet=
ely on transaction fees for security is likely to be a disaster. What we ca=
n say from existing experience is that having transaction fees be about 10%=
 of rewards on average works well. It&#39;s enough to incentivize collectin=
g fees but not so much that it makes incentives get all weird. 90% transact=
ion fees is probably very bad. 50% works but runs the risk of spikes gettin=
g 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 zon=
e thus smoothing out the day/night cycle but that&#39;s probably unrealisti=
c. Another would be to hard fork in fixed rewards in perpetuity, which is s=
lightly less unrealistic but still extremely problematic.=C2=A0</div><div><=
br></div><div>Much more actionable are measures which smooth out fees over =
time. Having wallets opportunistically collect their dust during times of l=
ow 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&#=
39;s reliable would be a reasonable thing to do, but users unfortunately ar=
e 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></div>

--0000000000003f30ec05e38bde5f--