Re: [bitcoin-dev] Security problems with relying on transaction fees for security

From: Erik Aronesty <erik@q32•com>
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 14:43:27 -0400	[thread overview]
Message-ID: <CAJowKgLXU8fFduDu5=ZQt7j585weHN5Bj_Rqs3jnPbghzV474Q@mail.gmail.com> (raw)
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5322 bytes --]

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

We should carefully define "when" this becomes an issue.

Suppose the reward is 1.5625 BTC.   That's not very far away.   Assume you
need a 12-month investment in hardware.   One-year * 100% mining capacity
at that time is thus incentivised with 82125 bitcoin in losses against a
double spend.   If the price remains the same as it is now, that's 1.6
billion.  Is that a sufficient security budget?

As the rewards drop, the security of Bitcoin increasingly relies on "price
increases" and "fee pressure".  Obviously "price increases" isn't something
anyone should rely on.   Therefore the correct thing to address is "fee
pressure".

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

There is abundant evidence that modifying on-chain utility alters fees.
There is little doubt that the lightning network has cut into the security
budget.  Future privacy protocols, such as mweb, will cut in even further.

Therefore another solution would be to simply *increase on-chain utility*,
driving up fees in response to the growth of layered transactions.

Proposals like "payment codes" and protocols like "omni" and "omnibolt" all
use on-chain resources without needing a soft fork.   Other proposals, like
covenants, may increase fee pressure more.   And, of course, promoting the
use of Bitcoin & Lightning in transactions - not just "holding", helps
promote fee growth and helps maintain the security budget.

Even if it's less fixed and predictable than tail-emissions, this approach
seems to make much more sense.

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

[-- Attachment #2: Type: text/html, Size: 6176 bytes --]