From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 456BAC0001 for ; Fri, 12 Mar 2021 23:58:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 20324605EB for ; Fri, 12 Mar 2021 23:58:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVXxBSbdnOVh for ; Fri, 12 Mar 2021 23:58:36 +0000 (UTC) X-Greylist: delayed 01:04:11 by SQLgrey-1.8.0 Received: from mslow2.mail.gandi.net (mslow2.mail.gandi.net [217.70.178.242]) by smtp3.osuosl.org (Postfix) with ESMTPS id 73FDD605E7 for ; Fri, 12 Mar 2021 23:58:36 +0000 (UTC) Received: from relay7-d.mail.gandi.net (unknown [217.70.183.200]) by mslow2.mail.gandi.net (Postfix) with ESMTP id AFD383B0EAC for ; Fri, 12 Mar 2021 22:37:29 +0000 (UTC) X-Originating-IP: 10.200.201.51 Received: from sogo1.sd4.0x35.net (sogo1.sd4.0x35.net [10.200.201.51]) (Authenticated sender: email@yancy.lol) by relay7-d.mail.gandi.net (Postfix) with ESMTPA id ED6C820002; Fri, 12 Mar 2021 22:37:23 +0000 (UTC) From: "email@yancy.lol" In-Reply-To: Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-15717-1615588643.600866-100------" X-Forward: 127.0.0.1 Date: Fri, 12 Mar 2021 23:37:23 +0100 To: "Lonero Foundation" , "Bitcoin Protocol Discussion" MIME-Version: 1.0 Message-ID: <3d65-604bed00-17d-6093c680@171273340> User-Agent: SOGoMail 5.0.1 X-Mailman-Approved-At: Sat, 13 Mar 2021 22:53:20 +0000 Subject: Re: [bitcoin-dev] =?utf-8?q?BIP_Proposal=3A_Consensus_=28hard_fork=29?= =?utf-8?q?_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, 12 Mar 2021 23:58:39 -0000 ------=_=-_OpenGroupware_org_NGMime-15717-1615588643.600866-100------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 13815 I think Andrew himself is an algo.=C2=A0 The crypto training set must n= ot be very good. Cheers, -Yancy On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev = wrote: =C2=A0Hi, I awkwardly phrased that part, I was referring to key validat= ion in relation to that section as well as the hashing related to those= keys. I might rephrase it.=C2=A0=C2=A0In regards to technical merit, t= he main purpose of the BIP is to get a sense of the idea. Once I get as= signed a BIP draft #, I am willing to follow it up with many preprints = or publications to go in the references implementation section and star= t dev work before upgrading to final status.=C2=A0This will take about = 400 hours of my time, but is something I am personally looking into dev= eloping as a hard fork.=C2=A0Keep in mind this is a draft, so after it = is assigned a number to references I do at the very least hope to descr= ibe various parts of the cryptographic proofs and algorithmic structure= I am hoping for.=C2=A0Best regards, Andrew=C2=A0On Fri, Mar 12, 2021, = 10:03 AM Erik Aronesty wrote:secp236k1 isn't a hashing a= lgo.=C2=A0 =C2=A0your BIP needs about 10 more pages and some degree of technical merit. i suggest you start here: https://en.bitcoin.it/wiki/Proof=5Fof=5Fburn https://bitcointalk.org/index.php?topic=3D225690.0 proof-of-burn is a nice alternative to proof-of-work.=C2=A0 =C2=A0i alw= ays suspected that, if designed correctly, it could be a proven equivalent.=C2=A0 =C2=A0you could spin up a fork of bitcoin that allows= aged, burned, coins instead of POW that would probably work just fine. - erik On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundation via bitcoin-dev wrote: > > Hi, I have submitted the BIP Pull Request here: https://github.com/bi= tcoin/bips/pull/1084 > > Hoping to receive a BIP # for the draft prior to development/referenc= e 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://git= hub.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki >> Can I submit a pull request on the BIPs repo for this to go into dra= ft 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 wrote: >>> >>> [off-list] >>> >>> Okay. I will do so and post the link here for discussion before doi= ng 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 reposit= ory >>>> 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=A1bad= o, >>>> 6/03/2021 =C3=A0(s) 08:58: >>>> > >>>> > I know Ethereum had an outlandishly large percentage of nodes ru= nning on AWS, I heard the same thing is for Bitcoin but for mining. Had= trouble finding the article online so take it with a grain of salt. Th= e point though is that both servers and ASIC specific hardware would st= ill be able 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 B= IP 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. Th= at way people don't have to get emails everytime there is a reply, but = replies still get seen as opposed to offline discussion. Since the inst= ructions 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 merge= d manually anyways, I think it is the easiest way to handle this. >>>> > >>>> > I'm also okay w/ continuing the discussion on bitcoin-dev but ra= ther form a discussion on git instead given I don't want to accidentall= y impolitely bother people given this is a moderated list and we alread= y 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 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= from a hybrid proof, and the fact that it is hybrid in that manner wou= ldn't disenfranchise currently optimized mining entities as well. >>>> >> >>>> >> My instincts tell me that this is an outlandish claim. Do you h= ave supporting evidence for this? >>>> >> >>>> >> Keagan >>>> >> >>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-de= v 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/ Pro= of of Work as it normally stands: https://en.wikipedia.org/wiki/Proof=5F= of=5Fspace >>>> >>> 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 look= ed into numerous fault tolerant designs as well and what others in the = cryptography community attempted to propose. The actual argument you ha= ve only against this is the Proof of Memory fallacy, which is only part= ially true. Given how the current hashing algorithm works, hard memory = allocation wouldn't be of much benefit given it is more optimized for C= PU/ASIC specific mining. I'm working towards a hybrid mechanism that fi= xes that. BTW: The way Bitcoin currently stands in its cryptography sti= ll 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 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 comp= lexity in regards to the hybrid cryptography I'm aiming to provide whic= h includes a polynomial time algorithm in the cryptography. More than l= ikely the first version of my BTC hard fork will be coded in a way wher= e integrating such complexity in the future only requires a soft fork o= r 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 cap= ital expenditure into mining hardware that may compute these more "usef= ul" 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 woul= dn'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 b= roken. My goal outside of efficiency is to build cryptography in a way = that prevents 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 a= lot with distributed computing. I believe if the BTC community likes su= ch a proposal, I would single handedly be able to build the cryptograph= ic 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 sta= king. >>>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocu= rrency-stop-telling-us-that-you-arent-pi3s3yjl >>>> >>> >>>> >>> Best regards,=C2=A0 Andrew >>>> >>> >>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland wrote: >>>> >>>> >>>> >>>> It is important to understand that it is critical for the wor= k to be "useless" in order for the security model to be the same. If th= e work was useful it provides an avenue for actors to have nothing at s= take 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= different context and therefore would have been done anyway. This actu= ally degrades the security of the network in the process. >>>> >>>> >>>> >>>> As a separate issue, proposing a hard fork in the hashing alg= orithm will invalidate the enormous amount of capital expenditure by mi= ning entities and disincentivize future capital expenditure into mining= hardware that may compute these more "useful" proofs of work. This is = because any 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 o= f the bitcoin network at large. It also puts the developers in a positi= on where they can be bribed by entities with a vested interest in decid= ing 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 wrote: >>>> >>>>> >>>> >>>>> Also in regards to my other email, I forgot to iterate that = my cryptography proposal helps behind the efficiency category but also = tackles problems such as NP-Completeness or Halting which is something = the BTC network could be vulnerable to in the future. For sake of simpl= icity, I do want to do this BIP because it tackles lots of the issues i= n regards to this manner and can provide useful insight to the communit= y. If things such as bigger block height have been proposed as hard for= ks, 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, just let me know on the preferred format? >>>> >>>>> >>>> >>>>> Best regards, Andrew >>>> >>>>> >>>> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation wrote: >>>> >>>>>> >>>> >>>>>> Hi, this isn't about the energy efficient argument in regar= ds to renewables or mining devices but a better cryptography layer to g= et the most out of your hashing for validation. I do understand the arb= itrariness 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 = wrote: >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>>=C2=A0 =C2=A0https://www.truthcoin.info/blog/pow-cheapest/= >>>> >>>>>>>>=C2=A0 =C2=A0 =C2=A0"Nothing is Cheaper than Proof of Work= " >>>> >>>>>>>>=C2=A0 =C2=A0 =C2=A0on | 04 Aug 2015 >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>>> Just to belabor this a bit, the paper demonstrates that th= e mining market will tend to expend resources equivalent to miner rewar= d.=C2=A0 It does not prove that mining work has to expend *energy* as a= primary cost. >>>> >>>>>>> >>>> >>>>>>> Some might argue that energy expenditure has negative exte= rnalities and that we should move to other resources.=C2=A0 I would arg= ue that the negative externalities will go away soon because of the mov= e to renewables, so the point is likely moot. >>>> >>>>>>> >>>> >>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F >>>> >>>>> bitcoin-dev mailing list >>>> >>>>> bitcoin-dev@lists.linuxfoundation.org >>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d= ev >>>> >>> >>>> >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F >>>> >>> bitcoin-dev mailing list >>>> >>> bitcoin-dev@lists.linuxfoundation.org >>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev= >>>> > >>>> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F >>>> > bitcoin-dev mailing list >>>> > bitcoin-dev@lists.linuxfoundation.org >>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =C2=A0 ------=_=-_OpenGroupware_org_NGMime-15717-1615588643.600866-100------ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 20868 I think Andrew himself is an algo.  The crypto training set = must not be very good.

