path: root/7e/57f5dbe046ed7a1bcf795794f817556a63c3f4

Return-Path: <anton@etcm.ltd>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C6FE6C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 May 2021 12:39:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id B675183252
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 May 2021 12:39:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Level: 
X-Spam-Status: No, score=0.149 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=etc-group.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id U8aIrfmgBGvL
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 May 2021 12:39:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com
 [IPv6:2a00:1450:4864:20::336])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 0549F8316A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 May 2021 12:39:22 +0000 (UTC)
Received: by mail-wm1-x336.google.com with SMTP id 62so2467674wmb.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 May 2021 05:39:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=etc-group.com; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=OYYaHz6MypSuftNIamFXm4FkUo/nTAJcH9da/sjE5Yk=;
 b=BMwGQXZgITR2Hehi/7JsYeCWDLl6iGrqqpOY4VVwfv40wBAxjlIKttUsQhF8bjjnrg
 CD4vZQWM/9fvuAkL6WHX2kQgtcKH0TjdAO1/UuMENX55Ne52fubrJHkXzLkmsYGKdlY+
 pRcQJ3YscBXi2Vz7Z5Jad4S6HvWsM8dZvMrCJDbvNjtpgOIi8ogTeZAn22puMz3mTf/U
 I9S1Rfdpg7YnMw2v5BSGwwklRs4hvn+wCfKrJaB7m63HvPaigPaURjT6HejIMT9cDaQ3
 ULfd9i/SKRcIZ9N0+w6DnMK8ZFhYdhyQma4AsuEqUfvXLD7lfY5NeO3yWqZJ+mEI1wNF
 liiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=OYYaHz6MypSuftNIamFXm4FkUo/nTAJcH9da/sjE5Yk=;
 b=OnvaIx/UqANHE/mJEN47EZ0XPkPysL0YrCvKy6DDQr6JJKPomYIHcNxZRDoAui5cIj
 fB8InhyOMNz/a3FNMTGqpEnDJPlLs8n+H6gvhdtMaDOU/R5gMJ8xKgU0Ibjs4xu7eSbS
 xtkudMxxIqV2CckAwuv29w00LbuPU1k751Tx2TvhO455iwH53XNjL0amG2G41KTTjEP+
 sptuEHkW1RFXzBu9NRqUa9+XSyfzz1EwJgpKVfY1d5RwlvGbItBSvif+gNJiX+cOm6es
 I7bOtFSexvtNe+UMOb65awiP4Sln25eR14DdHv+okaCuuElwi7AYGr4odYVVhO9szZZe
 eivw==
X-Gm-Message-State: AOAM53038wW0qNumHhWv3mD4m2KLgtfN52RyQMRKGKKFgQjz9Gtr7Z2B
 sFEnA+uVIZXguNshvK8bpJcdCKuqyuGFJu8o21FF6w==
X-Google-Smtp-Source: ABdhPJzWKQb156lAvoJNxh3N6CEu2yWoVDSHo6zNb+7Pp0BD2RSg05QS/bToCDpfPi2RP4RtDR5GbtlKqfJLjx+8mTY=
X-Received: by 2002:a1c:38c4:: with SMTP id
 f187mr23150343wma.144.1621255160935; 
 Mon, 17 May 2021 05:39:20 -0700 (PDT)
MIME-Version: 1.0
References: <d35dee03-2d19-e80a-c577-2151938f9203@web.de>
 <202105170258.13233.luke@dashjr.org>
In-Reply-To: <202105170258.13233.luke@dashjr.org>
From: Anton Ragin <anton@etc-group.com>
Date: Mon, 17 May 2021 13:39:02 +0100
Message-ID: <CAPyV_jDsScGQo4_DB8y7-4ZFGyEqM_Sk3YUUteK6HwPRuxOAvQ@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="000000000000f546c605c285e1f6"
X-Mailman-Approved-At: Mon, 17 May 2021 12:44:49 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes
 to save 90% of mining energy
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, 17 May 2021 12:39:24 -0000

--000000000000f546c605c285e1f6
Content-Type: text/plain; charset="UTF-8"

