Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
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>
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
Date: Mon, 11 Jul 2022 21:45:39 +0200
Message-Id: <165118572-15ce31cf3b31edf806ed76f11a104a90@pmq1v.m5r2.onet>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
 fees for security
Precedence: list

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 u=
sage 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 us=
e that energy overnight or not (usually, energy at night is cheaper, in the=
 same way as other resources like Internet bandwidth limits, which are lowe=
r at night).

If less energy is used at night, then that energy is cheaper, and that mean=
s mining at night is more profitable.

> There are likely to be some, as miners at first turn off their mining rig=
s completely overnight then adopt the more sophisticated strategy of waitin=
g 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. Ea=
ch 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, relate=
d to mined transactions. So, it is far better to think about some kind of c=
ommit-and-reveal scheme, where each miner will independently mine a share o=
f the block, and commit the block header on-chain. Then, it will be later p=
ossible 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, the=
n 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 ha=
ndle the most of the traffic, and where there will be almost no need to tou=
ch 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 t=
o be a disaster.

Note that if you want to rely on something else than fees, then you have th=
ree options: big blocks, tail supply, or Merged Mining. Big blocks were dis=
cussed 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 difficul=
ty, 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 tai=
l supply, then why hard-fork is needed at all? Make it explicitly, take sin=
gle satoshis from all UTXOs in existence, and make it crystal clear, what t=
his proposal is about: it is about taking a tiny fractions of satoshis or e=
ven 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 rewarde=
d for doing that in P2P way is unrealistic? It is perfectly possible to dep=
loy any "I will pay you for increasing block reward for block 1000000" sche=
me. We have OP_CHECKLOCKTIMEVERIFY for that, anyone can do that, even non-m=
ining users can send their own coins to the future block numbers to increas=
e future rewards with their own coins.

> Another would be to hard fork in fixed rewards in perpetuity, which is sl=
ightly 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 smoo=
th 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 cha=
in).

> 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.l=
inuxfoundation.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 re=
wards. Unfortunately that isn't how it works in the real world. There's a v=
ery 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 enti=
rely dependent on fees for security (scheduled very strongly) and this patt=
ern 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 fe=
w blocks mined overnight. There are likely to be some, as miners at first t=
urn off their mining rigs completely overnight then adopt the more sophisti=
cated strategy of waiting until there are enough fees in the mempool to war=
rant attempting to make a block and only then doing it. Unfortunately the g=
aming doesn't end there. Eventually the miners with lower costs of operatio=
n will figure out that they can collectively reorg the last hour (or some t=
ime period) of the day overnight and this will be profitable. That's likely=
 to cause the miners with more expensive operations to stop attempting mini=
ng the last hour of the day preemptively.=C2=A0


What happens after that I'm not sure. There are a small enough number of mi=
ners with a quirky enough distribution of costs of operation and profitabil=
ity that the dynamic is heavily dependent on those specifics, but the begin=
nings 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 an=
yone else out when they make a block other miners will shut down and rapidl=
y lose the ability to quickly spin up again, so the threshold needed for th=
at 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 tran=
saction 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 al=
l 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 cy=
cle but that's probably unrealistic. Another would be to hard fork in fixed=
 rewards in perpetuity, which is slightly less unrealistic but still extrem=
ely problematic.=C2=A0


Much more actionable are measures which smooth out fees over time. Having w=
allets opportunistically collect their dust during times of low transaction=
 fees would help and would save users on fees. Also making UX which clarifi=
es when things are likely to take a day or week but that it's reliable woul=
d be a reasonable thing to do, but users unfortunately are very averse to t=
ransactions taking a while.