Cheers,
-Yancy

On Fri= day, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:
 
Hi, I awkwardly phrased that = part, I was referring to key validation in relation to that section as = well as the hashing related to those keys. I might rephrase it.  
In regards to technical m= erit, the main purpose of the BIP is to get a sense of the idea. Once I= get assigned a BIP draft #, I am willing to follow it up with many pre= prints or publications to go in the references implementation section a= nd start dev work before upgrading to final status.
 
This will take about 400 hours of my = time, but is something I am personally looking into developing as a har= d fork.
 
Keep in mi= nd this is a draft, so after it is assigned a number to references I do= at the very least hope to describe various parts of the cryptographic = proofs and algorithmic structure I am hoping for.
 
Best regards, Andrew
 <= div class=3D"gmail=5Fquote">
On = Fri, Mar 12, 2021, 10:03 AM Erik Aronesty <erik@q32.com> wrote:
secp236k1 isn't a hashing algo.   your BIP needs about = 10 more pages
and some degree of technical merit.

i sug= gest you start here:

htt= ps://en.bitcoin.it/wiki/Proof=5Fof=5Fburn
https://bitcointalk.org/index.php?topic=3D225690.= 0

proof-of-burn is a nice alternative to proof-of-work.&= nbsp;  i always
suspected that, if designed correctly, it cou= ld be a proven
equivalent.   you could spin up a fork of= bitcoin that allows aged,
burned, coins instead of POW that would= probably work just fine.

