path: root/48/4dcc9fedf9ae0e444d5463f006aef1d21ffd8c

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 24336C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 19:45:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id EB45660FE7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 19:45:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EB45660FE7
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
 header.a=rsa-sha256 header.s=2013 header.b=J5M6wJoE
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id oXbvXDp6KAHR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 19:45:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 39E4F60FDE
Received: from smtpo39.poczta.onet.pl (smtpo39.poczta.onet.pl
 [213.180.142.170])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 39E4F60FDE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 19:45:48 +0000 (UTC)
Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4LhZ9w4FrtzgcF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 21:45:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1657568740; bh=UnwI8CBdkBtzK7lKWNxi5jHpGIrTy6iEpqTAqF+ddl8=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=J5M6wJoEULjbHjPVYOIZdfzT5c1zRkLwYRImfTjf38WkGMNzRX9utXSr2KXYGuCp2
 0lh/NSx9tY/gcaUIzOJzgRXqa1lszgntw16uKIL7TjXBI7zIBOIoW9ga8p5jqueRBq
 t1k3dcCCg/qiYtguaTxzNxJ6bUkIczxQE2LD9/yU=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.240.219] by pmq1v.m5r2.onet via HTTP id ;
 Mon, 11 Jul 2022 21:45:40 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
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>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.240.219;PL;1
X-Mailman-Approved-At: Mon, 11 Jul 2022 23:05:26 +0000
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
 fees for security
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2022 19:45:51 -0000

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.