path: root/72/c1218fadaa6c93e566f879ce34df19486dbfbc

Return-Path: <user@petertodd.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4F138C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 21:53:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 1164F83F5C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 21:53:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1164F83F5C
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key, unprotected) header.d=petertodd.org
 header.i=@petertodd.org header.a=rsa-sha256 header.s=fm1 header.b=B8veyIMF; 
 dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm3 header.b=Yp7CwWfX
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.789
X-Spam-Level: 
X-Spam-Status: No, score=-2.789 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, LOTS_OF_MONEY=0.001,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 T_MONEY_PERCENT=0.01] 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 7-vDnSD1tMtq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 21:53:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org EB5DE83F56
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
 [66.111.4.28])
 by smtp1.osuosl.org (Postfix) with ESMTPS id EB5DE83F56
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 21:53:40 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.nyi.internal (Postfix) with ESMTP id E05665C0182;
 Mon, 11 Jul 2022 17:53:39 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute2.internal (MEProxy); Mon, 11 Jul 2022 17:53:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petertodd.org;
 h=cc:content-type:date:date:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:sender:subject
 :subject:to:to; s=fm1; t=1657576419; x=1657662819; bh=Z2ly0//J/J
 vBKBMOvOZybrVx47npsgAafYS/77liurg=; b=B8veyIMF6mHzvMYP2w8TpJ43uL
 PjmYL4b75RhQgjvS76Uc5ZAG45oh3rPlUt8/1EKXtcBgXdf7Im7Wh9/LXpcqa7Vq
 b70jeLgLeQtIcj/adpcd20x3UrErKRSJou0aczqjiFPyfMs8E40lIH+eenyjKhcz
 3Lmfm2pQUsHdYcOrWhg+mv8qCvKHVzeQuXJCQjDLX3D4G8y2Ia5oBdLkwISUyJeM
 sCQ1pDFdV/oGvbsTM2WsEjERZhpaCujT034fnZ9+Dv32hsQVjE1RvhnVkfaAOt6c
 Y51uIe0vI59Pm6NpTV3SLwPvork4GA2BOabzi3HDp/yvbb3a3UQoyu+WboVA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:date:feedback-id
 :feedback-id:from:from:in-reply-to:in-reply-to:message-id
 :mime-version:references:reply-to:sender:subject:subject:to:to
 :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm3; t=1657576419; x=1657662819; bh=Z2ly0//J/JvBKBMOvOZybrVx47np
 sgAafYS/77liurg=; b=Yp7CwWfXejFjN35Za6ymggd76cB2tcja1A8C7+9IYBKQ
 V2yF34DSpXpePWqSm36KGRPktgAvUEGimG9o0Kz5bGBSNhSXFuYuQe1yvv4r1Ph8
 UA++y/N9aaRtBqlH4W4yy5OuDEy/MEBqCJNveu+5FpU/K1iTjp4x1AUcXPO5aPlY
 E4fu9tW0lOIu06RgABiAYTQ8wmFjr9wX6Ft+yEQLIq8CTNHQyFWrY4YRE4tweQdm
 VgHiT9P9pSstnFEleWdA9GLAUxrOhpiAmC1wJ6wsYmAT3YGYsxJj1u5FYlTPTM1n
 zfaY4ostiTxw2U26e0YAkB2LlyvSuG7dAw7BfvHU4A==
X-ME-Sender: <xms:45vMYoBiduFyZE80xzSRusQDAWVzt85TgR4BzPyWTGzQl9WwttpPLg>
 <xme:45vMYqgM3XGqPNAlF86iFIGGvhGf-vYR971gVe1Sgw8naUlLupBdHGgqL_nCdplP7
 Wvk4K9kgJMS_W-wEr8>
X-ME-Received: <xmr:45vMYrmrvWbJcF_6MWNvdd884pPW4qUWQKb68rSL9Gi39Q4Q9LrL09QhwMROhtSSwpExRA7XbMUom0_bdFyGnT2iAoqV7MOz>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejgedgtdegucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepfffhvffukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr
 ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg
 hrnhepiedvvdelieekjeeukefgtdelfeegheehleffueehteeghfelveejfeelgeevffef
 necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg
 eptdenucfrrghrrghmpehmrghilhhfrhhomhepuhhsvghrsehpvghtvghrthhouggurdho
 rhhg