- erik

On Thu, Mar 11, = 2021 at 11:56 AM Lonero Foundation via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
= >
> 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 dev= elopment/reference implementation.
>
> Best regards, An= drew
>
> 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/main/bip-draft= .mediawiki
>> Can I submit a pull request on the BIPs re= po for this to go into draft mode? Also, I think this provides at least= some more insight on what I want to work on.
>>
>&g= t; 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 he= re for discussion before doing a pull request on BIP's repo as the best= way to handle it.
>>>
>>> Best regards, An= drew
>>>
>>> On Sat, Mar 6, 2021, 10:21 AM = Ricardo Filipe <ricardojdfilipe@gmail.com> wrote= :
>>>>
>>>> As said before, you are f= ree to create the BIP in your own repository
>>>> and = bring it to discussion on the mailing list. then you can do a PR
&= gt;>>>
>>>> Lonero Foundation via bitcoin-dev=
>>>> <bitcoin-dev@lists.l= inuxfoundation.org> escreveu no dia s=C3=A1bado,
>>&g= t;> 6/03/2021 =C3=A0(s) 08:58:
>>>> >
>&= gt;>> > I know Ethereum had an outlandishly large percentage o= f nodes running on AWS, I heard the same thing is for Bitcoin but for m= ining. Had trouble finding the article online so take it with a grain o= f salt. The point though is that both servers and ASIC specific hardwar= e would still be able to benefit from the cryptography upgrade I am pro= posing, as this was in relation to the disinfranchisemet point.
&g= t;>>> >
>>>> > That said, I think the b= est 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 b= e answered in the reqeust's comments. That way people don't have to get= emails everytime there is a reply, but replies still get seen as oppos= ed to offline discussion. Since the instructions say to email bitcoin-d= ev 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 an= d we already established some interest for at least a draft.
>&= gt;>> >
>>>> > Does that seem fine?
&= gt;>>> >
>>>> > 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 serv= ers and non-asic specific hardware anyways. A majority of them would be= nefit from a hybrid proof, and the fact that it is hybrid in that manne= r wouldn't disenfranchise currently optimized mining entities as well.<= br />>>>> >>
>>>> >> My instin= cts tell me that this is an outlandish claim. Do you have supporting ev= idence for this?
>>>> >>
>>>> &= gt;> Keagan
>>>> >>
>>>> >= ;> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:
>>>> >>>
>>>> >= ;>> Actually I mentioned a proof of space and time hybrid which i= s much different than staking. Sorry to draw for the confusion as PoC i= s more commonly used then PoST.
>>>> >>> Ther= e is a way to make PoC cryptographically compatible w/ Proof of Work as= it normally stands: https://en= .wikipedia.org/wiki/Proof=5Fof=5Fspace
>>>> >&g= t;> It has rarely been done though given the technological complexit= y of being both CPU compatible and memory-hard compatible. There are lo= ts of benefits outside of the realm of efficiency, and I already looked= into numerous fault tolerant designs as well and what others in the cr= yptography community attempted to propose. The actual argument you have= only against this is the Proof of Memory fallacy, which is only partia= lly true. Given how the current hashing algorithm works, hard memory al= location wouldn't be of much benefit given it is more optimized for CPU= /ASIC specific mining. I'm working towards a hybrid mechanism that fixe= s that. BTW: The way Bitcoin currently stands in its cryptography still= needs updating regardless. If someone figures out NP hardness or the h= alting problem the traditional rule of millions of years to break all o= f Bitcoin's cryptography now comes down to minutes. Bitcoin is going to= have to eventually radically upgrade their cryptography and hashing al= go in the future regardless. I want to integrate some form of NP comple= xity in regards to the hybrid cryptography I'm aiming to provide which = includes a polynomial time algorithm in the cryptography. More than lik= ely the first version of my BTC hard fork will be coded in a way where = integrating such complexity in the future only requires a soft fork or = minor upgrade to its chain.
>>>> >>>
>= ;>>> >>> In regards to the argument, "As a separate i= ssue, proposing a hard fork in the hashing algorithm will invalidate th= e enormous amount of capital expenditure by mining entities and disince= ntivize future capital expenditure into mining hardware that may comput= e these more "useful" proofs of work."
>>>> >>&g= t;
>>>> >>> A large portion of BTC is already= mined through AWS servers and non-asic specific hardware anyways. A ma= jority of them would benefit from a hybrid proof, and the fact that it = is hybrid in that manner wouldn't disenfranchise currently optimized mi= ning entities as well.
>>>> >>>
>>= >> >>> There are other reasons why a cryptography upgrad= e like this is beneficial. Theoretically one can argue BItcoin isn't fu= lly decentralized. It is few unsolved mathematical proofs away from bei= ng entirely broken. My goal outside of efficiency is to build cryptogra= phy in a way that prevents such an event from happening in the future, = 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 commu= nity likes such a proposal, I would single handedly be able to build th= e cryptographic proof myself (though would like as many open source con= tributors as I can get :)
>>>> >>>
>&= gt;>> >>> Anyways just something to consider. We are in = the same space in regards to what warrants a shitcoin or the whole argu= ment against staking.
>>>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cr= yptocurrency-stop-telling-us-that-you-arent-pi3s3yjl
>>&= gt;> >>>
>>>> >>> Best regards,&n= bsp; Andrew
>>>> >>>
>>>> &g= t;>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <keagan.mcclelland@gmail.com> wrote:
>>>>= ; >>>>
>>>> >>>> It is importa= nt to understand that it is critical for the work to be "useless" in or= der for the security model to be the same. If the work was useful it pr= ovides an avenue for actors to have nothing at stake when submitting a = proof of work, since the marginal cost of block construction will be le= ssened by the fact that the work was useful in a different context and = therefore would have been done anyway. This actually degrades the secur= ity of the network in the process.
>>>> >>>&g= t;
>>>> >>>> As a separate issue, proposin= g a hard fork in the hashing algorithm will invalidate the enormous amo= unt of capital expenditure by mining entities and disincentivize future= capital expenditure into mining hardware that may compute these more "= useful" proofs of work. This is because any 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 tyi= ng their own interests to that of the bitcoin 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 o= ff.
>>>> >>>>
>>>> >&g= t;>> Keagan
>>>> >>>>
>>&= gt;> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundati= on via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org> wrote:
>>>> >>>>>=
>>>> >>>>> Also in regards to my other= email, I forgot to iterate that my cryptography proposal helps behind = the efficiency category but also tackles problems such as NP-Completene= ss 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 becaus= e it tackles lots of the issues in regards to this manner and can provi= de useful insight to the community. If things such as bigger block heig= ht have been proposed as hard forks, I feel at the very least an upgrad= e regarding the hashing algorithm and cryptography does at least warran= t some discussion. Anyways I hope I can send you my BIP, just let me kn= ow on the preferred format?
>>>> >>>>><= br />>>>> >>>>> Best regards, Andrew
&g= t;>>> >>>>>
>>>> >>>&= gt;> 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 renewabl= es or mining devices but a better cryptography layer to get the most ou= t of your hashing for validation. I do understand the arbitrariness of = it, but do want to still propose a document. Do I use the Media Wiki fo= rmat on GitHub and just attach it as my proposal?
>>>>= >>>>>>
>>>> >>>>>>= ; Best regards, Andrew
>>>> >>>>>>>>>> >>>>>> On Fri, Mar 5, 2021, 10:0= 7 AM Devrandom <c1.devrandom@niftybox.net> wrote= :
>>>> >>>>>>>
>>>&= gt; >>>>>>> Hi Ryan and Andrew,
>>>&= gt; >>>>>>>
>>>> >>>>= >>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org&= gt; wrote:
>>>> >>>>>>>>
= >>>> >>>>>>>>
>>>>= >>>>>>>>   https://www.truthcoin.info/blog/pow-cheapest/
>= >>> >>>>>>>>     "Nothi= ng is Cheaper than Proof of Work"
>>>> >>>>= ;>>>>     on | 04 Aug 2015
>>>= > >>>>>>>>
>>>> >>>= ;>>>>
>>>> >>>>>>> Ju= st to belabor this a bit, the paper demonstrates that the mining market= will tend to expend resources equivalent to miner reward.  It doe= s not prove that mining work has to expend *energy* as a primary cost.<= br />>>>> >>>>>>>
>>>>= ; >>>>>>> Some might argue that energy expenditure= has negative externalities and that we should move to other resources.=   I would argue that the negative externalities will go away soon = because of the move to renewables, so the point is likely moot.
&g= t;>>> >>>>>>>
>>>> >&= gt;>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F
>>>> >>>>> bitcoin-dev mai= ling list
>>>> >>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> = >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br />>>>> >>>
>>>> >>> =5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>>>> >>> bitcoin-dev mailing list
>>&g= t;> >>> bitcoin-dev@lists.linuxfou= ndation.org
>>>> >>> https://lists.linuxfoundation.org/mai= lman/listinfo/bitcoin-dev
>>>> >
>>&= gt;> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F
>>>> > bitcoin-dev mailing list
>= >>> > bitcoin-dev@lists.linuxfound= ation.org
>>>> > https://lists.linuxfoundation.org/mailman/listi= nfo/bitcoin-dev
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> bitcoin-dev mailing list=
> bitcoin-dev@lists.linuxfoundation.o= rg
> = https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



  ------=_=-_OpenGroupware_org_NGMime-15717-1615588643.600866-100--------