From: Peter Todd <pete@petertodd•org>
To: Bram Cohen <bram@chia•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction fees for security
Date: Mon, 11 Jul 2022 17:53:37 -0400 [thread overview]
Message-ID: <Ysyb4T/36oXeAH+z@petertodd.org> (raw)
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4691 bytes --]
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 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.
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 entirely
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 estimation.
And I suspect the reason why this happens is simply that for a $1 million tx,
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-07-11 21:53 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 18:12 Bram Cohen
2022-07-11 18:38 ` micaroni
2022-07-11 18:43 ` Erik Aronesty
2022-07-11 19:45 ` vjudeu
2022-07-11 20:35 ` Russell O'Connor
2022-07-11 20:52 ` Erik Aronesty
2022-07-11 21:36 ` Peter Todd
2022-07-11 21:56 ` Peter Todd
2022-07-12 0:21 ` Russell O'Connor
2022-07-12 0:37 ` Peter Todd
2022-07-14 0:54 ` Anthony Towns
2022-07-11 21:18 ` Pox
2022-07-11 21:53 ` Peter Todd [this message]
2022-07-12 2:47 ` Bram Cohen
2022-07-11 22:19 ` James MacWhyte
2022-07-11 22:26 ` Peter Todd
2022-07-12 0:01 ` James MacWhyte
2022-07-12 0:31 ` Peter Todd
2022-07-13 0:38 ` Tom Harding
2022-07-13 12:18 ` Erik Aronesty
2022-07-11 23:29 ` Anthony Towns
2022-07-12 3:56 Peter
2022-07-12 11:57 ` Erik Aronesty
2022-07-12 15:08 ` Peter
2022-07-12 17:46 ` Ryan Grant
[not found] <mailman.82083.1657699581.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-07-13 9:43 ` John Tromp
2022-07-13 11:56 ` John Tromp
2022-07-13 12:11 ` Gino Pinuto
2022-07-13 13:29 ` Manuel Costa
2022-07-14 9:33 ` vjudeu
2022-07-14 9:57 ` Erik Aronesty
2022-07-14 11:42 ` Gino Pinuto
2022-07-14 16:01 ` Erik Aronesty
2022-07-14 16:27 ` Manuel Costa
2022-07-15 6:03 ` vjudeu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ysyb4T/36oXeAH+z@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bram@chia$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox