From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A1937C0001 for ; Fri, 5 Mar 2021 23:10:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8DD154ED86 for ; Fri, 5 Mar 2021 23:10:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RdadQpYAvDIf for ; Fri, 5 Mar 2021 23:10:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by smtp4.osuosl.org (Postfix) with ESMTPS id D9E6F4ED82 for ; Fri, 5 Mar 2021 23:10:56 +0000 (UTC) Received: by mail-yb1-xb35.google.com with SMTP id l8so3615790ybe.12 for ; Fri, 05 Mar 2021 15:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kV5iWD/VL4rn522X9QTsTLQo6F7groy/A1YcBdc3TII=; b=mi50yYlorBc9oyxNd5kSPaE9D5iAslf9I0aL6RnpRb0FK7uzBDA1+88vaL2DhD03xj 6OQHDNrLNTSgCDjcCoFW0ThoozS4ktA6kYxMzK+kWy+lBZI6wJ3vwGnYORPm2n3ZAV49 sU8slRhYPBH7+doVbtuqQ/hlRtx75S96FM2hoDCA5VsELqHAiJP3cwlQbRF7rbGh/AZU 68asD1QMxyvguZiYetjyVVgZYgv+a611XtgYGuGix1uYkglTjZc/0R9+JXchTx4+V9qx lgt+7yxPzz58n9h+6k3JrgYY7YDYALqPaGGXgDocLrw3WMc+rOJdj7RdJAUhb7IixnSx nJqA== 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=kV5iWD/VL4rn522X9QTsTLQo6F7groy/A1YcBdc3TII=; b=cmotOP0TZ49zBmA3xSeraFDBfqHlr0CTEK2xK7zFe5/sR58YQ73H2qR+LcwBTmGjPS q9/GfqFqfw19Vc/GkXfkgwvnqzKcwepNIKReMjLdUZeFLjaYUKjHRxsqW4GBRnjofkxh hJ5hnTIMp6T4EO0vQTc3ak1fyaON0e1L/P43uw2wCztcvMRAWheSl0ysrdoUELGeo1ZE c6H20EWq9nX/iRLtmZ6kwfx4UAYMryuQZ0+OeJHOCCe/jKAPxReRBV3zB3Gn8N+L0PrB 5ackHy9h/kf01b2ip/zPr8RDRSIsy2FQPmPLm/huBdVW0zwWjTA1mpsHzAqRdzlas8Ns BYow== X-Gm-Message-State: AOAM533TMG9aLhJV0CiIKHvpH6nPVokMfhb27DNtGOYQMIb7cK6ZSgsf 1OZjhDJ50OUoSivIfAvRbP5QS07PXntiue2m5OY= X-Google-Smtp-Source: ABdhPJy9cuJ7pm+Ax3PToWi+QzLqm7ECCwbw+XlNpMzNaSPOGVDGpz300bmoB0mGxNs2EjpZTcBEM+J/3tdmYEAd1hE= X-Received: by 2002:a25:bd85:: with SMTP id f5mr17228037ybh.183.1614985855855; Fri, 05 Mar 2021 15:10:55 -0800 (PST) MIME-Version: 1.0 References: <974C7CF0-5087-4120-B860-35FAEF39EA95@voskuil.org> In-Reply-To: <974C7CF0-5087-4120-B860-35FAEF39EA95@voskuil.org> From: Lonero Foundation Date: Fri, 5 Mar 2021 18:10:43 -0500 Message-ID: To: Eric Voskuil Content-Type: multipart/alternative; boundary="000000000000416d4d05bcd232a7" X-Mailman-Approved-At: Sat, 06 Mar 2021 08:58:05 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 23:10:59 -0000 --000000000000416d4d05bcd232a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, in regards to my research this is just one of my patents: https://patents.google.com/patent/CN110825707A This isn't related to this proposal but gives you a general depth of understanding in regards to the technology and field I'm working on in reducing redundancy and efficiency. You aren't a cryptographer, but there are easy ways to validate my proposal if it was to be made. In regards to popularity, many people have wanted to upgrade BTC's cryptography in a similar manner. I believe it is at the very least a topic of interest to you and others in the community. I would like to draft it out. Lastly, I wasn't sure if you wanted to create a private thread or meant reply all so that is my fault. The recent reply is to the BTC Dev list so I wanted to provide my insight in regards to your inquiry. Best regards, Andrew On Fri, Mar 5, 2021, 5:50 PM Eric Voskuil wrote: > FYI it=E2=80=99s generally considered bad form repost a private thread, e= specially > one you initiate. > > ... > > It=E2=80=99s typically more effective to generate some community support = before > actually submitting a BIP. Otherwise the process gets easily overwhelmed. > This is likely why you aren=E2=80=99t getting a response. You can draft t= he BIP in > your own repo and collect feedback from interested parties. > > Posting a link to your research/code is a good start. I=E2=80=99d be happ= y to look > at an overview of the central principles. I=E2=80=99m not a cryptographer= . I write > code, but I look at these things from economic principles. So far all I > have to go on is that you go =E2=80=9Cmuch beyond=E2=80=9D Chia. That=E2= =80=99s not really anything. > > e > > On Mar 5, 2021, at 14:03, Lonero Foundation > wrote: > > =EF=BB=BF > Hi, Eric. Chia's network is a bad example. They go after energy > consumption in the wrong way entirely. True, it requires a comparable cos= t > of hardware. I am trying to tackle cryptography in a way that goes much > beyond that. Part of what I am doing includes lowering invalided proofs > while trying to get the best of both worlds in regards to PoW and PoC. It > is an efficiency issue to the core. In regards to the mechanisms of how I > will do that, I suggest you look at the entire proposal which is why I am > hoping the BIP team would be so gracious as to allow me to draft it out o= n > GitHub. > > Best regards, Andrew > > On Fri, Mar 5, 2021, 4:42 PM Eric Voskuil wrote: > >> How is the argument against PoM only partially true? >> >> I wrote this as soon as I saw Chia. Had two debates on Twitter with >> Brahm, before he blocked me. Two years later, after they finally realize= d I >> was correct, one of their PhDs contacted me and told me. Better to flesh >> this out early. They had already raised $20 and done their research, so = he >> wasn=E2=80=99t exactly in a listening mode. >> >> e >> >> On Mar 5, 2021, at 13:20, Lonero Foundation >> wrote: >> >> =EF=BB=BF >> Actually I mentioned a proof of space and time hybrid which is much >> different than staking. Sorry to draw for the confusion as PoC is more >> commonly used then PoST. >> There is a way to make PoC cryptographically compatible w/ Proof of Work >> as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space >> It has rarely been done though given the technological complexity of >> being both CPU compatible and memory-hard compatible. There are lots of >> benefits outside of the realm of efficiency, and I already looked into >> numerous fault tolerant designs as well and what others in the cryptogra= phy >> community attempted to propose. The actual argument you have only agains= t >> this is the Proof of Memory fallacy, which is only partially true. Given >> how the current hashing algorithm works, hard memory allocation wouldn't= be >> of much benefit given it is more optimized for CPU/ASIC specific mining. >> I'm working towards a hybrid mechanism that fixes that. BTW: The way >> Bitcoin currently stands in its cryptography still needs updating >> regardless. If someone figures out NP hardness or the halting problem th= e >> traditional rule of millions of years to break all of Bitcoin's >> cryptography now comes down to minutes. Bitcoin is going to have to >> eventually radically upgrade their cryptography and hashing algo in the >> future regardless. I want to integrate some form of NP complexity in >> regards to the hybrid cryptography I'm aiming to provide which includes = a >> polynomial time algorithm in the cryptography. More than likely the firs= t >> version of my BTC hard fork will be coded in a way where integrating suc= h >> complexity in the future only requires a soft fork or minor upgrade to i= ts >> chain. >> >> In regards to the argument, "As a separate issue, proposing a hard fork >> in the hashing algorithm will invalidate the enormous amount of capital >> expenditure by mining entities and disincentivize future capital >> expenditure into mining hardware that may compute these more "useful" >> proofs of work." >> >> A large portion of BTC is already mined through AWS servers and non-asic >> specific hardware anyways. A majority of them would benefit from a hybri= d >> proof, and the fact that it is hybrid in that manner wouldn't >> disenfranchise currently optimized mining entities as well. >> >> There are other reasons why a cryptography upgrade like this is >> beneficial. Theoretically one can argue BItcoin isn't fully decentralize= d. >> It is few unsolved mathematical proofs away from being entirely broken. = My >> goal outside of efficiency is to build cryptography in a way that preven= ts >> such an event from happening in the future, if it was to ever happen. I >> have various research in regards to this area and work alot with >> distributed computing. I believe if the BTC community likes such a >> proposal, I would single handedly be able to build the cryptographic pro= of >> myself (though would like as many open source contributors as I can get = :) >> >> Anyways just something to consider. We are in the same space in regards >> to what warrants a shitcoin or the whole argument against staking. >> >> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-sto= p-telling-us-that-you-arent-pi3s3yjl >> >> Best regards, Andrew >> >> On Fri, Mar 5, 2021 at 3:53 PM Eric Voskuil wrote: >> >>> =EF=BB=BFHi Andrew, >>> >>> Do you mean that you can reduce the cost of executing the cryptography >>> at a comparable level of security? If so this will only have the effect= of >>> increasing the amount of it that is required to consume the same cost. >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox >>> >>> You mentioned a staking hybrid in your original post. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fall= acy >>> >>> This would be a change to dynamics - the economic forces at work. >>> Staking is not censorship resistant >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fal= lacy >>> >>> and is therefore what I refer to as cryptodynamically insecure. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Prin= ciples >>> >>> As such it wouldn=E2=80=99t likely be considered as a contribution to B= itcoin. >>> It might of course be useful in some other context. >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definitio= n >>> >>> But BIPs are proposals aimed at Bitcoin improvement. >>> >>> >>> https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_= a_BIP >>> >>> Non-staking attempts to improve energy efficiency are either proof of >>> work in disguise, such as proof of memory: >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fa= llacy >>> >>> or attempts to repurpose =E2=80=9Cwasteful=E2=80=9D computing, such as = by finding prime >>> numbers, which does not imply a reduction in dedicated energy >>> consumption. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Pri= nciple >>> >>> Finally, waste and renewable energy approaches at =E2=80=9Ccarbon=E2=80= =9D (vs energy) >>> reduction must still consume the same in cost as the reward. In other >>> words, the apparent benefit represents a temporary market shift, with >>> advantage to first movers. The market will still consume what it consum= es. >>> If the hashing energy was free all reward consumption would shift to >>> operations. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-F= allacy >>> >>> The motivation behind these attempts is naively understandable, but >>> based on a false premise. >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Falla= cy >>> >>> The one thing that reduces Bitcoin energy consumption is an increase in >>> energy cost relative to block reward. >>> >>> >>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Exhaustion-= Fallacy >>> >>> e >>> >>> On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> =EF=BB=BF >>> Hi, this isn't about the energy efficient argument in regards to >>> renewables or mining devices but a better cryptography layer to get the >>> most out of your hashing for validation. I do understand the arbitrarin= ess >>> of it, but do want to still propose a document. Do I use the Media Wiki >>> format on GitHub and just attach it as my proposal? >>> >>> Best regards, Andrew >>> >>> On Fri, Mar 5, 2021, 10:07 AM Devrandom >>> wrote: >>> >>>> Hi Ryan and Andrew, >>>> >>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> >>>>> >>>>> https://www.truthcoin.info/blog/pow-cheapest/ >>>>> "Nothing is Cheaper than Proof of Work" >>>>> on | 04 Aug 2015 >>>>> >>>>> >>>> Just to belabor this a bit, the paper demonstrates that the mining >>>> market will tend to expend resources equivalent to miner reward. It d= oes >>>> not prove that mining work has to expend *energy* as a primary cost. >>>> >>>> Some might argue that energy expenditure has negative externalities an= d >>>> that we should move to other resources. I would argue that the negati= ve >>>> externalities will go away soon because of the move to renewables, so = the >>>> point is likely moot. >>>> >>>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> --000000000000416d4d05bcd232a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, in regards to my research this is just one of my pate= nts:
This isn't related to this proposal but gives you a general d= epth of understanding in regards to the technology and field I'm workin= g on in reducing redundancy and efficiency. You aren't a cryptographer,= but there are easy ways to validate my proposal if it was to be made. In r= egards to popularity, many people have wanted to upgrade BTC's cryptogr= aphy in a similar manner. I believe it is at the very least a topic of inte= rest to you and others in the community. I would like to draft it out. Last= ly, I wasn't sure if you wanted to create a private thread or meant rep= ly all so that is my fault. The recent reply is to the BTC Dev list so I wa= nted to provide my insight in regards to your inquiry.

