Return-Path: <loneroassociation@gmail.com> Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A7EF8C0001 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 8 Mar 2021 23:41:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A2C1140149 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 8 Mar 2021 23:41:04 +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 IRKN7NtVUGff for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 8 Mar 2021 23:41:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by smtp2.osuosl.org (Postfix) with ESMTPS id C2A7B4013B for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 8 Mar 2021 23:41:02 +0000 (UTC) Received: by mail-yb1-xb2f.google.com with SMTP id c131so11996422ybf.7 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 08 Mar 2021 15:41:02 -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=97Ziy2tW41ZOPMJqPFzgj7k4KfEH3M6vJttpMCaxyEI=; b=toyrsE79ynDoYpU+N2eaLMZ1zTvmmexBHsvHC1P7XJTAz+uTd/v4O6RkOdJ60M0liZ BX/379rKs+1+v8jAuVH5K4xnaaA/P/24lNXYagAYGFerMmxKm+/o3NTyFt3bI3ulFhMW Z01Zze5h6JW+qUjqsS3J94912kPxmWjF/cJpGR2p9FyfiA9fkGhOaTqWyFkmPEqTmnqX q0fe7sRHNanmtkh2Me59ixZxbg+DXAM6Q+QHU3s6R3qnytU5Kg4zw/89NRLwtiQiDEz9 dKMTxlCYlJwN9BDJOeIWOYzyuSL5xh/LPP0MpHU+uUysqgaap7xXrJd3Yx+qjRqZiy6d j/9w== 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=97Ziy2tW41ZOPMJqPFzgj7k4KfEH3M6vJttpMCaxyEI=; b=lxz+mFRlK+2yFQBy496He3yL74SmepGmxCbvUIbCsTMOig3G+14bXXuoIJic8X5X2f w7oQi66mHXj94EC5knqzz29IWChybmKr4XN9TGbD7v7Rn+0VbkVh+V5HKkNJn21b/caM ckoDAN8t+neaoEdsqs9DRp07esVTQ9HfMYKCePUZwFTtpCAfT9zRw7/PyhnMXxUBPtFC NO8tWwCsTKcvIBF4cIJs1BSnBOpIoe671Wq5nvXqd9xXhFDALsTSC5ookCRj/abUL4Fk ijXueIk8afaQfkV8Y/TxPxVkYu8MGFjtJMzasFEUESgf//QN22SSSZ+puHkGUmTmIGVI P/SA== X-Gm-Message-State: AOAM531muOQHyIsjBPOQvK/M8nWwJGxMK3pjJb3aJ3clEOQ1At2QmcmD lTPe/h7wgYfTHeMNgli16SJpnjO/WHwWLN9417280ERl X-Google-Smtp-Source: ABdhPJxIa0DQ5b/vzUbBTsrWHBZRiopO8mqtgvBFDbp5UXnzKJYEL1PCC0yp2XYKgFEo7Da0xMJKb4xBJoJjEFXGq+0= X-Received: by 2002:a25:d843:: with SMTP id p64mr35236196ybg.339.1615246861491; Mon, 08 Mar 2021 15:41:01 -0800 (PST) MIME-Version: 1.0 References: <CA+YkXXxUdZFYTa1c-F=-FzoQQVtV3GUmE2Okec-zRAD3xS1qAQ@mail.gmail.com> <CAMnpzfop8ttqjMAKoS37zpQV6WiZfi1Bn+y_e-HaepTiD4Vm1Q@mail.gmail.com> <CAB0O3SVNyr_t23Y0LyT0mSaf6LONFRLYJ8qzO7rcdJFnrGccFw@mail.gmail.com> <CA+YkXXwkSCu=2UOEhzFBzGDHo1c=Ewqsnxp632ke3jdH1ff5WA@mail.gmail.com> <CA+YkXXwfS7eer5Za_ed9tCNdfOp4c3nV_X=mfXzoDxMm6BrizQ@mail.gmail.com> <CALeFGL31M5DAULLRtCwjPYHaPVqsVqREUg6WQ2-cuj23SNk=BA@mail.gmail.com> <CA+YkXXwBMG6YUAhf-2U5EV5Ep5RgG2foc9chramNFN5=AQ=-EA@mail.gmail.com> <CALeFGL3E-rWW9aJkwre_3UF44vbNxPH2436DvaQdHoqEQ5b+eg@mail.gmail.com> <CA+YkXXyBmOootb=Kt6CH3yquYVnAZd=fJQqiF_A3p_pkB8QC3g@mail.gmail.com> <CALC81CMDQf4PqxRisQw58OL7QSFeMcQTvLMvmtOGJ_ya4-dhLg@mail.gmail.com> <CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com> In-Reply-To: <CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com> From: Lonero Foundation <loneroassociation@gmail.com> Date: Mon, 8 Mar 2021 18:40:50 -0500 Message-ID: <CA+YkXXw1AiMqCoPk_pUOdDMfkGF_T+aURGAjGK=MTa7jtAQchg@mail.gmail.com> To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary="0000000000006764e105bd0ef725" X-Mailman-Approved-At: Tue, 09 Mar 2021 08:25:34 +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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Mon, 08 Mar 2021 23:41:04 -0000 --0000000000006764e105bd0ef725 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, here is the list to the BIP proposal on my own repo: https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawi= ki 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 want to work on. Best regards, Andrew On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <loneroassociation@gmail.co= m> 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 <ricardojdfilipe@gmail.com> > 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 >> <bitcoin-dev@lists.linuxfoundation.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 troubl= e >> 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 ab= le >> 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 pul= l >> 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 wa= y >> 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 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 < >> 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_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 fro= m 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 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 stakin= g. >> >>> >> 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 4:11 PM Keagan McClelland < >> keagan.mcclelland@gmail.com> wrote: >> >>>> >> >>>> It is important to understand that it is critical for the work to b= e >> "useless" in order for the security model to be the same. If the work wa= s >> useful it provides an avenue for actors to have nothing at stake when >> submitting a proof of work, since the marginal cost of block constructio= n >> will be lessened by the fact that the work was useful in a different >> context and therefore would have been done anyway. This actually degrade= s >> 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 mining >> entities and disincentivize future capital expenditure into mining hardw= are >> 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 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 >> "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 tack= les >> 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 s= uch >> as bigger block height have been proposed as hard forks, I feel at the v= ery >> least an upgrade regarding the hashing algorithm and cryptography does a= t >> least warrant some discussion. Anyways I hope I can send you my BIP, jus= t >> 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 arbitrarine= ss >> 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.ne= t> >> 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 cost= . >> >>>>>>> >> >>>>>>> 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. >> >>>>>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> > --0000000000006764e105bd0ef725 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Hi, here is the list to the BIP proposal on my own repo: = <a href=3D"https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-dr= aft.mediawiki">https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bi= p-draft.mediawiki</a><div dir=3D"auto">Can I submit a pull request on the B= IPs repo for this to go into draft mode? Also, I think this provides at lea= st some more insight on what I want to work on.</div><div dir=3D"auto"><br>= </div><div dir=3D"auto">Best regards, Andrew</div></div><br><div class=3D"g= mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 6, 2021, 10:4= 2 AM Lonero Foundation <<a href=3D"mailto:loneroassociation@gmail.com">l= oneroassociation@gmail.com</a>> wrote:<br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef= t:1ex"><div dir=3D"auto"><div dir=3D"auto">[off-list]</div><div dir=3D"auto= "><br></div>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=C2=A0it.<= div dir=3D"auto"><br></div><div dir=3D"auto">Best regards, Andrew</div></di= v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S= at, Mar 6, 2021, 10:21 AM Ricardo Filipe <<a href=3D"mailto:ricardojdfil= ipe@gmail.com" target=3D"_blank" rel=3D"noreferrer">ricardojdfilipe@gmail.c= om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As said before, y= ou are free to create the BIP in your own repository<br> and bring it to discussion on the mailing list. then you can do a PR<br> <br> Lonero Foundation via bitcoin-dev<br> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefer= rer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>= > escreveu no dia s=C3=A1bado,<br> 6/03/2021 =C3=A0(s) 08:58:<br> ><br> > 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.<br> ><br> > 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.<br> ><br> > 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.<br> ><br> > Does that seem fine?<br> ><br> > Best regards, Andrew<br> ><br> > On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland <<a href=3D"mailto:k= eagan.mcclelland@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank"= >keagan.mcclelland@gmail.com</a>> wrote:<br> >><br> >> > 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.<br> >><br> >> My instincts tell me that this is an outlandish claim. Do you have= supporting evidence for this?<br> >><br> >> Keagan<br> >><br> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev &= lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferr= er noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&= gt; wrote:<br> >>><br> >>> 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.<br> >>> There is a way to make PoC cryptographically compatible w/ Pro= of of Work as it normally stands: <a href=3D"https://en.wikipedia.org/wiki/= Proof_of_space" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">= https://en.wikipedia.org/wiki/Proof_of_space</a><br> >>> 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.<br> >>><br> >>> 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."<br> >>><br> >>> 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.<br> >>><br> >>> 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 :)<br> >>><br> >>> 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= .<br> >>> <a href=3D"https://hackernoon.com/ethereum-you-are-a-centraliz= ed-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl" rel=3D"noreferre= r noreferrer noreferrer" target=3D"_blank">https://hackernoon.com/ethereum-= you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yj= l</a><br> >>><br> >>> Best regards,=C2=A0 Andrew<br> >>><br> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <<a href= =3D"mailto:keagan.mcclelland@gmail.com" rel=3D"noreferrer noreferrer" targe= t=3D"_blank">keagan.mcclelland@gmail.com</a>> wrote:<br> >>>><br> >>>> 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.<br> >>>><br> >>>> 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.<br> >>>><br> >>>> All of these things make the Bitcoin network worse off.<br= > >>>><br> >>>> Keagan<br> >>>><br> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitco= in-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"= noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.= org</a>> wrote:<br> >>>>><br> >>>>> 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?<br> >>>>><br> >>>>> Best regards, Andrew<br> >>>>><br> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <<a= href=3D"mailto:loneroassociation@gmail.com" rel=3D"noreferrer noreferrer" = target=3D"_blank">loneroassociation@gmail.com</a>> wrote:<br> >>>>>><br> >>>>>> 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?<br> >>>>>><br> >>>>>> Best regards, Andrew<br> >>>>>><br> >>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <<a hre= f=3D"mailto:c1.devrandom@niftybox.net" rel=3D"noreferrer noreferrer" target= =3D"_blank">c1.devrandom@niftybox.net</a>> wrote:<br> >>>>>>><br> >>>>>>> Hi Ryan and Andrew,<br> >>>>>>><br> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via = bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" re= l=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfounda= tion.org</a>> wrote:<br> >>>>>>>><br> >>>>>>>><br> >>>>>>>>=C2=A0 =C2=A0<a href=3D"https://www.truthco= in.info/blog/pow-cheapest/" rel=3D"noreferrer noreferrer noreferrer" target= =3D"_blank">https://www.truthcoin.info/blog/pow-cheapest/</a><br> >>>>>>>>=C2=A0 =C2=A0 =C2=A0"Nothing is Cheape= r than Proof of Work"<br> >>>>>>>>=C2=A0 =C2=A0 =C2=A0on | 04 Aug 2015<br> >>>>>>>><br> >>>>>>><br> >>>>>>> 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.<br> >>>>>>><br> >>>>>>> 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.<br> >>>>>>><br> >>>>> _______________________________________________<br> >>>>> bitcoin-dev mailing list<br> >>>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or= g" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxf= oundation.org</a><br> >>>>> <a href=3D"https://lists.linuxfoundation.org/mailman/l= istinfo/bitcoin-dev" rel=3D"noreferrer noreferrer noreferrer" target=3D"_bl= ank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> >>><br> >>> _______________________________________________<br> >>> bitcoin-dev mailing list<br> >>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel= =3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundat= ion.org</a><br> >>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/= bitcoin-dev" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">htt= ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> ><br> > _______________________________________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefe= rrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a= ><br> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lis= ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> </blockquote></div> </blockquote></div> --0000000000006764e105bd0ef725--