From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 52F3AC0001 for ; Thu, 11 Mar 2021 15:29:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 35034431DE for ; Thu, 11 Mar 2021 15:29:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO0JIAkiW7Zf for ; Thu, 11 Mar 2021 15:29:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) by smtp2.osuosl.org (Postfix) with ESMTPS id 604E642FB1 for ; Thu, 11 Mar 2021 15:29:52 +0000 (UTC) Received: by mail-yb1-xb2a.google.com with SMTP id h82so22054380ybc.13 for ; Thu, 11 Mar 2021 07:29:52 -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; bh=JovU7cKaFwwZ9sUhFswGx2lvb192JTcYZb6XblOWIoM=; b=Favd0cGjtWjNTD5oVieWcjJe1F1f2AUzLqXGy63r5k57ZaCKF0EhcHenJsOV+JJbsQ hBsJLrSdcCSUz6yIfi9sByqeoDd10/h6aVPNaRWr3lUqOsuF0Sx0aIbpftNz155cG9YM rCBh4jSDir4/Zwzd1MHL9RHjLBh9/NUo/kaTEds9CegjsYzyNCuG+Cg8NS2gcUO9J6ia JYh4EQi8faOY7/6MQ7j/c1SPz1hZwMULKr3D7a3izs1oV9Il5DEHCSRMnpGZTxJlsCZF clGBd6/AhJOzYmrOFPs5a2u3LEyUF1h9UGEiHqg42XKPbF4gbN68NEq4JnpMCvmOZwp+ LQRQ== 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=JovU7cKaFwwZ9sUhFswGx2lvb192JTcYZb6XblOWIoM=; b=Vi6a47lR6PkxFdhqUewziSdpkEyj3qiQpr7jnQ3B652uDMCh9J47BH/NZxV33CBpfj 6i5YZvemnmVmeifwmoQlOyYFsC7X9OBc8b+rPmckkfdH1sZLhWrgGq1fII/cpL088OYY BuuHXhpA9D1kZW5UujV0d3YCkgESik/n6//S1bmUA1pM5RDHVX2SZ8SAedkORgq/iENZ nu4SwFAuTuSZK4bJ4UgrQo9yymWavna5h/Y3fqi4rUQBrfLoLl4BrJ2XWoCfpUoj9Alo c69cqi56IeZR5x+wRSLM3eARZurDTPO0ix7OkqnzC8vPC8ec1s7p+5SwYxjhVFM6Bmfs 2WFA== X-Gm-Message-State: AOAM533vEZFF/aSp1a4ZvQGBS0WKrJzPyPBru78dz23SGMC6W+oyUw16 pUfit6I80BFsCyPabYHH1lUxG7qe4VV/X70yCMuu2Xp3 X-Google-Smtp-Source: ABdhPJxWQg8eueG9b4hSsF6a4tU54WuYkQc6/A+tTsFnTkMzL6UdVqCum8EnEIxPWTAgqwzyCxitx77jGpAaH5aVmBI= X-Received: by 2002:a25:b206:: with SMTP id i6mr11906179ybj.499.1615476590956; Thu, 11 Mar 2021 07:29:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lonero Foundation Date: Thu, 11 Mar 2021 10:29:38 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000058d4fc05bd447449" X-Mailman-Approved-At: Thu, 11 Mar 2021 16:56:20 +0000 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: Thu, 11 Mar 2021 15:29:56 -0000 --00000000000058d4fc05bd447449 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have submitted the BIP Pull Request here: https://github.com/bitcoin/bips/pull/1084 Hoping to receive a BIP # for the draft prior to development/reference implementation. Best regards, Andrew On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation wrote: > Hi, here is the list to the BIP proposal on my own repo: > https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.media= wiki > Can I submit a pull request on the BIPs repo for this to go into draft > mode? Also, I think this provides at least some more insight on what I wa= nt > to work on. > > Best regards, Andrew > > On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation < > loneroassociation@gmail.com> wrote: > >> [off-list] >> >> Okay. I will do so and post the link here for discussion before doing a >> pull request on BIP's repo as the best way to handle it. >> >> Best regards, Andrew >> >> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe >> wrote: >> >>> As said before, you are free to create the BIP in your own repository >>> and bring it to discussion on the mailing list. then you can do a PR >>> >>> Lonero Foundation via bitcoin-dev >>> escreveu no dia s=C3=A1bado, >>> 6/03/2021 =C3=A0(s) 08:58: >>> > >>> > I know Ethereum had an outlandishly large percentage of nodes running >>> on AWS, I heard the same thing is for Bitcoin but for mining. Had troub= le >>> finding the article online so take it with a grain of salt. The point >>> though is that both servers and ASIC specific hardware would still be a= ble >>> to benefit from the cryptography upgrade I am proposing, as this was in >>> relation to the disinfranchisemet point. >>> > >>> > That said, I think the best way to move forward is to submit a BIP >>> pull request for a draft via GitHub using BIP #2's draft format and any >>> questions people have can be answered in the reqeust's comments. That w= ay >>> people don't have to get emails everytime there is a reply, but replies >>> still get seen as opposed to offline discussion. Since the instructions= say >>> to email bitcoin-dev before doing a bip draft, I have done that. Since >>> people want to see the draft beforehand and it isn't merged manually >>> anyways, I think it is the easiest way to handle this. >>> > >>> > I'm also okay w/ continuing the discussion on bitcoin-dev but rather >>> form a discussion on git instead given I don't want to accidentally >>> impolitely bother people given this is a moderated list and we already >>> established some interest for at least a draft. >>> > >>> > Does that seem fine? >>> > >>> > Best regards, Andrew >>> > >>> > On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland < >>> keagan.mcclelland@gmail.com> wrote: >>> >> >>> >> > A large portion of BTC is already mined through AWS servers and >>> non-asic specific hardware anyways. A majority of them would benefit fr= om a >>> hybrid proof, and the fact that it is hybrid in that manner wouldn't >>> disenfranchise currently optimized mining entities as well. >>> >> >>> >> My instincts tell me that this is an outlandish claim. Do you have >>> supporting evidence for this? >>> >> >>> >> Keagan >>> >> >>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> >>> >>> 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_spac= e >>> >>> It has rarely been done though given the technological complexity o= f >>> 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 cryptogr= aphy >>> community attempted to propose. The actual argument you have only again= st >>> this is the Proof of Memory fallacy, which is only partially true. Give= n >>> 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 t= he >>> 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 fir= st >>> version of my BTC hard fork will be coded in a way where integrating su= ch >>> complexity in the future 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 entities and disincentivize future capita= l >>> 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 fr= om a >>> hybrid 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 decentraliz= ed. >>> It is few unsolved mathematical proofs away from being entirely broken.= My >>> goal outside of efficiency is to build cryptography in a way that preve= nts >>> 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 pr= oof >>> 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 staki= ng. >>> >>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-st= op-telling-us-that-you-arent-pi3s3yjl >>> >>> >>> >>> Best regards, Andrew >>> >>> >>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland < >>> keagan.mcclelland@gmail.com> wrote: >>> >>>> >>> >>>> It is important to understand that it is critical for the work to >>> be "useless" in order for the security model to be the same. If the wor= k >>> was useful it provides an avenue for actors to have nothing at stake wh= en >>> submitting a proof of work, since the marginal cost of block constructi= on >>> will be lessened by the fact that the work was useful in a different >>> context and therefore would have been done anyway. This actually degrad= es >>> the security of the network in the process. >>> >>>> >>> >>>> As a separate issue, proposing a hard fork in the hashing algorith= m >>> will invalidate the enormous amount of capital expenditure by mining >>> entities and disincentivize future capital expenditure into mining hard= ware >>> that may compute these more "useful" proofs of work. This is because an= y >>> change in the POW algorithm will be considered unstable and subject to >>> change in the future. This puts the entire network at even more risk >>> meaning that no entity is tying their own interests to that of the bitc= oin >>> network at large. It also puts the developers in a position where they = can >>> be bribed by entities with a vested interest in deciding what the new >>> "useful" proof of work should be. >>> >>>> >>> >>>> All of these things make the Bitcoin network worse off. >>> >>>> >>> >>>> Keagan >>> >>>> >>> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>>> >>> >>>>> Also in regards to my other email, I forgot to iterate that my >>> cryptography proposal helps behind the efficiency category but also tac= kles >>> problems such as NP-Completeness or Halting which is something the BTC >>> network could be vulnerable to in the future. For sake of simplicity, I= do >>> want to do this BIP because it tackles lots of the issues in regards to >>> this manner and can provide useful insight to the community. If things = such >>> as bigger block height have been proposed as hard forks, I feel at the = very >>> least an upgrade regarding the hashing algorithm and cryptography does = at >>> least warrant some discussion. Anyways I hope I can send you my BIP, ju= st >>> let me know on the preferred format? >>> >>>>> >>> >>>>> Best regards, Andrew >>> >>>>> >>> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation < >>> loneroassociation@gmail.com> wrote: >>> >>>>>> >>> >>>>>> 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 < >>> c1.devrandom@niftybox.net> 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 >>> does not prove that mining work has to expend *energy* as a primary cos= t. >>> >>>>>>> >>> >>>>>>> Some might argue that energy expenditure has negative >>> externalities and that we should move to other resources. I would argu= e >>> that the negative externalities will go away soon because of the move t= o >>> renewables, so the point is likely moot. >>> >>>>>>> >>> >>>>> _______________________________________________ >>> >>>>> bitcoin-dev mailing list >>> >>>>> bitcoin-dev@lists.linuxfoundation.org >>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> >>> _______________________________________________ >>> >>> bitcoin-dev mailing list >>> >>> bitcoin-dev@lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> > >>> > _______________________________________________ >>> > bitcoin-dev mailing list >>> > bitcoin-dev@lists.linuxfoundation.org >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> --00000000000058d4fc05bd447449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, I have submitted the BIP Pull Request here:=C2=A0https://github.com/bitcoi= n/bips/pull/1084=C2=A0