Best regards, Andrew

On Fri, Mar 5, 202= 1, 5:50 PM Eric Voskuil <eric@voskui= l.org> wrote:
FYI it=E2= =80=99s generally considered bad form repost a private thread, especially o= ne you initiate.

...

It=E2=80=99s typically more effective to generate some community support = before actually submitting a BIP. Otherwise the process gets easily overwhe= lmed. This is likely why you aren=E2=80=99t getting a response. You can dra= ft the BIP in your own repo and collect feedback from interested parties.

Posting a link to your research/code is a good s= tart. I=E2=80=99d be happy to look at an overview of the central principles= . I=E2=80=99m not a cryptographer. I write code, but I look at these things= from economic principles. So far all I have to go on is that you go =E2=80= =9Cmuch beyond=E2=80=9D Chia. That=E2=80=99s not really anything.

e

On Mar 5, 2021, at 14:03, Lonero Foundation <loneroassociat= ion@gmail.com> wrote:

=EF=BB=BF
Hi, Eric. Chia's netw= ork is a bad example. They go after energy consumption in the wrong way ent= irely. True, it requires a comparable cost of hardware. I am trying to tack= le cryptography in a way that goes much beyond that. Part of what I am doin= g includes lowering invalided proofs while trying to get the best of both w= orlds in regards to PoW and PoC. It is an efficiency issue to the core. In = regards to the mechanisms of how I will do that, I suggest you look at the = entire proposal which is why I am hoping the BIP team would be so gracious = as to allow me to draft it out on GitHub.

