diff options
| author | Anton Ragin <anton@etc-group.com> | 2021-05-17 13:39:02 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-05-17 12:39:24 +0000 |
| commit | 278ad834d3c2608e99462b3cc75e2fefb756d1a2 (patch) | |
| tree | 1f04400fd361d994dc4a6d17eea7141da04b84b2 | |
| parent | 08fad7573ec42796eab8bfe01550c76011b4990f (diff) | |
| download | pi-bitcoindev-278ad834d3c2608e99462b3cc75e2fefb756d1a2.tar.gz pi-bitcoindev-278ad834d3c2608e99462b3cc75e2fefb756d1a2.zip | |
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
| -rw-r--r-- | 7e/57f5dbe046ed7a1bcf795794f817556a63c3f4 | 442 |
1 files changed, 442 insertions, 0 deletions
diff --git a/7e/57f5dbe046ed7a1bcf795794f817556a63c3f4 b/7e/57f5dbe046ed7a1bcf795794f817556a63c3f4 new file mode 100644 index 000000000..d77f0343f --- /dev/null +++ b/7e/57f5dbe046ed7a1bcf795794f817556a63c3f4 @@ -0,0 +1,442 @@ +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)"= +>>> 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>>That sounds kind of = +exotic, could you take charge of checking to see<br>>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 'special deal', 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 '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 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 'cool-down' 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)">>> 4. My counter-proposal to the community to address energy= + consumption<br></span>>> problems would be *to encourage users to al= +low only 'green miners' process<br>>> their transaction.* In = +particular:<br>>>...<span class=3D"gmail-im" style=3D"color:rgb(80,0,= +80)"><br>>> (b) Should there be some non-profit organization(s) certi= +fying green miners<br>>> and giving them cryptographic certificates o= +f conformity (either usage of<br>>> green energy or purchase of offse= +ts), users could encrypt their<br></span>>> transactions and submit t= +o mempool in such a format that *only green miners<br>>> would be abl= +e to decrypt and process them*.<br><br>>Hello centralisation. Might as w= +ell just have someone sign miner keys, and get<br>>rid of PoW entirely..= +.<br></div><div>>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 '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 'greener'. What is being proposed is some community= + effort to standardize=C2=A0& 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 - '<a href=3D"http://www.bit= +coin.org">www.bitcoin.org</a>', 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'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 'green cartel' 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 <<a h= +ref=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>> 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> +> Bitcoin should create blocks every 10 minutes in average. So why do<br= +> +> miners need to mine the 9 minutes after the last block was found? It&#= +39;s<br> +> not necessary.<br> +<br> +It increases security, and is unavoidable anyway.<br> +<br> +> Problem: How to prevent "pre-mining" in the 9 minutes time w= +indow?<br> +<br> +You can't.<br> +<br> +> Possible ideas for discussion:<br> +><br> +> - (maybe most difficult) global network timer sending a salted hash ti= +me<br> +> code after 9 minutes. this enables validation by nodes.<br> +<br> +PoW *is* the global network timer.<br> +<br> +> - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or jus= +t<br> +> high enough) times higher difficulty. so everyone can mine any time bu= +t<br> +> before to 9 minutes are up there will be a too high downside. It is mo= +re<br> +> efficient to wait then paying high bills. The bitcoin will get a "= +;puls".<br> +<br> +There's no timestamp at this stage of consensus.<br> +<br> +On Sunday 16 May 2021 18:10:12 Karl via bitcoin-dev wrote:<br> +> The clock might be implementable on a peer network level by requiring<= +br> +> 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> +> 1. Has anyone considered that it might be technically not possible to<= +br> +> completely 'power down' mining rigs during this 'cool-down= +' period of time?<br> +> While modern CPUs have power-saving modes, I am not sure about ASICs u= +sed<br> +> for mining.<br> +<br> +That would be miners' problem, not the network's... New ASICs would= + no doubt <br> +be made to work more efficiently.<br> +<br> +> 2. I am not a huge data-center specialist, but it was my understanding= + that<br> +> they charge per unit of installed (maximum) electricity consumption. I= +t<br> +> would mean that if the miner needs X kilowatts-hour within that 1 minu= +te<br> +> when they are allowed to mine, he/she will have to pay for the same X = +for<br> +> the remaining 9 minutes - and as such would have no economic incentive= + not<br> +> 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> +> 4. My counter-proposal to the community to address energy consumption<= +br> +> problems would be *to encourage users to allow only 'green miners&= +#39; process<br> +> their transaction.* In particular:<br> +>...<br> +> (b) Should there be some non-profit organization(s) certifying green m= +iners <br> +> and giving them cryptographic certificates of conformity (either usage= + of<br> +> green energy or purchase of offsets), users could encrypt their<br> +> transactions and submit to mempool in such a format that *only green m= +iners<br> +> 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-- + |