Hop= ing to receive a BIP # for the draft prior to development/reference impleme= ntation.

Best regards, A= ndrew

On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <loneroassociation@gmail.com> wrote= :
Hi, here is the= list to the BIP proposal on my own repo: https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/mai= n/bip-draft.mediawiki
Can I submit a pull request on t= he BIPs repo for this to go into draft mode? Also, I think this provides at= least some more insight on what I want to work on.
=
Best regards, Andrew

On Sat, Mar 6, 2021,= 10:42 AM Lonero Foundation <loneroassociation@gmail.com>= ; wrote:
[off-list]

Okay. I will do so an= d post the link here for discussion before doing a pull request on BIP'= s repo as the best way to handle=C2=A0it.

Best regards, Andrew

=
On Sat, Mar 6, 2021, 10:21 AM Ricardo= Filipe <ricardojdfilipe@gmail.com> wrote:
<= /div>
As said before, you are free to create = the BIP in your own repository
and bring it to discussion on the mailing list. then you can do a PR

Lonero Foundation via bitcoin-dev
<bitcoin-dev@lists.linuxfoundat= ion.org> escreveu no dia s=C3=A1bado,
6/03/2021 =C3=A0(s) 08:58:
>
> I know Ethereum had an outlandishly large percentage of nodes running = on AWS, I heard the same thing is for Bitcoin but for mining. Had trouble f= inding the article online so take it with a grain of salt. The point though= is that both servers and ASIC specific hardware would still be able to ben= efit from the cryptography upgrade I am proposing, as this was in relation = to the disinfranchisemet point.
>
> That said, I think the best way to move forward is to submit a BIP pul= l request for a draft via GitHub using BIP #2's draft format and any qu= estions people have can be answered in the reqeust's comments. That way= people don't have to get emails everytime there is a reply, but replie= s still get seen as opposed to offline discussion. Since the instructions s= ay to email bitcoin-dev before doing a bip draft, I have done that. Since p= eople want to see the draft beforehand and it isn't merged manually any= ways, I think it is the easiest way to handle this.
>
> I'm also okay w/ continuing the discussion on bitcoin-dev but rath= er form a discussion on git instead given I don't want to accidentally = impolitely bother people given this is a moderated list and we already esta= blished some interest for at least a draft.
>
> Does that seem fine?
>
> Best regards, Andrew
>
> On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland <keagan.mcclelland@gmail.com> wrote:
>>
>> > A large portion of BTC is already mined through AWS servers a= nd non-asic specific hardware anyways. A majority of them would benefit fro= m a hybrid proof, and the fact that it is hybrid in that manner wouldn'= t disenfranchise currently optimized mining entities as well.
>>
>> My instincts tell me that this is an outlandish claim. Do you have= supporting evidence for this?
>>
>> Keagan
>>
>> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundati= on.org> wrote:
>>>
>>> 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 mor= e commonly used then PoST.
>>> There is a way to make PoC cryptographically compatible w/ Pro= of of Work as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space
>>> It has rarely been done though given the technological complex= ity 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 cryptography= community attempted to propose. The actual argument you have only against = this is the Proof of Memory fallacy, which is only partially true. Given ho= w 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 B= itcoin currently stands in its cryptography still needs updating regardless= . If someone figures out NP hardness or the halting problem the traditional= rule of millions of years to break all of Bitcoin's cryptography now c= omes down to minutes. Bitcoin is going to have to eventually radically upgr= ade 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 th= e cryptography. More than likely the first version of my BTC hard fork will= be coded in a way where integrating such complexity in the future only req= uires a soft fork or minor upgrade to its chain.
>>>
>>> In regards to the argument, "As a separate issue, proposi= ng a hard fork in the hashing algorithm will invalidate the enormous amount= of capital expenditure by mining entities and disincentivize future capita= l expenditure into mining hardware that may compute these more "useful= " proofs of work."
>>>
>>> A large portion of BTC is already mined through AWS servers an= d non-asic specific hardware anyways. A majority of them would benefit from= a hybrid 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 i= s beneficial. Theoretically one can argue BItcoin isn't fully decentral= ized. It is few unsolved mathematical proofs away from being entirely broke= n. My goal outside of efficiency is to build cryptography in a way that pre= vents 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 distrib= uted computing. I believe if the BTC community likes such a proposal, I wou= ld single handedly be able to build the cryptographic 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 i= n regards to what warrants a shitcoin or the whole argument against staking= .
>>> https://hackernoon.co= m/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-ar= ent-pi3s3yjl
>>>
>>> Best regards,=C2=A0 Andrew
>>>
>>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <keagan.mcclelland@gmail.com> wrote:
>>>>
>>>> It is important to understand that it is critical for the = work to be "useless" in order for the security model to be the sa= me. If the work was useful it provides an avenue for actors to have nothing= at stake when submitting a proof of work, since the marginal cost of block= construction will be lessened by the fact that the work was useful in a di= fferent context and therefore would have been done anyway. This actually de= grades the security of the network in the process.
>>>>
>>>> As a separate issue, proposing a hard fork in the hashing = algorithm will invalidate the enormous amount of capital expenditure by min= ing entities and disincentivize future capital expenditure into mining hard= ware that may compute these more "useful" proofs of work. This is= because any change in the POW algorithm will be considered unstable and su= bject to change in the future. This puts the entire network at even more ri= sk meaning that no entity is tying their own interests to that of the bitco= in network at large. It also puts the developers in a position where they c= an be bribed by entities with a vested interest in deciding what the new &q= uot;useful" proof of work should be.
>>>>
>>>> All of these things make the Bitcoin network worse off. >>>>
>>>> Keagan
>>>>
>>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitco= in-dev <bitcoin-dev@lists.linux= foundation.org> wrote:
>>>>>
>>>>> Also in regards to my other email, I forgot to iterate= that my cryptography proposal helps behind the efficiency category but als= o tackles problems such as NP-Completeness or Halting which is something th= e BTC network could be vulnerable to in the future. For sake of simplicity,= I do want to do this BIP because it tackles lots of the issues in regards = to this manner and can provide useful insight to the community. If things s= uch as bigger block height have been proposed as hard forks, I feel at the = very least an upgrade regarding the hashing algorithm and cryptography does= at least warrant some discussion. Anyways I hope I can send you my BIP, ju= st let me know on the preferred format?
>>>>>
>>>>> Best regards, Andrew
>>>>>
>>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <loneroassociation@gmail.com> wrote:
>>>>>>
>>>>>> Hi, this isn't about the energy efficient argu= ment in regards to renewables or mining devices but a better cryptography l= ayer to get the most out of your hashing for validation. I do understand th= e arbitrariness of it, but do want to still propose a document. Do I use th= e Media Wiki format on GitHub and just attach it as my proposal?
>>>>>>
>>>>>> Best regards, Andrew
>>>>>>
>>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom@niftybox.net> 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:
>>>>>>>>
>>>>>>>>
>>>>>>>>=C2=A0 =C2=A0https://www.truthcoin.info/blog/pow-cheapest/ >>>>>>>>=C2=A0 =C2=A0 =C2=A0"Nothing is Cheape= r than Proof of Work"
>>>>>>>>=C2=A0 =C2=A0 =C2=A0on | 04 Aug 2015
>>>>>>>>
>>>>>>>
>>>>>>> Just to belabor this a bit, the paper demonstr= ates that the mining market will tend to expend resources equivalent to min= er reward.=C2=A0 It does not prove that mining work has to expend *energy* = as a primary cost.
>>>>>>>
>>>>>>> Some might argue that energy expenditure has n= egative externalities and that we should move to other resources.=C2=A0 I w= ould argue that the negative externalities will go away soon because of the= move to renewables, so the point is likely moot.
>>>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@l= ists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.l= inuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfounda= tion.org
> = https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--00000000000058d4fc05bd447449--