X-ME-Proxy: <xmx:45vMYuy_eShXV_rP23tPulGHfkyWQj4Sp_ATW3zs6EI6DEqwUaNdlw>
 <xmx:45vMYtSDGHABUBVtGwPNCcHimFReUPImwmwX9-3OjfCh9d9q2W4nng>
 <xmx:45vMYpY1N6HK-HCZZ3W4cAVpobanL6AHwTCk2fx_V8w6b05uAVPlPg>
 <xmx:45vMYu4mJe3GkA0ouCWgNs1pAkb0vvr33eTESpC53J7iAwAOaZPZhA>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 11 Jul 2022 17:53:39 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
 id 1BBB35F7C1; Mon, 11 Jul 2022 17:53:37 -0400 (EDT)
Date: Mon, 11 Jul 2022 17:53:37 -0400
From: Peter Todd <pete@petertodd.org>
To: Bram Cohen <bram@chia.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Ysyb4T/36oXeAH+z@petertodd.org>
References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="eqlpffpinTU5x1UZ"
Content-Disposition: inline
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
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 21:53:42 -0000


--eqlpffpinTU5x1UZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev wrote:
> If transaction fees came in at an even rate over time all at the exact sa=
me
> 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 a=
nd
> 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.
>=20
> 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 fir=
st
> 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 preemptivel=
y.
>=20
> 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, b=
ut
> 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.
>=20
> 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 enou=
gh
> to incentivize collecting fees but not so much that it makes incentives g=
et
> all weird. 90% transaction fees is probably very bad. 50% works but runs
> the risk of spikes getting too high.
>=20
> 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.
>=20
> Much more actionable are measures which smooth out fees over time.

Note that a tricky thing here is that smoothing out fees is made difficult =
by
the fact that users can by-pass the fee system by including anyone-can-spend
outputs in their transactions. Or worse, by simply paying large miners
out-of-band to get their txs confirmed. So any smothing scheme that tries to
smooth the market-based fees we already have will fail.

The only type of fee-smoothing scheme that is feasible is to smooth an enti=
rely
separate category of fees that are made mandatory. For example, you could
achieve the economic impact of inflation by having a fixed value*time based=
 fee
that goes to timelocked anyone-can-spend outputs in the coinbase to push the
fee forward to other miners.

Doing this is of course a gigantic accounting headache, and problematic for
existing L2 protocols, because you are reducing the value of txouts as they=
 age
(demurrage). But at least it's a soft-fork.

Interestingly, if you look at transaction fees in blocks right now, people
regularly pay far higher transaction fees than necessary. There seem to be a
bunch of high value users, eg $1 million txs, without terrible fee estimati=
on.
And I suspect the reason why this happens is simply that for a $1 million t=
x,
overpaying 100x with a $100 tx fee is irrelevant. Of course, this is also a
problem from the re-org point of view...

> Having
> wallets opportunistically collect their dust during times of low
> transaction fees would help and would save users on fees.

You're assuming wallets will even have dust to collect. With widespread use=
 of
Lightning that will likely not be true. Indeed, with sufficiently efficient=
 L2
solutions it's really unclear as to how much demand there will be for block
space.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--eqlpffpinTU5x1UZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmLMm94ACgkQLly11TVR
LzdbCRAAqqVksSkLJNycAb9/nbVLx7vjVv+zhd7txqiQp+urPQirQrx9NtDCEI8t
51x/XuVKXQvdN+uaIVcDB6jhK+3bFklSKB5Bv2a28czyJvaiynqkiZTGnZh2mULW
jA4veGrrplVA97QDxWalp2C6S1EO4HFYDEgHXFDm86/TjZHxf1aLaxFl+zr+9pe9
SXxeA42kCARSefcd+347Z5hAKg60+6kn7GZP4x/5SO7e+TjANddpzGdVw4j5ILbZ
RwaIn9JD8IKQA+A5OiP8pBKQ0jnJcQyfYI5dtUiPPZ1PSo/nMU1rCxsgDlV3cbUg
WSgePWIHNFL9L/Ua1KR3+hfwuUMOUH8/T7E4aSGQ8YGQRcwrlaIlTF7w9CdHjEAH
OLHEh9PW3efun8UmFcAqccsuB8bf8HRKWr/sAYeY5GsNaR5jIAY6MuUuS2lALyBW
gsZaMwgzMoxVHerQBGSWgDEPALU2l/ci1yD1Ei7UvGbcdyLcE8pHHPXSOUDjpQ81
z6/PyzIQLGfPozciU/U+5T6ZVKgkhqaDHimCwcvzm03KuROeYIjMyHCaYZmkmXlR
WzZlx6VMsP9Ial08UXNalPIglRhUI/B4bWZSvzXl25XbOueqFTGnxU5QB2dWinaV
Q8bZiPXYShiPeRH1K0rNc8bRgTWmfCTKSh/Htw1iXQZuJKeioE4=
=Ehd6
-----END PGP SIGNATURE-----

--eqlpffpinTU5x1UZ--