path: root/8f/55f470dc7e1ffed1a77aed44ece54e8f42a3f2

Return-Path: <micaroni3@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 02CD9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 18:39:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id C24C4826AA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 18:39:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C24C4826AA
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=JorIdWoA
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.852
X-Spam-Level: 
X-Spam-Status: No, score=0.852 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 65WBLOns7MNw
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 18:39:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6E7EA82640
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com
 [IPv6:2a00:1450:4864:20::22e])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 6E7EA82640
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 18:39:14 +0000 (UTC)
Received: by mail-lj1-x22e.google.com with SMTP id o12so4646781ljc.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 11:39:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=6CA0tH1ajRBIXnhF/lo5BaszZiUowby4BC79IVH3VOs=;
 b=JorIdWoAwdMopSUrTj3IwtDwWsyiEm2N87fiVGmOaqCPvT67cWgaOc/gAC14DSwhEI
 ro6e/VgvC96S2bcQUJnQXBOPFdLhLtSCs5kxxfqh4pBY3tARR01owLktmJgJ2KiloQ3E
 pDV29VQL1ArKJQkyvHIv/dDABD9MMCBPF4Z2QaaZa9OqKaSL7p7DjZs5egLzzdPPWIKo
 V5yJP/9E0TXydF/xS/Zzq4T1IpUPr2A/Vm1tyEmnFz/8JkRaf7mx8gYqh8fhasf+hahH
 fWsWF+ZCQ0DLclm+R2dZb7Lq/WTEUAUpS6xpUuQD60E0nXj4o2o/8Pg1p+DeuVVQ0G+X
 YVvw==
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=6CA0tH1ajRBIXnhF/lo5BaszZiUowby4BC79IVH3VOs=;
 b=AEEBxwJdcZ4WYfw1gRJ0BQl4qbpN/6TvLZZ3D1b7d3QGLbAvOsQAH9pIuTPvsByHp5
 hu1tlwVe87n3ZIqxecZEG/9D8oIPFSHcSVZObBOfd9loqew4vucUxRbVdXLyKy4vzR7Q
 nJ2aeJC3GwoZM5AwUXHW0VpI+u9IZIQy3mANauso+z5VWqfp2rVSatgMR0tROkMcwYSn
 sfiWBS5ETQ8xj8CSkb+GFKm2k92XYaFW0pDDnAS3lU5aXwnbDAlr6bYjJzwoJAs8rcIU
 25qKSV/sQbtMJZFFUngNKuBtMvsKeQJmPnbrFozVLDAkLKFpT3bu68au75YxT41OTJCU
 oj5w==
X-Gm-Message-State: AJIora8ZfrQE9kYop57Hi1SNBf4kg45ubXVUernzAILqx6NF44MQ7Xhp
 fSccFz07GeyOeMMHgBq1hoJcT9ZBd3ZUT6NQLAs=
X-Google-Smtp-Source: AGRyM1tsx7CkpW9lfFC72wD42/2b3QeBGQQKN16y6Tcia+cblCjvfwgZBC31MjPBrNgk1pWLjDCPO/zuL9m64ZG7SMo=
X-Received: by 2002:a05:651c:211f:b0:25a:86c4:bfe4 with SMTP id
 a31-20020a05651c211f00b0025a86c4bfe4mr11042100ljq.531.1657564752193; Mon, 11
 Jul 2022 11:39:12 -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: 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"
X-Mailman-Approved-At: Mon, 11 Jul 2022 23:06:55 +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:39:19 -0000

--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--