>> 2. I am not a huge data-center specialist, but it was my understanding
that they charge per unit of installed (maximum) electricity consumption.
It would mean that if the miner needs X kilowatts-hour within that 1 minute
when they are allowed to mine, he/she will have to pay for the same X for
the remaining 9 minutes - and as such would have no economic incentive not
to draw that power when idling.

>That sounds kind of exotic, could you take charge of checking to see
>how true it is?

I am pretty sure that is how it works in data centers absent 'special
deal', as we use some DCs in our business. However, after reading some
discussion on this thread it is pretty clear that some (maybe even
majority?) of miners have some sort of special deal on electricity - some
use 'spill over' electricity which would otherwise be wasted etc. This kind
of disproves my point, but not entirely - even 'special deal' electricity
is very unlikely to be available like water in the tap - you open it when
you need it, and pay for what you use only.

Variations in power consumption in the grid are very difficult to
compensate for:

(a) there is no efficient way to store electricity;
(b) some (majority?) power-generating assets are notoriously difficult to
throttle up and down - it takes almost a day in some cases to throttle down
power production on the nuclear power plant for example.

(did you know that sometimes the spot price for electricity goes below
zero, and consumers are being paid to consume - exactly because it is
cheaper to pay somebody to consume electricity than to switch off the
reactor?)

Because of this, an enormous spike in energy consumption every 1 minute in
10 is the worst possible load profile to any power grid, and would most
likely result in either miners or power grid infrastructure itself just
burning off peak energy during the 9 minutes 'cool-down' period.

>> 4. My counter-proposal to the community to address energy consumption
>> problems would be *to encourage users to allow only 'green miners'
process
>> their transaction.* In particular:
>>...
>> (b) Should there be some non-profit organization(s) certifying green
miners
>> and giving them cryptographic certificates of conformity (either usage of
>> green energy or purchase of offsets), users could encrypt their
>> transactions and submit to mempool in such a format that *only green
miners
>> would be able to decrypt and process them*.

>Hello centralisation. Might as well just have someone sign miner keys, and
get
>rid of PoW entirely...
>No, it is not centralization -

No, it is not centralization, as:

(a) different miners could use different standards / certifications for
'green' status, there are many already;
(b) it does not affect stability of the network in a material way, rather
creates small (12.5% of revenue max) incentive to move to green sources of
energy (or buy carbon credits) and get certified - miners who would choose
to run dirty energy will still be able to do so.
and
(c) nothing is being proposed beyond what is already possible - Antpool can
go green today, and solicit users to send them signed transactions directly
instead of adding them to a public mempool, under the pretext that it would
make the transfer 'greener'. What is being proposed is some community
effort to standardize & promote this approach, because if we manage to make
Bitcoin green(er) - we will remove what many commentators see as the last
barrier / biggest risk to even wider Bitcoin adoption.

Not to mention the fact that some aspects of the Bitcoin community are
pretty centralized already - 'www.bitcoin.org', GitHub repo, certain global
internet cables / protocols / providers. Centralization is evil only when
it enables (or makes significantly easier) a threatening attack on the
network, which does not appear to be the case. It is my personal opinion
only, though, I would respect it if someone disagrees.

On a separate note, I just want to draw everyone's attention to the fact
that - assuming if my calculations are correct - carbon credits to offset
dirty energy burned by miners would cost only *approx 5%* of block rewards
in USD terms max. On the other hand, BTC price has just collapsed 20%
because Tesla dropped their adoption citing environmental concerns. If
every miner on the planet agrees to go green or buy carbon credits, it will
actually be commercially beneficial to everybody, as the price will likely
skyrocket - the problem is that such situation absent community
coordination is not a Pareto-equilibrium state, which means that every
single miner is incentivised to break away from the commitment to the green
energy.

Maybe there is another solution to the problem, and huge mining pools need
to establish a 'green cartel' like OPEC and all start buying carbon credits
in order to make Bitcoin greener and more widely adopted for their own
benefit.

On Mon, May 17, 2021 at 3:58 AM Luke Dashjr <luke@dashjr.org> wrote:

