Return-Path: <email@yancy.lol> Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1D7D5C0001 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 08:13:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id F34334EC3B for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 08:13:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 o9OpforMjilM for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 08:13:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) by smtp4.osuosl.org (Postfix) with ESMTPS id 26C7A4EC3A for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 08:13:28 +0000 (UTC) Received: from sogo1.sd4.0x35.net (sogo1.sd4.0x35.net [10.200.201.51]) (Authenticated sender: email@yancy.lol) by relay12.mail.gandi.net (Postfix) with ESMTPA id 9B5A4200004; Sat, 13 Mar 2021 08:13:25 +0000 (UTC) From: "email@yancy.lol" <email@yancy.lol> In-Reply-To: <CA+YkXXw5uh4yfvqDiBBEXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com> Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------" X-Forward: 127.0.0.1 Date: Sat, 13 Mar 2021 09:13:25 +0100 To: "Lonero Foundation" <loneroassociation@gmail.com> MIME-Version: 1.0 Message-ID: <1802-604c7400-4d1-7b635e80@91248813> User-Agent: SOGoMail 5.0.1 X-Mailman-Approved-At: Sat, 13 Mar 2021 22:53:20 +0000 Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 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 <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: Sat, 13 Mar 2021 08:13:33 -0000 ------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 16332 My email was not intended as an insult.=C2=A0 Your proposal seemed a bi= t like gibberish and made some obvious mistakes as pointed out before (= such as conflating secp256k1 with sha256), and so I was genuinely curio= us if you were a bot spamming the list.=C2=A0 Maybe a more interesting topic is, can GPT3 be used to generate a BIP?=C2= =A0 How long before our AI overlord produces improvements to Bitcoin?=C2= =A0 At what point will the AI have more than 51% of commit frequency?=C2= =A0 Will we have lost the war to our new centralized overlord? Cheers, -Yancy On Saturday, March 13, 2021 00:31 CET, Lonero Foundation <loneroassocia= tion@gmail.com> wrote: =C2=A0Also, I already stated I was referring to signature validation cr= yptography in that aspect: https://wizardforcel.gitbooks.io/practical-c= ryptography-for-developers-book/content/digital-signatures/ecdsa-sign-v= erify-examples.htmlMy BIP has a primary purpose in regards to what I wa= nt to develop proofs for and the different cryptographic elements I wan= t to develop proofs for.That said to those who disagree with the premis= e, I do prefer constructive feedback over insults or making fun of one = another. After all this is an improvement proposal with a specific purp= ose aiming to develop a specific thing, not a guy who is just wanting t= o copy and paste a repository and call it a day.=C2=A0Best regards, And= rew=C2=A0On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation <loneroassoc= iation@gmail.com> wrote:Hi, I also want to emphasize that my main point= isn't just to create a BTC hardfork or become another Bitcoin Cash, Go= ld, or SV. The main point in regards to this BIP actually expands POW r= ather than replaces or creates an alternative. Many of the problems fac= ed in regards to security in the future as well as sustainability is so= mething I believe lots of the changes I am proposing can fix. In regard= s to technological implementation, once this is assigned draft status I= am more than willing to create preprints explaining the cryptography, = hashing algorithm improvements, and consensus that I am working on. Thi= s is a highly technologically complex idea that I am willing to "call m= y bluff on" and expand upon. As for it being a draft, I think this is a= good starting point at least for draft status prior to working on tech= nological implementation.=C2=A0Best regards, Andrew=C2=A0On Fri, Mar 12= , 2021 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote:I think Andre= w himself is an algo.=C2=A0 The crypto training set must not be very go= od. Cheers, -Yancy On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> 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 <erik@q32.com> 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 <bitcoin-dev@lists.linuxfoundation.org> 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 <loneroassociation@gma= il.com> 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 <loneroassociation@g= mail.com> 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 <ricardojdfilipe@gmail= .com> 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 >>>> <bitcoin-dev@lists.linuxfoundation.org> 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 <keagan.mcclellan= d@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= 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 <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/ 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 <keagan.mccle= lland@gmail.com> 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 <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 = 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 <loneroassoc= iation@gmail.com> 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 <c1.devrandom@nifty= box.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 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 =C2=A0 ------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 25217 <html><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bo= ttom:0pt;" id=3D"docs-internal-guid-4056a8b1-7fff-9296-3427-4d2e04c785c= 7"><span style=3D"font-size: 11pt; font-family: Arial; background-color= : transparent; font-weight: 400; font-style: normal; font-variant: norm= al; text-decoration: none; vertical-align: baseline; white-space: pre-w= rap;">My email was not intended as an insult. Your proposal seeme= d a bit like gibberish and made some obvious mistakes as pointed out be= fore (such as conflating secp256k1 with sha256), and so I was genuinely= curious if you were a bot spamming the list.</span></p> <p dir=3D= "ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><spa= n style=3D"font-size: 11pt; font-family: Arial; background-color: trans= parent; font-weight: 400; font-style: normal; font-variant: normal; tex= t-decoration: none; vertical-align: baseline; white-space: pre-wrap;">M= aybe a more interesting topic is, can GPT3 be used to generate a BIP?&n= bsp; How long before our AI overlord produces improvements to Bitcoin?&= nbsp; At what point will the AI have more than 51% of commit frequency?= Will we have lost the war to our new centralized overlord?</span= ></p><br />Cheers,<br />-Yancy<br /><br /><br />On Saturday, March 13, = 2021 00:31 CET, Lonero Foundation <loneroassociation@gmail.com> w= rote:<br /> <blockquote type=3D"cite" cite=3D"CA+YkXXw5uh4yfvqDiBB= EXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com"><div dir=3D"ltr"><div>A= lso, I already stated I was referring to signature validation cryptogra= phy in that aspect: <a href=3D"https://wizardforcel.gitbooks.io/practic= al-cryptography-for-developers-book/content/digital-signatures/ecdsa-si= gn-verify-examples.html">https://wizardforcel.gitbooks.io/practical-cry= ptography-for-developers-book/content/digital-signatures/ecdsa-sign-ver= ify-examples.html</a></div><div>My BIP has a primary purpose in regards= to what I want to develop proofs for and the different cryptographic e= lements I want to develop proofs for.</div><div>That said to those who = disagree with the premise, I do prefer constructive feedback over insul= ts or making fun of one another. After all this is an improvement propo= sal with a specific purpose aiming to develop a specific thing, not a g= uy who is just wanting to copy and paste a repository and call it a day= .</div><div> </div><div>Best regards, Andrew</div></div> <div= class=3D"gmail=5Fquote"><div dir=3D"ltr" class=3D"gmail=5Fattr">On Fri= , Mar 12, 2021 at 6:21 PM Lonero Foundation <<a href=3D"mailto:loner= oassociation@gmail.com">loneroassociation@gmail.com</a>> wrote:</div= ><blockquote class=3D"gmail=5Fquote" style=3D"margin:0px 0px 0px 0.8ex;= border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt= r"><div>Hi, I also want to emphasize that my main point isn't just to c= reate a BTC hardfork or become another Bitcoin Cash, Gold, or SV. The m= ain point in regards to this BIP actually expands POW rather than repla= ces or creates an alternative. Many of the problems faced in regards to= security in the future as well as sustainability is something I believ= e lots of the changes I am proposing can fix. In regards to technologic= al implementation, once this is assigned draft status I am more than wi= lling to create preprints explaining the cryptography, hashing algorith= m improvements, and consensus that I am working on. This is a highly te= chnologically complex idea that I am willing to "call my bluff on" and = expand upon. As for it being a draft, I think this is a good starting p= oint at least for draft status prior to working on technological implem= entation.</div><div> </div><div>Best regards, Andrew</div></div>&n= bsp;<div class=3D"gmail=5Fquote"><div dir=3D"ltr" class=3D"gmail=5Fattr= ">On Fri, Mar 12, 2021 at 5:37 PM email@yancy.lol <email@yancy.lol&g= t; wrote:</div><blockquote class=3D"gmail=5Fquote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">= I think Andrew himself is an algo. The crypto training set must n= ot be very good.<br /><br />Cheers,<br />-Yancy<br /><br />On Friday, M= arch 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev <<a targe= t=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi= tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br /> <blockquo= te type=3D"cite" cite=3D"http://CA+YkXXz9aHfZtt-it=5F8w4ovF=3D-QaZ4=5F9= vwDS0Kz36qhHwVDC5Q@mail.gmail.com"><div dir=3D"auto">Hi, I awkwardly ph= rased 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. <div dir=3D"auto"> </div><div dir=3D"auto">In regards to = technical merit, the main purpose of the BIP is to get a sense of the i= dea. Once I get assigned a BIP draft #, I am willing to follow it up wi= th many preprints or publications to go in the references implementatio= n section and start dev work before upgrading to final status.</div><di= v dir=3D"auto"> </div><div dir=3D"auto">This will take about 400 h= ours of my time, but is something I am personally looking into developi= ng as a hard fork.</div><div dir=3D"auto"> </div><div dir=3D"auto"= >Keep in mind this is a draft, so after it is assigned a number to refe= rences I do at the very least hope to describe various parts of the cry= ptographic proofs and algorithmic structure I am hoping for.</div><div = dir=3D"auto"> </div><div dir=3D"auto">Best regards, Andrew</div></= div> <div class=3D"gmail=5Fquote"><div dir=3D"ltr" class=3D"gmail=5F= attr">On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty <<a target=3D"=5F= blank" href=3D"mailto:erik@q32.com">erik@q32.com</a>> wrote:</div><b= lockquote class=3D"gmail=5Fquote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex">secp236k1 isn't a= hashing algo. your BIP needs about 10 more pages<br />and = some degree of technical merit.<br /><br />i suggest you start here:<br= /><br /><a rel=3D"noreferrer noreferrer" target=3D"=5Fblank" href=3D"h= ttps://en.bitcoin.it/wiki/Proof=5Fof=5Fburn">https://en.bitcoin.it/wiki= /Proof=5Fof=5Fburn</a><br /><a rel=3D"noreferrer noreferrer" target=3D"= =5Fblank" href=3D"https://bitcointalk.org/index.php?topic=3D225690.0">h= ttps://bitcointalk.org/index.php?topic=3D225690.0</a><br /><br />proof-= of-burn is a nice alternative to proof-of-work. i always<br= />suspected that, if designed correctly, it could be a proven<br />equ= ivalent. you could spin up a fork of bitcoin that allows ag= ed,<br />burned, coins instead of POW that would probably work just fin= e.<br /><br />- erik<br /><br />On Thu, Mar 11, 2021 at 11:56 AM Lonero= Foundation via bitcoin-dev<br /><<a rel=3D"noreferrer" target=3D"=5F= blank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de= v@lists.linuxfoundation.org</a>> wrote:<br />><br />> Hi, I ha= ve submitted the BIP Pull Request here: <a rel=3D"noreferrer noreferrer= " target=3D"=5Fblank" href=3D"https://github.com/bitcoin/bips/pull/1084= ">https://github.com/bitcoin/bips/pull/1084</a><br />><br />> Hop= ing to receive a BIP # for the draft prior to development/reference imp= lementation.<br />><br />> Best regards, Andrew<br />><br />&g= t; On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <<a rel=3D"norefer= rer" target=3D"=5Fblank" href=3D"mailto:loneroassociation@gmail.com">lo= neroassociation@gmail.com</a>> wrote:<br />>><br />>> Hi= , here is the list to the BIP proposal on my own repo: <a rel=3D"norefe= rrer noreferrer" target=3D"=5Fblank" href=3D"https://github.com/Mentors= 4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki">https://github.com= /Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki</a><br />&g= t;> 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.<br />>><br />>> Best regards, Andre= w<br />>><br />>> On Sat, Mar 6, 2021, 10:42 AM Lonero Foun= dation <<a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:lon= eroassociation@gmail.com">loneroassociation@gmail.com</a>> wrote:<br= />>>><br />>>> [off-list]<br />>>><br />>= ;>> Okay. I will do so and post the link here for discussion befo= re doing a pull request on BIP's repo as the best way to handle it.<br = />>>><br />>>> Best regards, Andrew<br />>>>= <br />>>> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe <<a = rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:ricardojdfilipe@g= mail.com">ricardojdfilipe@gmail.com</a>> wrote:<br />>>>>= ;<br />>>>> As said before, you 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 />&= gt;>>> Lonero Foundation via bitcoin-dev<br />>>>>= <<a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-d= ev@lists.linuxfoundation.org">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 find= ing the article online so take it with a grain of salt. The point thoug= h is that both servers and ASIC specific hardware would still be able t= o benefit 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 pull request for a draft via GitHub using BIP #2's = draft format and any questions people have can be answered in the reqeu= st's comments. That way people don't have to get emails everytime there= is a reply, but replies still get seen as opposed to offline discussio= n. Since the instructions say to email bitcoin-dev before doing a bip d= raft, I have done that. Since people want to see the draft beforehand a= nd it isn't merged manually anyways, I think it is the easiest way to h= andle this.<br />>>>> ><br />>>>> > I'm a= lso 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 establishe= d some interest for at least a draft.<br />>>>> ><br />&= gt;>>> > Does that seem fine?<br />>>>> ><br= />>>>> > Best regards, Andrew<br />>>>> >= ;<br />>>>> > On Fri, Mar 5, 2021, 7:41 PM Keagan McClel= land <<a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:keaga= n.mcclelland@gmail.com">keagan.mcclelland@gmail.com</a>> wrote:<br /= >>>>> >><br />>>>> >> > A large = portion of BTC is already mined through AWS servers and non-asic specif= ic hardware anyways. A majority of them would benefit from a hybrid pro= of, and the fact that it is hybrid in that manner wouldn't disenfranchi= se currently optimized mining entities as well.<br />>>>> &= gt;><br />>>>> >> My instincts tell me that this i= s an outlandish claim. Do you have supporting evidence for this?<br />&= gt;>>> >><br />>>>> >> Keagan<br />>= ;>>> >><br />>>>> >> On Fri, Mar 5, 20= 21 at 3:22 PM Lonero Foundation via bitcoin-dev <<a rel=3D"noreferre= r" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation= .org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br />>>= ;>> >>><br />>>>> >>> Actually I me= ntioned a proof of space and time hybrid which is much different than s= taking. Sorry to draw for the confusion as PoC is more commonly used th= en PoST.<br />>>>> >>> There is a way to make PoC = cryptographically compatible w/ Proof of Work as it normally stands: <a= rel=3D"noreferrer noreferrer" target=3D"=5Fblank" href=3D"https://en.w= ikipedia.org/wiki/Proof=5Fof=5Fspace">https://en.wikipedia.org/wiki/Pro= of=5Fof=5Fspace</a><br />>>>> >>> It has rarely be= en done though given the technological complexity of being both CPU com= patible and memory-hard compatible. There are lots of benefits outside = of the realm of efficiency, and I already looked into numerous fault to= lerant designs as well and what others in the cryptography community at= tempted to propose. The actual argument you have only against this is t= he 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 Bi= tcoin currently stands in its cryptography still needs updating regardl= ess. If someone figures out NP hardness or the halting problem the trad= itional rule of millions of years to break all of Bitcoin's cryptograph= y now comes down to minutes. Bitcoin is going to have to eventually rad= ically upgrade their cryptography and hashing algo in the future regard= less. I want to integrate some form of NP complexity in regards to the = hybrid cryptography I'm aiming to provide which includes a polynomial t= ime algorithm in the cryptography. More than likely the first version o= f my BTC hard fork will be coded in a way where integrating such comple= xity in the future only requires a soft fork or minor upgrade to its ch= ain.<br />>>>> >>><br />>>>> >>&= gt; In regards to the argument, "As a separate issue, proposing a hard = fork in the hashing algorithm will invalidate the enormous amount of ca= pital expenditure by mining entities and disincentivize future capital = expenditure into mining hardware that may compute these more "useful" p= roofs of work."<br />>>>> >>><br />>>>>= ; >>> 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 />>>>> >>><br />>>>> >>> T= here are other reasons why a cryptography upgrade like this is benefici= al. Theoretically one can argue BItcoin isn't fully decentralized. It i= s 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 happe= n. I have various research in regards to this area and work alot with d= istributed computing. I believe if the BTC community likes such a propo= sal, I would single handedly be able to build the cryptographic proof m= yself (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 in regar= ds to what warrants a shitcoin or the whole argument against staking.<b= r />>>>> >>> <a rel=3D"noreferrer noreferrer" targ= et=3D"=5Fblank" href=3D"https://hackernoon.com/ethereum-you-are-a-centr= alized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl">https://= hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telli= ng-us-that-you-arent-pi3s3yjl</a><br />>>>> >>><br= />>>>> >>> Best regards, Andrew<br />>&g= t;>> >>><br />>>>> >>> On Fri, Mar = 5, 2021 at 4:11 PM Keagan McClelland <<a rel=3D"noreferrer" target=3D= "=5Fblank" href=3D"mailto:keagan.mcclelland@gmail.com">keagan.mcclellan= d@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 mod= el to be the same. If the work was useful it provides an avenue for act= ors 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 different context and therefore would have bee= n done anyway. This actually degrades the security of the network in th= e process.<br />>>>> >>>><br />>>>>= >>>> As a separate issue, proposing a hard fork in the has= hing algorithm will invalidate the enormous amount of capital expenditu= re by mining entities and disincentivize future capital expenditure int= o mining hardware that may compute these more "useful" proofs of work. = This is because any change in the POW algorithm will be considered unst= able 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 t= o 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.<br />>>= ;>> >>>><br />>>>> >>>> All o= f these things make the Bitcoin network worse off.<br />>>>>= ; >>>><br />>>>> >>>> Keagan<br />&= gt;>>> >>>><br />>>>> >>>>= On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <<= a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lis= ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> w= rote:<br />>>>> >>>>><br />>>>> = >>>>> Also in regards to my other email, I forgot to ite= rate 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 sak= e of simplicity, I do want to do this BIP because it tackles lots of th= e issues in regards to this manner and can provide useful insight to th= e community. If things such as bigger block height have been proposed a= s hard forks, I feel at the very least an upgrade regarding the hashing= algorithm and cryptography does at least warrant some discussion. Anyw= ays I hope I can send you my BIP, just let me know on the preferred for= mat?<br />>>>> >>>>><br />>>>> &= gt;>>>> Best regards, Andrew<br />>>>> >>= >>><br />>>>> >>>>> On Fri, Mar 5, = 2021, 10:12 AM Lonero Foundation <<a rel=3D"noreferrer" target=3D"=5F= blank" href=3D"mailto:loneroassociation@gmail.com">loneroassociation@gm= ail.com</a>> wrote:<br />>>>> >>>>>><b= r />>>>> >>>>>> Hi, this isn't about the = energy efficient argument in regards to renewables or mining devices bu= t a better cryptography layer to get the most out of your hashing for v= alidation. I do understand the arbitrariness of it, but do want to stil= l propose a document. Do I use the Media Wiki format on GitHub and just= attach it as my proposal?<br />>>>> >>>>>&g= t;<br />>>>> >>>>>> Best regards, Andrew<= br />>>>> >>>>>><br />>>>> &g= t;>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <<a r= el=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:c1.devrandom@nifty= box.net">c1.devrandom@niftybox.net</a>> wrote:<br />>>>>= >>>>>>><br />>>>> >>>>>= ;>> Hi Ryan and Andrew,<br />>>>> >>>>>= ;>><br />>>>> >>>>>>> On Fri, Ma= r 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <<a rel=3D"noreferre= r" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation= .org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br />>>= ;>> >>>>>>>><br />>>>> >&g= t;>>>>>><br />>>>> >>>>>&g= t;>> <a rel=3D"noreferrer noreferrer" target=3D"=5Fbl= ank" href=3D"https://www.truthcoin.info/blog/pow-cheapest/">https://www= .truthcoin.info/blog/pow-cheapest/</a><br />>>>> >>&g= t;>>>>> "Nothing is Cheaper than Proo= f of Work"<br />>>>> >>>>>>>> = on | 04 Aug 2015<br />>>>> >>>>&g= t;>>><br />>>>> >>>>>>><br />= >>>> >>>>>>> Just to belabor this a bi= t, the paper demonstrates that the mining market will tend to expend re= sources equivalent to miner reward. It does not prove that mining= work has to expend *energy* as a primary cost.<br />>>>> &= gt;>>>>>><br />>>>> >>>>>&= gt;> Some might argue that energy expenditure has negative externali= ties and that we should move to other resources. I would argue th= at the negative externalities will go away soon because of the move to = renewables, so the point is likely moot.<br />>>>> >>= >>>>><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<br />>&= gt;>> >>>>> bitcoin-dev mailing list<br />>>= >> >>>>> <a rel=3D"noreferrer" target=3D"=5Fblank"= href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list= s.linuxfoundation.org</a><br />>>>> >>>>> <a= rel=3D"noreferrer noreferrer" target=3D"=5Fblank" href=3D"https://list= s.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linux= foundation.org/mailman/listinfo/bitcoin-dev</a><br />>>>> &= gt;>><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<br />>>>> >= ;>> bitcoin-dev mailing list<br />>>>> >>> <= a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lis= ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />= >>>> >>> <a rel=3D"noreferrer noreferrer" target=3D= "=5Fblank" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/b= itcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev</a><br />>>>> ><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<br />>&= gt;>> > bitcoin-dev mailing list<br />>>>> > <a= rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@list= s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />&= gt;>>> > <a rel=3D"noreferrer noreferrer" target=3D"=5Fblan= k" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d= ev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><= br />><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<br />> bitcoin-dev mailing list<br />> <a rel=3D= "noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lists.linux= foundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />> <a = rel=3D"noreferrer noreferrer" target=3D"=5Fblank" href=3D"https://lists= .linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxf= oundation.org/mailman/listinfo/bitcoin-dev</a></blockquote></div></bloc= kquote><br /><br /><br /> </blockquote></div></blockquote></div></= blockquote><br /><br /><br /> </html> ------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539--------