Best regards, Andrew

=
On Fri, Mar 5, 2021, 4:42 PM Eric Vos= kuil <eric@voskuil.org> wrote:
How is the argument against PoM only= partially true?

I wrote t= his as soon as I saw Chia. Had two debates on Twitter with Brahm, before he= blocked me. Two years later, after they finally realized I was correct, on= e of their PhDs contacted me and told me. Better to flesh this out early. T= hey had already raised $20 and done their research, so he wasn=E2=80=99t ex= actly in a listening mode.

e

On Mar 5, 2021, at 1= 3:20, Lonero Foundation <loneroassociation@gmail.com= > wrote:

=EF=BB=BF
Actually I mentioned a proof of sp= ace and time hybrid which is much different than staking. Sorry to draw for= the confusion as PoC is more commonly used then PoST.
There is a= way to make PoC cryptographically compatible w/ Proof of Work as it normal= ly stands: https://en.wikipedia.org/wiki/Proo= f_of_space
It has rarely been done though given the technolog= ical complexity of being both CPU compatible and memory-hard compatible. Th= ere are lots of benefits outside of the realm of efficiency, and I already = looked into numerous fault tolerant designs as well and what others in the = cryptography community attempted to propose. The actual argument you have o= nly against this is the Proof of Memory fallacy, which is only partially tr= ue. Given how the current hashing algorithm works, hard memory allocation w= ouldn't be of much benefit given it is more optimized for CPU/ASIC spec= ific mining. I'm working towards a hybrid mechanism that fixes that. BT= W: The way Bitcoin currently stands in its cryptography still needs updatin= g regardless. If someone figures out NP hardness or the halting problem the= traditional rule of millions of years to break all of Bitcoin's crypto= graphy now comes down to minutes. Bitcoin is going to have to eventually ra= dically upgrade their cryptography and hashing algo in the future regardles= s. I want to integrate some form of NP complexity in regards to the hybrid = cryptography I'm aiming to provide which includes a polynomial time alg= orithm in the cryptography. More than likely the first version of my BTC ha= rd fork will be coded in a way where integrating such complexity in the fut= ure only requires a soft fork or minor upgrade to its chain.