> On Friday 14 May 2021 21:41:23 Michael Fuhrmann via bitcoin-dev wrote:
> > Bitcoin should create blocks every 10 minutes in average. So why do
> > miners need to mine the 9 minutes after the last block was found? It's
> > not necessary.
>
> It increases security, and is unavoidable anyway.
>
> > Problem: How to prevent "pre-mining" in the 9 minutes time window?
>
> You can't.
>
> > Possible ideas for discussion:
> >
> > - (maybe most difficult) global network timer sending a salted hash time
> > code after 9 minutes. this enables validation by nodes.
>
> PoW *is* the global network timer.
>
> > - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just
> > high enough) times higher difficulty. so everyone can mine any time but
> > before to 9 minutes are up there will be a too high downside. It is more
> > efficient to wait then paying high bills. The bitcoin will get a "puls".
>
> There's no timestamp at this stage of consensus.
>
> On Sunday 16 May 2021 18:10:12 Karl via bitcoin-dev wrote:
> > The clock might be implementable on a peer network level by requiring
> > inclusion of a transaction that was broadcast after a 9 minute delay.
>
> That requires a centralised authority.
>
> On Sunday 16 May 2021 20:31:47 Anton Ragin via bitcoin-dev wrote:
> > 1. Has anyone considered that it might be technically not possible to
> > completely 'power down' mining rigs during this 'cool-down' period of
> time?
> > While modern CPUs have power-saving modes, I am not sure about ASICs used
> > for mining.
>
> That would be miners' problem, not the network's... New ASICs would no
> doubt
> be made to work more efficiently.
>
> > 2. I am not a huge data-center specialist, but it was my understanding
> that
> > they charge per unit of installed (maximum) electricity consumption. It
> > would mean that if the miner needs X kilowatts-hour within that 1 minute
> > when they are allowed to mine, he/she will have to pay for the same X for
> > the remaining 9 minutes - and as such would have no economic incentive
> not
> > to draw that power when idling.
>
> Actually, this would be a good thing: it would heavily discourage
> datacentre
> use (which is very harmful to mining decentralisation).
>
> > 4. My counter-proposal to the community to address energy consumption
> > problems would be *to encourage users to allow only 'green miners'
> process
> > their transaction.* In particular:
> >...
> > (b) Should there be some non-profit organization(s) certifying green
> miners
> > and giving them cryptographic certificates of conformity (either usage of
> > green energy or purchase of offsets), users could encrypt their
> > transactions and submit to mempool in such a format that *only green
> miners
> > would be able to decrypt and process them*.
>
> Hello centralisation. Might as well just have someone sign miner keys, and
> get
> rid of PoW entirely...
>
>

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

<div dir=3D"ltr"><div><span class=3D"gmail-im" style=3D"color:rgb(80,0,80)"=
>&gt;&gt; 2. I am not a huge data-center specialist, but it was my understa=
nding that they charge per unit of installed (maximum) electricity consumpt=
ion. It would mean that if the miner needs X kilowatts-hour within that 1 m=
inute when they are allowed to mine, he/she will have to pay for the same X=
 for the remaining 9 minutes - and as such would have no economic incentive=
 not to draw that power when idling.<br><br></span>&gt;That sounds kind of =
exotic, could you take charge of checking to see<br>&gt;how true it is?<br>=
</div><div><span class=3D"gmail-im" style=3D"color:rgb(80,0,80)"><br></span=
></div><div><div>I am pretty sure that is how it works in data centers=C2=
=A0absent &#39;special deal&#39;, as we use some DCs in our business. Howev=
er, after reading some discussion on this thread it is pretty clear that so=
me (maybe even majority?) of miners have some sort of special deal on elect=
ricity - some use &#39;spill over&#39; electricity which would otherwise be=
 wasted etc. This kind of disproves my point, but not entirely - even &#39;=
