From: vjudeu@gazeta•pl
To: "Bram Cohen <bram@chia•net>,
Bitcoin Protocol Discussion"
<bitcoin-dev@lists•linuxfoundation.org>,
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 21:45:39 +0200 [thread overview]
Message-ID: <165118572-15ce31cf3b31edf806ed76f11a104a90@pmq1v.m5r2.onet> (raw)
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
This problem can be solved by mining decentralization.
> What's likely to happen is that at first there will simply be no or very few blocks mined overnight.
Why? When it comes to energy usage, there are also cycles, because energy usage during the day is definitely higher than at night. You can clearly see that there are different prices for energy usage, and it depends if you use that energy overnight or not (usually, energy at night is cheaper, in the same way as other resources like Internet bandwidth limits, which are lower at night).
If less energy is used at night, then that energy is cheaper, and that means mining at night is more profitable.
> 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.
Again, that's the problem that should be solved by decentralized mining. Each reward of each miner should depend on all fees collected by that miner. It is easier to think about it if you assume zero basic block reward, where the whole coinbase transaction is based only on transaction fees. So, all that is needed, is to make it possible to get some transaction fees, related to mined transactions. So, it is far better to think about some kind of commit-and-reveal scheme, where each miner will independently mine a share of the block, and commit the block header on-chain. Then, it will be later possible to prove that such share was created at a given point in time, and to claim some reward (even off-chain), based on that proof.
> 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 would mean on-chain transaction fees are very low. And that would mean off-chain transaction fees are higher (because if that's not the case, then it would mean that people stopped making any transactions at all, on all monetary systems globally, including all altcoins, and all fiat currencies). So, that case is possible in a situation, where Lightning Network will handle the most of the traffic, and where there will be almost no need to touch on-chain coins, because all of them will fly inside other networks like LN, sidechains, or Merge-Mined altcoins.
> In short, relying completely on transaction fees for security is likely to be a disaster.
Note that if you want to rely on something else than fees, then you have three options: big blocks, tail supply, or Merged Mining. Big blocks were discussed heavily in the past, tail supply is discussed now, and Merged Mining is still not touched correctly (to get it right, it is needed to track the heaviest chain of Proof of Work headers, and to distribute a fractions of coins, based on that, not like NameCoin, where you have a separate difficulty, so you can 51% attack NameCoin, even if you don't have 51% on Bitcoin). So, why not Merged Mining? Or what else could it be? And if it will be tail supply, then why hard-fork is needed at all? Make it explicitly, take single satoshis from all UTXOs in existence, and make it crystal clear, what this proposal is about: it is about taking a tiny fractions of satoshis or even smaller amounts from all UTXOs to form the future block rewards, that's what it is truly about, and users should be aware of that.
> 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.
What is unrealistic? Trustless mining on someone's behalf and being rewarded for doing that in P2P way is unrealistic? It is perfectly possible to deploy any "I will pay you for increasing block reward for block 1000000" scheme. We have OP_CHECKLOCKTIMEVERIFY for that, anyone can do that, even non-mining users can send their own coins to the future block numbers to increase future rewards with their own coins.
> Another would be to hard fork in fixed rewards in perpetuity, which is slightly less unrealistic but still extremely problematic.
No hard-fork is needed. Moving coins to OP_CHECKLOCKTIMEVERIFY outputs is a no-fork. Enforcing that on consensus level to make block rewards more smooth is a soft-fork. Creating a Merge-Mined sidechain for that is a no-fork (because new coins are produced out of thin air, so Proof of Work alone, and tracking the main chain is enough, no new rules are needed on the main chain).
> Much more actionable are measures which smooth out fees over time.
What about RSK and their way of making fees more smooth?
On 2022-07-11 20:19:51 user 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.
next prev parent reply other threads:[~2022-07-11 19:45 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 [this message]
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=165118572-15ce31cf3b31edf806ed76f11a104a90@pmq1v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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