=
In regards to the argument, "As a separate issue, proposing= a hard fork in the hashing algorithm will invalidate the enormous amount of capital expenditure by mining=20 entities and disincentivize future capital expenditure into mining=20 hardware that may compute these more "useful" proofs of work.&quo= t;

A large portion of BTC is already mined through= AWS servers and non-asic specific hardware anyways. A majority of them wou= ld benefit from a hybrid proof, and the fact that it is hybrid in that mann= er wouldn't disenfranchise currently optimized mining entities as well.=

There are other reasons why a cry= ptography upgrade like this is beneficial. Theoretically one can argue BItc= oin isn't fully decentralized. It is few unsolved mathematical proofs a= way from being entirely broken. My goal outside of efficiency is to build c= ryptography in a way that prevents such an event from happening in the futu= re, if it was to ever happen. I have various research in regards to this ar= ea and work alot with distributed computing. I believe if the BTC community= likes such a proposal, I would single handedly be able to build the crypto= graphic proof myself (though would like as many open source contributors as= I can get :)

Anyways just something to consider. = We are in the same space in regards to what warrants a shitcoin or the whol= e argument against staking.

Best regards,=C2=A0 Andrew
=

On Fri, Mar 5, 2021 at 3:53 PM Eric Voskuil <eric@voskuil= .org> wrote:
=EF=BB=BFHi Andrew,
=

