path: root/07/2b8727b128561ccced016c698e515668d31d27

Return-Path: <bram@chia.net>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1D2E3C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 18:13:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E75CB40517
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 18:13:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E75CB40517
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=chia.net header.i=@chia.net
 header.a=rsa-sha256 header.s=google header.b=S5PYp30Y
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level: 
X-Spam-Status: No, score=0.601 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, 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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6CjSjM51anyZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 18:13:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org BFB8F4019B
Received: from mail-yw1-x112e.google.com (mail-yw1-x112e.google.com
 [IPv6:2607:f8b0:4864:20::112e])
 by smtp2.osuosl.org (Postfix) with ESMTPS id BFB8F4019B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 18:13:04 +0000 (UTC)
Received: by mail-yw1-x112e.google.com with SMTP id
 00721157ae682-31cf1adbf92so57762737b3.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 11:13:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
 h=mime-version:from:date:message-id:subject:to;
 bh=Rt8AEn0KyMdWd7IYxsbpZMgansLgxC7TSlzpKqFIvpg=;
 b=S5PYp30YtIuIwH/jHcdzQ2BWQm6m2tZnRWWuuIw5bVJT3MfJv7ZVwghCWUClcwHiPo
 jgWdo7xFimuWBRFA4HmSbQIi9Yka3Qoii5MlvRE391ReF2GJaYoH3I5GsfGsQT4me9yN
 gD2tOsrLqnaUSo2rOEpQx1bf9r3NAgpJsKlxW4Rcw/QrGSgnzctT1qoZfmv5/yqSnAL+
 Mi+kzzDz3bfR9zPjOgiFr1JtGgE/XHOkZa370pNb0Myq8yVZ+vLTD+T7j7c9ph0riIce
 4dgy0473gjaQBhydR9EAocCLOyojG5ncsjYZpF7Oayk1RaF0F6WZdFYco0GMMiZV9BO1
 j7lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=Rt8AEn0KyMdWd7IYxsbpZMgansLgxC7TSlzpKqFIvpg=;
 b=aPs1r7a0Pbnl8LSpLWgmEo63WmChF0jMXwYfYwKM8UkY9yoiKTqbwe9t8Quax0FJ/k
 vnRFytfQNSt0bdGJonJISW/TeaMr4ZWwGiQT4nQCmU1RStKmo2iWg9+GBycvXIqJeVya
 Y/g/AXUxHs1bEg3lmUDaCUdEtZ1lYyFJscZJsNFVc/hAjzvRDvNF4PAWnxQTfE570e3y
 pWfRfYUWj4aVpz0QAnPF9GDE7KI6604sxR79xZpaFej/0ze296X87EzJp5Z4aoAxwyGg
 M+VYnuNOWGNoFgE0UJNqz/YiCpjqQrEcpEgTdKBgqLHJnybWwHtauRaXArkSnAM9fMHW
 IU2w==
X-Gm-Message-State: AJIora83n3Wn2AQBjx2glx/6oKvBPGH04kwf3m6rLSQrTC5Pd9siC2aI
 IiKI8m+963qETVPenulYjeR5yAt+2etsGQRDmWqR18nW0QQ=
X-Google-Smtp-Source: AGRyM1sc76/14wVWge+3h2DxbGQxZHZ6v8MWTGwozrA6Cg8pVcmLvTDFfK6Ryosj3iH0fRPoEChcp7J2HZA3Yp7JMOQ=
X-Received: by 2002:a81:83c1:0:b0:31c:782f:7a42 with SMTP id
 t184-20020a8183c1000000b0031c782f7a42mr20742354ywf.399.1657563183391; Mon, 11
 Jul 2022 11:13:03 -0700 (PDT)
MIME-Version: 1.0
From: Bram Cohen <bram@chia.net>
Date: Mon, 11 Jul 2022 11:12:52 -0700
Message-ID: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bd3d3a05e38b80ef"
X-Mailman-Approved-At: Mon, 11 Jul 2022 18:19:35 +0000
Subject: [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:13:06 -0000

--000000000000bd3d3a05e38b80ef
Content-Type: text/plain; charset="UTF-8"

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.

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

<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 for security, acting similarly =
to fixed block rewards. Unfortunately that isn&#39;t how it works in the re=
al world. There&#39;s a very well established day/night cycle with fees goi=
ng to zero overnight and even longer gaps on weekends and holidays. If in t=
he future Bitcoin is entirely dependent on fees for security (scheduled ver=
y strongly) 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 is that at first there will simply be no or very few blocks mined ov=
ernight. There are likely to be some, as miners at first turn off their min=
ing rigs completely overnight then adopt the more sophisticated strategy of=
 waiting until there are enough fees in the mempool to warrant attempting t=
o make a block and only then doing it. Unfortunately the gaming doesn&#39;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) o=
f the day overnight and this will be profitable. That&#39;s likely to cause=
 the miners with more expensive operations to stop attempting mining the la=
st hour of the day preemptively.=C2=A0</div><div><br></div><div>What happen=
s after that I&#39;m not sure. There are a small enough number of miners wi=
th a quirky enough distribution of costs of operation and profitability tha=
t the dynamic is heavily dependent on those specifics, but the beginnings o=
f a slippery slope to a mining cabal which reorgs everyone else out of exis=
tence and eventually 51% attacks the whole thing have begun. It even gets w=
orse than that because once there&#39;s a cabal aggressively reorging anyon=
e else out when they make a block other miners will shut down and rapidly l=
ose the ability to quickly spin up again, so the threshold needed for that =
51% attack will keep going down.</div><div><br></div><div>In short, relying=
 completely on transaction fees for security is likely to be a disaster. Wh=
at we can say from existing experience is that having transaction fees be a=
bout 10% of rewards on average works well. It&#39;s enough to incentivize c=
ollecting 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 spike=
s getting too high.</div><div><br></div><div>There are a few possible appro=
aches 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&#39;s probably un=
realistic. Another would be to hard fork in fixed rewards in perpetuity, wh=
ich is slightly less unrealistic but still extremely problematic.=C2=A0</di=
v><div><br></div><div>Much more actionable are measures which smooth out fe=
es over time. Having wallets opportunistically collect their dust during ti=
mes of low transaction fees would help and would save users on fees. Also m=
aking UX which clarifies when things are likely to take a day or week but t=
hat it&#39;s reliable would be a reasonable thing to do, but users unfortun=
ately are very averse to transactions taking a while.</div></div>

--000000000000bd3d3a05e38b80ef--