special deal&#39; electricity is very unlikely to be available like water i=
n the tap - you open it when you need it, and pay for what you use only.=C2=
=A0</div><div><br></div><div>Variations in power consumption in the grid ar=
e very difficult to compensate for:</div><div><br></div><div>(a) there is n=
o efficient way to store electricity;<br></div><div>(b) some (majority?) po=
wer-generating assets are notoriously difficult to throttle up and down - i=
t takes almost a day in some cases to throttle down power production on the=
 nuclear power plant for example.</div><div><br></div><div>(did you know th=
at sometimes the spot price for electricity goes below zero, and consumers =
are being paid to consume - exactly because it is cheaper to pay somebody t=
o consume electricity than to switch off the reactor?)</div><div><br></div>=
<div>Because of this, an enormous=C2=A0spike in energy consumption every 1 =
minute in 10 is the worst possible load profile to any power grid, and woul=
d most likely result in either miners or power grid infrastructure itself j=
ust burning off peak energy during the 9 minutes &#39;cool-down&#39; period=
.</div><div></div></div><div><span class=3D"gmail-im" style=3D"color:rgb(80=
,0,80)"><br></span></div><div><span class=3D"gmail-im" style=3D"color:rgb(8=
0,0,80)">&gt;&gt; 4. My counter-proposal to the community to address energy=
 consumption<br></span>&gt;&gt; problems would be *to encourage users to al=
low only &#39;green miners&#39; process<br>&gt;&gt; their transaction.* In =
particular:<br>&gt;&gt;...<span class=3D"gmail-im" style=3D"color:rgb(80,0,=
80)"><br>&gt;&gt; (b) Should there be some non-profit organization(s) certi=
fying green miners<br>&gt;&gt; and giving them cryptographic certificates o=
f conformity (either usage of<br>&gt;&gt; green energy or purchase of offse=
ts), users could encrypt their<br></span>&gt;&gt; transactions and submit t=
o mempool in such a format that *only green miners<br>&gt;&gt; would be abl=
e to decrypt and process them*.<br><br>&gt;Hello centralisation. Might as w=
ell just have someone sign miner keys, and get<br>&gt;rid of PoW entirely..=
.<br></div><div>&gt;No, it is not centralization -=C2=A0</div><div><br></di=
v><div>No, it is not centralization, as:</div><div><br></div><div>(a) diffe=
rent miners could use different standards / certifications for &#39;green&#=
39; status, there are many already;</div><div>(b) it does not affect stabil=
ity of the network in a material way, rather creates small (12.5% of revenu=
e max) incentive to move to green sources of energy (or buy carbon credits)=
 and get certified - miners who would choose to run dirty energy will still=
 be able to do so.</div><div><div>and</div><div></div></div><div>(c) nothin=
g is being proposed beyond=C2=A0what is already possible - Antpool can go g=
reen today, and solicit users to send them signed transactions directly ins=
tead of adding them to a public mempool, under the pretext that it would ma=
ke the transfer &#39;greener&#39;. What is being proposed is some community=
 effort to standardize=C2=A0&amp; promote this approach, because if we mana=
ge to make Bitcoin green(er) - we will remove what many commentators=C2=A0s=
ee as the last barrier / biggest risk to even wider Bitcoin adoption.</div>=
<div><br></div><div>Not to mention the fact that some aspects of the Bitcoi=
n community are pretty centralized already - &#39;<a href=3D"http://www.bit=
coin.org">www.bitcoin.org</a>&#39;, GitHub repo, certain global internet ca=
bles / protocols / providers. Centralization is evil only when it enables (=
or makes significantly easier) a threatening attack on the network, which d=
oes not appear to be the case. It is my personal opinion only, though, I wo=
uld respect it if someone disagrees.</div><div><br></div><div>On a separate=
 note, I just want to draw everyone&#39;s attention to the fact that - assu=
ming if my calculations are correct - carbon credits to offset dirty energy=
 burned by miners would cost only <u>approx 5%</u> of block rewards in USD =
terms max. On the other hand, BTC price has just collapsed 20% because Tesl=
a dropped their adoption citing environmental concerns. If every miner on t=
he planet agrees to go green or buy carbon credits, it will actually be com=
mercially beneficial to everybody, as the price will likely skyrocket - the=
 problem is that such situation absent community coordination is not a Pare=