Do you mean that you can reduce= the cost of executing the cryptography at a comparable level of security? = If so this will only have the effect of increasing the amount of it that is= required to consume the same cost.


You mentioned a staking hybrid in= your original post.


This woul= d be a change to dynamics - the economic forces at work. Staking is not cen= sorship resistant

<= a href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Sta= ke-Fallacy" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.= com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy

and is therefore what I refer to as = cryptodynamically insecure.

https://gi= thub.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles

As suc= h it wouldn=E2=80=99t likely be considered as a contribution to Bitcoin. It= might of course be useful in some other context.

But BIPs are prop= osals aimed at Bitcoin improvement.




or attempts to repurpose =E2=80=9Cwasteful= =E2=80=9D computing, such as by finding prime numbers, which=C2=A0does not imply a reduction in dedicated energy cons= umption.


Finally, waste and renewable energy app= roaches at =E2=80=9Ccarbon=E2=80=9D (vs energy) reduction must still consum= e the same in cost as the reward. In other words, the apparent benefit repr= esents a temporary market shift, with advantage to first movers. The market= will still consume what it consumes. If the hashing energy was free all re= ward consumption would shift to operations.


The motivatio= n behind these attempts is naively understandable, but based on a false pre= mise.


<= div dir=3D"ltr">The one thing that reduces Bitcoin energy consumption is an= increase in energy cost relative to block reward.

e

On Mar 5, 2021, at 07:30,= Lonero Foundation via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:

=EF=BB=BF
Hi, thi= s isn't about the energy efficient argument in regards to renewables or= mining devices but a better cryptography layer to get the most out of your= hashing for validation. I do understand the arbitrariness of it, but do wa= nt to still propose a document. Do I use the Media Wiki format on GitHub an= d just attach it as my proposal?

Best regards, Andrew

On Fri, Mar 5, 2021, 10:07 AM Devrandom <<= a href=3D"mailto:c1.devrandom@niftybox.net" rel=3D"noreferrer noreferrer" t= arget=3D"_blank">c1.devrandom@niftybox.net> wrote:
Hi Ryan and Andrew,

On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via= bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:

=C2=A0 http= s://www.truthcoin.info/blog/pow-cheapest/
=C2=A0 =C2=A0 "Nothing is Cheaper than Proof of Work"
=C2=A0 =C2=A0 on | 04 Aug 2015


Just to belabor this a bit, the paper = demonstrates that the mining market will tend to expend resources equivalen= t to miner reward.=C2=A0 It does not prove that mining work has to expend *= energy* as a primary cost.

Some might argue th= at energy expenditure has negative externalities and that we should move to= other resources.=C2=A0 I would argue that the negative externalities will = go away soon because of the move to renewables, so the point is likely moo= t.=C2=A0

_______________________________________________
bitco= in-dev mailing list
bitcoin-d= ev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bi= tcoin-dev
<= /div>
--000000000000416d4d05bcd232a7--