From: micaroni@gmail.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 15:38:34 -0300 [thread overview]
Message-ID: <CAHvMVPTi5wLzNvW6z2F7aEcKd=Sqwqr39_W7rCQMbSN_hWApYQ@mail.gmail.com> (raw)
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3764 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 5213 bytes --]
next prev parent reply other threads:[~2022-07-11 18:39 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 18:12 [bitcoin-dev] Security problems with relying on transaction fees for security Bram Cohen
2022-07-11 18:38 ` micaroni [this message]
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
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='CAHvMVPTi5wLzNvW6z2F7aEcKd=Sqwqr39_W7rCQMbSN_hWApYQ@mail.gmail.com' \
--to=micaroni@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=bram@chia.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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