to-equilibrium state, which means that every single miner is incentivised t=
o break away from the commitment to the green energy.</div><div><br></div><=
div>Maybe there is another solution to the problem, and huge mining pools n=
eed to establish a &#39;green cartel&#39; like OPEC and all start buying ca=
rbon credits in order to make Bitcoin greener and more widely adopted for t=
heir own benefit.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Mon, May 17, 2021 at 3:58 AM Luke Dashjr &lt;<a h=
ref=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>&gt; wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">On Friday 14 May 2021 21:41:2=
3 Michael Fuhrmann via bitcoin-dev wrote:<br>
&gt; Bitcoin should create blocks every 10 minutes in average. So why do<br=
>
&gt; miners need to mine the 9 minutes after the last block was found? It&#=
39;s<br>
&gt; not necessary.<br>
<br>
It increases security, and is unavoidable anyway.<br>
<br>
&gt; Problem: How to prevent &quot;pre-mining&quot; in the 9 minutes time w=
indow?<br>
<br>
You can&#39;t.<br>
<br>
&gt; Possible ideas for discussion:<br>
&gt;<br>
&gt; - (maybe most difficult) global network timer sending a salted hash ti=
me<br>
&gt; code after 9 minutes. this enables validation by nodes.<br>
<br>
PoW *is* the global network timer.<br>
<br>
&gt; - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or jus=
t<br>
&gt; high enough) times higher difficulty. so everyone can mine any time bu=
t<br>
&gt; before to 9 minutes are up there will be a too high downside. It is mo=
re<br>
&gt; efficient to wait then paying high bills. The bitcoin will get a &quot=
;puls&quot;.<br>
<br>
There&#39;s no timestamp at this stage of consensus.<br>
<br>
On Sunday 16 May 2021 18:10:12 Karl via bitcoin-dev wrote:<br>
&gt; The clock might be implementable on a peer network level by requiring<=
br>
&gt; inclusion of a transaction that was broadcast after a 9 minute delay.<=
br>
<br>
That requires a centralised authority.<br>
<br>
On Sunday 16 May 2021 20:31:47 Anton Ragin via bitcoin-dev wrote:<br>
&gt; 1. Has anyone considered that it might be technically not possible to<=
br>
&gt; completely &#39;power down&#39; mining rigs during this &#39;cool-down=
&#39; period of time?<br>
&gt; While modern CPUs have power-saving modes, I am not sure about ASICs u=
sed<br>
&gt; for mining.<br>
<br>
That would be miners&#39; problem, not the network&#39;s... New ASICs would=
 no doubt <br>
be made to work more efficiently.<br>
<br>
&gt; 2. I am not a huge data-center specialist, but it was my understanding=
 that<br>
&gt; they charge per unit of installed (maximum) electricity consumption. I=
t<br>
&gt; would mean that if the miner needs X kilowatts-hour within that 1 minu=
te<br>
&gt; when they are allowed to mine, he/she will have to pay for the same X =
for<br>
&gt; the remaining 9 minutes - and as such would have no economic incentive=
 not<br>
&gt; to draw that power when idling.<br>
<br>
Actually, this would be a good thing: it would heavily discourage datacentr=
e <br>
use (which is very harmful to mining decentralisation).<br>
<br>
&gt; 4. My counter-proposal to the community to address energy consumption<=
br>
&gt; problems would be *to encourage users to allow only &#39;green miners&=
#39; process<br>
&gt; their transaction.* In particular:<br>
&gt;...<br>
&gt; (b) Should there be some non-profit organization(s) certifying green m=
iners <br>
&gt; and giving them cryptographic certificates of conformity (either usage=
 of<br>
&gt; green energy or purchase of offsets), users could encrypt their<br>
&gt; transactions and submit to mempool in such a format that *only green m=
iners<br>
&gt; would be able to decrypt and process them*.<br>
<br>
Hello centralisation. Might as well just have someone sign miner keys, and =
get <br>
rid of PoW entirely...<br>
<br>
</blockquote></div>

--000000000000f546c605c285e1f6--