path: root/4e/69d2ca40662df51c44bac27c9738918b323137

Return-Path: <keatonatron@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 251AFC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 22:19:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id ED11341A0F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 22:19:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org ED11341A0F
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=eHzlL/6K
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JtkhC52TG7Jv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 22:19:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3051D419FF
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com
 [IPv6:2607:f8b0:4864:20::630])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 3051D419FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 22:19:34 +0000 (UTC)
Received: by mail-pl1-x630.google.com with SMTP id d5so5622160plo.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 11 Jul 2022 15:19:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=vvZbpkAvpN6tovmrHyzZmYV3jXhXq2+wdnA3ySWBlq0=;
 b=eHzlL/6KnuPYWZ/VKPMi9Ko4HRDW4A1rhaThrD4eKDd7VFpr/tAQ2sHtDfqvi5RJeb
 fe1xJF7A6lOYn+6jHT+y7ulIohOawX3WAq0KSPRycx6YsFEFMTum3iVuIBbJithrPBFE
 0lteMBRDAllsg1paGjIdhUlNHsMLudn+zC9t8jXUFi4vqGdvSzOLyRLbRUkUbqbclQt4
 huBWEi9IVp7AKF3yYgBRlGUba/y5Db2RodcW6lllnh9+4TKOeyoCFhFbMokoZGFtkFuK
 eCtlEWNRkbP6ftlFplKZU9DDRX3fS6RNwcS+3NuQBtDGLsMnisJ8boL31sLf1SQx0Go5
 89vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=vvZbpkAvpN6tovmrHyzZmYV3jXhXq2+wdnA3ySWBlq0=;
 b=AGxth11EgU+tM771UeVxgFe86QxH0+tLWGncQ3oFQc3e+T5XP7djpJFxiMp1FCEPPp
 c4LW+5O4nCH6tjfTlLod2nvzyHxiOiEag4gBNmi5SEPyJVMBlq9El/khGBwHL+K+LmzL
 a3CYsG6OSZiHMGBuOMz+8nQK+vcqWCRuSfFVa1D58wExIvYPg9GWGAS2AfeoiniJiGvu
 V7ydyfTt/710rxj3WpCR/SlOB+f7BWKYixPdXIHC++b5OCUBYadzIE+fv4HJhjqgTtRS
 ovJM2Kgtqf3SLTTdKzcf5F3ZRFDuDBIKKivdcebOf6PhVjxoxK67lWgf+Kmf58pusZlf
 Nk9A==
X-Gm-Message-State: AJIora8oUSuG8esIlMl4+nK/uRLv6YXvObLd2x/yk1JDnv36KYN+cGnD
 dSXBGFBwaj/avBd/fIXGGwUryYn1hWcYorsJCcMXZUtixEQ=
X-Google-Smtp-Source: AGRyM1tGr3AHExhEYY8qcVdtgtk7QG+NTDQFUT8vPPnqVUQx2b/av7ldqPMdrC9SpzT8NK2tGkfSliG5N6NbDiVjJcc=
X-Received: by 2002:a17:902:ec8a:b0:16c:4baa:a50c with SMTP id
 x10-20020a170902ec8a00b0016c4baaa50cmr7254701plg.62.1657577973344; Mon, 11
 Jul 2022 15:19:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Tue, 12 Jul 2022 00:19:06 +0200
Message-ID: <CAH+Axy6h5r5SqPz8u_Lsj8hm91rtui63k4a6pV1Cp_nONZ2S9A@mail.gmail.com>
To: Bram Cohen <bram@chia.net>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000049f16905e38ef247"
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 22:19:36 -0000

--00000000000049f16905e38ef247
Content-Type: text/plain; charset="UTF-8"

I think many of these discussions about the loss of the mining reward are
fatally shortsighted.

It's always daytime somewhere--when you talk about volume dropping at
night, that simply means there is not enough activity outside the US. If
Bitcoin continues its rise in price, mining rewards will still be
substantial for decades to come. Given another 10 years, I'm fairly
confident there will be enough adoption worldwide to make mining profitable
around the clock, even if the mining reward were minimal.

James


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

--00000000000049f16905e38ef247
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think many of these discussions about the loss of the mi=
ning reward are fatally shortsighted.<br><br>It&#39;s always daytime somewh=
ere--when you talk about volume dropping at night, that simply means there =
is not enough activity outside the US. If Bitcoin continues its rise in pri=
ce, mining rewards will still be substantial for decades to come. Given ano=
ther 10 years, I&#39;m fairly confident there will be enough adoption world=
wide to make mining profitable around the clock, even if the mining reward =
were minimal.<div><div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gma=
il_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Jame=
s<br></div></div></div></div><br></div></div></div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 11, 2022 at 8:19 P=
M Bram Cohen via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">If tra=
nsaction 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&#39;t how it works in the real world. There&#39;s a=
 very well established day/night cycle with fees going to zero overnight an=
d even longer gaps on weekends and holidays. If in the future Bitcoin is en=
tirely dependent on fees for security (scheduled very strongly) and this pa=
ttern keeps up (overwhelmingly likely) then this is going to become a serio=
us problem.<div><br></div><div>What&#39;s likely to happen is that at first=
 there will simply be no or very few blocks mined overnight. There are like=
ly to be some, as miners at first turn off their mining rigs completely ove=
rnight then adopt the more sophisticated strategy of waiting until there ar=
e enough fees in the mempool to warrant attempting to make a block and only=
 then doing it. Unfortunately the gaming doesn&#39;t end there. Eventually =
the miners with lower costs of operation will figure out that they can coll=
ectively reorg the last hour (or some time period) of the day overnight and=
 this will be profitable. That&#39;s likely to cause the miners with more e=
xpensive operations to stop attempting mining the last hour of the day pree=
mptively.=C2=A0</div><div><br></div><div>What happens after that I&#39;m no=
t sure. There are a small enough number of miners with a quirky enough dist=
ribution of costs of operation and profitability that the dynamic is heavil=
y 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&#39;s a cabal aggressively reorging anyone else out when they ma=
ke a block other miners will shut down and rapidly lose the ability to quic=
kly spin up again, so the threshold needed for that 51% attack will keep go=
ing down.</div><div><br></div><div>In short, relying completely on transact=
ion fees for security is likely to be a disaster. What we can say from exis=
ting experience is that having transaction fees be about 10% of rewards on =
average works well. It&#39;s enough to incentivize collecting fees but not =
so much that it makes incentives get all weird. 90% transaction fees is pro=
bably very bad. 50% works but runs the risk of spikes getting too high.</di=
v><div><br></div><div>There are a few possible approaches to fixes. One wou=
ld be to drag most of east asia eastward to a later time zone thus smoothin=
g out the day/night cycle but that&#39;s probably unrealistic. Another woul=
d be to hard fork in fixed rewards in perpetuity, which is slightly less un=
realistic but still extremely problematic.=C2=A0</div><div><br></div><div>M=
uch more actionable are measures which smooth out fees over time. Having wa=
llets opportunistically collect their dust during times of low transaction =
fees would help and would save users on fees. Also making UX which clarifie=
s when things are likely to take a day or week but that it&#39;s reliable w=
ould be a reasonable thing to do, but users unfortunately are very averse t=
o transactions taking a while.</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000049f16905e38ef247--