diff options
| author | Anton Ragin <anton@etc-group.com> | 2021-05-16 21:31:47 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-05-16 20:32:09 +0000 |
| commit | b1d7c6c1b55037560e33ab1702e19c4e215bc3c8 (patch) | |
| tree | a07f534b2720a9caa3b2f75d4e1cbf96c30c0ece | |
| parent | 3f56e1a597e9d8efb5a6eb7b0e0ba1bec851eb1e (diff) | |
| download | pi-bitcoindev-b1d7c6c1b55037560e33ab1702e19c4e215bc3c8.tar.gz pi-bitcoindev-b1d7c6c1b55037560e33ab1702e19c4e215bc3c8.zip | |
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
| -rw-r--r-- | c9/6a8dc8e4202d79c01f04979003831b174ae655 | 320 |
1 files changed, 320 insertions, 0 deletions
diff --git a/c9/6a8dc8e4202d79c01f04979003831b174ae655 b/c9/6a8dc8e4202d79c01f04979003831b174ae655 new file mode 100644 index 000000000..9442d5d86 --- /dev/null +++ b/c9/6a8dc8e4202d79c01f04979003831b174ae655 @@ -0,0 +1,320 @@ +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 572ACC0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 16 May 2021 20:32:09 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 33C1483918 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 16 May 2021 20:32:09 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: 0.951 +X-Spam-Level: +X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 + tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, + 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 4MEuECbE_R5N + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 16 May 2021 20:32:08 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com + [IPv6:2a00:1450:4864:20::32b]) + by smtp1.osuosl.org (Postfix) with ESMTPS id C5AD683868 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 16 May 2021 20:32:07 +0000 (UTC) +Received: by mail-wm1-x32b.google.com with SMTP id + h3-20020a05600c3503b0290176f13c7715so769066wmq.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 16 May 2021 13:32:07 -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; + bh=XJ7sjm8OUnwREV+pVopa60aU0AkBW8buGtiWQILTZzw=; + b=K8x7/S+RPIF/mRXXCsupW/6EnZOneMq0X/yF1h2Wjkcuj6qsNJ9xnjncxWpfvKOcww + 8Yt849F6eIC8YIXxC9TL4MeFNyDuR1hJ9PnUHBFJZvRRaMeZrfwrS5Dau1aumgANk7Gz + Z1bCKcVgk9BB2XIbXybY2uVDnDuE6N28ocQEe5DfMMtrp7nMu94aB4vVOvzPDZ+vUvko + XePUCKo2Izi3CCxA2spri/H2oT3A7zQdVIM0zt+XtZi4w+XGxcM+Zv+jIX5+I3GFd+CO + EE8IQZhe6wgRbMrUgTVanChY89I7dtKlrmRsr6KeRS/FCLmu9UqXzOKSZLcwR7VvdSN4 + cBSQ== +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; + bh=XJ7sjm8OUnwREV+pVopa60aU0AkBW8buGtiWQILTZzw=; + b=kUfR7o+iYRrpgTlm2ZVHkvKSPWgR4dnfhbXCYKf8VEijMuab0JEHE3GFVR0IM2+NDX + lH0j9G9U/NheG6Vke2m5fICx/pfWq+j5M22xRIy6hWW/7quQaIwzPgwMdRIr8xJx2VRK + IMtOVGJjvLk9MZz0sQ9f4a1HLV8XTa2sUz0myLz7ABkMO7FA/LtGcnl9462nkBhvAgAc + 00wQ+ZRLQGa3SYP0cQIWN1XDS9UgzWdsFlxeeltVdLrb1ejTy+i+tO7FIBRPxuCMYJSt + /zZQzWXbFgCVwIltiLVpo4YNNhwOFofhSps+q8L3sY1NB8exASHatQMeIDFGf8+oiKtV + Wd3w== +X-Gm-Message-State: AOAM533tmgzGU8IruYu/taxurITNXZScXPD6Mcelfw2jzKjE7QVoeY4J + t3GFcKgM+ExAVhzG6GWWX+wH8g3uSBt4aI0ZPpVqBA== +X-Google-Smtp-Source: ABdhPJx0OAulmGl5/yjJGFYq/vVUFHtsQs49yDGY3LdyoYVgZXMvj0l9ZgQOQ+hgU/jN9oWg6s4WhVlDxb1ZrG47g3U= +X-Received: by 2002:a7b:cd16:: with SMTP id f22mr2413862wmj.8.1621197126026; + Sun, 16 May 2021 13:32:06 -0700 (PDT) +MIME-Version: 1.0 +References: <d35dee03-2d19-e80a-c577-2151938f9203@web.de> + <CALL-=e45Q_spVnFqVvGAK9c3QzZ=-c_WNwCO-y30q7z-j6orSA@mail.gmail.com> +In-Reply-To: <CALL-=e45Q_spVnFqVvGAK9c3QzZ=-c_WNwCO-y30q7z-j6orSA@mail.gmail.com> +From: Anton Ragin <anton@etc-group.com> +Date: Sun, 16 May 2021 21:31:47 +0100 +Message-ID: <CAPyV_jBvbXPPGcCj1TsEf=J9D7ADYWWkTctd9XD5HjJZAQDAfQ@mail.gmail.com> +To: Karl <gmkarl@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000ced56e05c2785ea3" +X-Mailman-Approved-At: Sun, 16 May 2021 20:37:33 +0000 +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: Sun, 16 May 2021 20:32:09 -0000 + +--000000000000ced56e05c2785ea3 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +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. + +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. + +3. Not really a criticism of the idea to reduce Bitcoin energy consumption, +but rather a couple of observations: + +(a) Environmental concerns cause Bitcoin to be less popular and thus push +the price lower, which in turn lowers miner's power consumption (lower +Bitcoin price =3D> less they can afford to spend on electricity). So it is = +a +self-stabilizing system to begin with. +(b) Crazy power consumption may be a temporary problem, after the number of +halving events economic attractiveness of mining will decrease and power +consumption with it. + +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: + +(a) According to this source ( +https://www.blockchain.com/charts/transaction-fees-usd), fees represent +approximately 12.5% of total miner reward. Not a lot, but not insignificant +either. + +(b) Based on the method used in this source ( +https://digiconomist.net/bitcoin-energy-consumption/) to offset CO2 +emissions of bitcoin mining the miner would need to spend approx ~3.6% - +7.2% (depending how 'dirty' is his power source) x 87.5% (mined portion of +its rewards) of its fees (assuming 50k Bitcoin price and 15$ / tonne of CO2 +price of carbon offset). + +(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*. + +Users routing transactions specifically to 'green miners' (and posting +potentially higher fees) would create economic incentives for miners to use +green energy and/or buy CO2 offsets, as described above with ~3.1% - 6.8% +of total revenue cost to offset CO2 vs.12.5% of fees component in mining, +if majority of users would use the routing to green miners method - there +is a chance that Bitcoin network will become significantly greener. + +Anton. + +On Sun, May 16, 2021 at 8:02 PM Karl via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> [sorry if I haven't replied to the other thread on this, I get swamped +> by email and don't catch them all] +> +> This solution is workable but it seems somewhat difficult to me at this +> time. +> +> The clock might be implementable on a peer network level by requiring +> inclusion of a transaction that was broadcast after a 9 minute delay. +> +> Usually a 50% hashrate attack is needed to reverse a transaction in +> bitcoin. With this change, this naively appears to become a 5% +> hashrate attack, unless a second source of truth around time and order +> is added, to verify proposed histories with. +> +> A 5% hashrate attack is much harder here, because the users of mining +> pools would be mining only 10% of the time, so compromising mining +> pools would not be as useful. +> +> Historically, hashrate has increased exponentially. This means that +> the difficulty of performing an attack, whether it is 5% or 50%, is +> still culturally infeasible because it is a multiplicative, rather +> than an exponential, change. +> +> If this approach were to be implemented, it could be important to +> consider how many block confirmations people wait for to trust their +> transaction is on the chain. A lone powerful miner could +> intentionally fork the chain more easily by a factor of 10. They +> would need to have hashrate that competes with a major pool to do so. +> +> > How would you prevent miners to already compute the simpler difficulty +> problem directly after the block was found and publish their solution +> directly after minute 9? We would always have many people with a finished= + / +> competing solution. +> +> Such a chain would have to wait a longer time to add further blocks +> and would permanently be shorter. +> +> > Your proposal won=E2=80=99t save any energy because it does nothing to = +decrease +> the budget available to mine a block (being the block reward). +> +> You are assuming this budget is directly related to energy +> expenditure, but if energy is only expended for 10% of the same +> duration, this money must now be spent on hardware. The supply of +> bitcoin hardware is limited. +> +> In the long term, it won't be, so a 10% decrease is a stop-gap +> measure. Additionally, in the long term, we will have quantum +> computers and AI-designed cryptography algorithms, so things will be +> different in a lot of other ways too. +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--000000000000ced56e05c2785ea3 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">1. Has anyone considered that it might be technically not = +possible to completely 'power down' mining=C2=A0rigs during this &#= +39;cool-down' period of time? While modern CPUs have power-saving modes= +, I am not sure about ASICs used for mining.<div><br></div><div>2. I am not= + a huge data-center specialist, but it was my understanding that they charg= +e per unit of installed (maximum) electricity consumption. It would mean th= +at if the miner needs X kilowatts-hour within that 1 minute when they are a= +llowed to mine, he/she will have to pay for the same X for the remaining 9 = +minutes=C2=A0- and as such would have no economic incentive not to draw tha= +t power when idling.</div><div><br></div><div>3. Not really a criticism of = +the idea to reduce Bitcoin energy consumption, but rather a couple of obser= +vations:</div><div><br></div><div>(a) Environmental concerns=C2=A0cause Bit= +coin to be less popular and thus push the price lower, which in turn lowers= + miner's power consumption (lower Bitcoin price =3D> less they can a= +fford to spend on electricity). So it is a self-stabilizing system to begin= + with.</div><div>(b) Crazy power consumption may be a temporary=C2=A0proble= +m, after the number of halving events economic attractiveness of mining wil= +l decrease and power consumption with it.</div><div><br></div><div>4. My co= +unter-proposal to the community to address energy consumption problems woul= +d be <u>to encourage users to allow only 'green miners' process the= +ir transaction.</u>=C2=A0In particular:</div><div><br></div><div>(a) Accord= +ing to this source (<a href=3D"https://www.blockchain.com/charts/transactio= +n-fees-usd">https://www.blockchain.com/charts/transaction-fees-usd</a>), fe= +es represent approximately 12.5% of total miner reward. Not a lot, but not = +insignificant either.</div><div><br></div><div>(b) Based on the method used= + in this source (<a href=3D"https://digiconomist.net/bitcoin-energy-consump= +tion/">https://digiconomist.net/bitcoin-energy-consumption/</a>) to offset = +CO2 emissions of bitcoin mining the miner would need to spend approx ~3.6% = +- 7.2% (depending how 'dirty' is his power source) x 87.5% (mined p= +ortion of its rewards) of its fees (assuming 50k Bitcoin price and 15$ / to= +nne of CO2 price of carbon offset).</div><div>=C2=A0=C2=A0</div><div>(b) Sh= +ould there be some non-profit organization(s) certifying green miners and g= +iving them cryptographic certificates of conformity (either usage of green = +energy or purchase of offsets), users could encrypt their transactions and = +submit=C2=A0to mempool in such a format that <u>only green miners would be = +able to decrypt and process them</u>.</div><div><br></div><div>Users routin= +g transactions specifically to 'green miners' (and posting potentia= +lly higher fees) would create economic incentives for miners to use green e= +nergy and/or buy CO2 offsets, as described above with ~3.1% - 6.8% of total= + revenue cost to offset CO2 vs.12.5% of fees component in mining, if majori= +ty of users would use the routing to green miners method - there is a chanc= +e that Bitcoin network will become significantly greener.</div><div><br></d= +iv><div>Anton.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" c= +lass=3D"gmail_attr">On Sun, May 16, 2021 at 8:02 PM Karl via bitcoin-dev &l= +t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list= +s.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_qu= +ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= +4);padding-left:1ex">[sorry if I haven't replied to the other thread on= + this, I get swamped<br> +by email and don't catch them all]<br> +<br> +This solution is workable but it seems somewhat difficult to me at this tim= +e.<br> +<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> +Usually a 50% hashrate attack is needed to reverse a transaction in<br> +bitcoin.=C2=A0 With this change, this naively appears to become a 5%<br> +hashrate attack, unless a second source of truth around time and order<br> +is added, to verify proposed histories with.<br> +<br> +A 5% hashrate attack is much harder here, because the users of mining<br> +pools would be mining only 10% of the time, so compromising mining<br> +pools would not be as useful.<br> +<br> +Historically, hashrate has increased exponentially.=C2=A0 This means that<b= +r> +the difficulty of performing an attack, whether it is 5% or 50%, is<br> +still culturally infeasible because it is a multiplicative, rather<br> +than an exponential, change.<br> +<br> +If this approach were to be implemented, it could be important to<br> +consider how many block confirmations people wait for to trust their<br> +transaction is on the chain.=C2=A0 A lone powerful miner could<br> +intentionally fork the chain more easily by a factor of 10.=C2=A0 They<br> +would need to have hashrate that competes with a major pool to do so.<br> +<br> +> How would you prevent miners to already compute the simpler difficulty= + problem directly after the block was found and publish their solution dire= +ctly after minute 9? We would always have many people with a finished / com= +peting solution.<br> +<br> +Such a chain would have to wait a longer time to add further blocks<br> +and would permanently be shorter.<br> +<br> +> Your proposal won=E2=80=99t save any energy because it does nothing to= + decrease the budget available to mine a block (being the block reward).<br= +> +<br> +You are assuming this budget is directly related to energy<br> +expenditure, but if energy is only expended for 10% of the same<br> +duration, this money must now be spent on hardware.=C2=A0 The supply of<br> +bitcoin hardware is limited.<br> +<br> +In the long term, it won't be, so a 10% decrease is a stop-gap<br> +measure.=C2=A0 Additionally, in the long term, we will have quantum<br> +computers and AI-designed cryptography algorithms, so things will be<br> +different in a lot of other ways too.<br> +_______________________________________________<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> + +--000000000000ced56e05c2785ea3-- + |