From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <loneroassociation@gmail.com> Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 784C7C0001 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 12 Mar 2021 23:32:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 4523C605A4 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 12 Mar 2021 23:32:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ebEhub-1begS for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 12 Mar 2021 23:32:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by smtp3.osuosl.org (Postfix) with ESMTPS id B5E3A6059E for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 12 Mar 2021 23:32:03 +0000 (UTC) Received: by mail-yb1-xb2b.google.com with SMTP id c131so27052234ybf.7 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 12 Mar 2021 15:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EKDmATKv2MLw1Oeo9eYpfj9wqaKD2Ca5f1jexxvnm80=; b=up9DQq/4X7cBApAAtTvi/LHW8OtN1rwyX+qdcDxJQcWDLOJf8hWJvtwhUmU1r/Gz7w lQkuGiCRw9XDk/43nx/t1qi2w+635ZLX2EjACVJMSDD3OaSB9Q+1bXOJ03pSmUOIiV3W IlW/3YAy3vfUn/47Xmv9LY7gVnBpLL49YjvZ4cOUp80nLAHwCsliAbGDAzEUbE88HC8m uXOJ4wVxlpbjlHa4wopkwc7+/q8epPi3gfHXhru6u6mnIZtXeSBFngNGSsUOlR7I+Yzm OqlJRSnGZae++W+xMhUS2Q4objbVApM5uFEkIPYfjcDhOT90yHCfq7EQ6WcgcfbeV/sm BiWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EKDmATKv2MLw1Oeo9eYpfj9wqaKD2Ca5f1jexxvnm80=; b=UgASsQolvrFVfkacFeLqnuI18LuTyaqYMQfKBmNmcEyDqKYgntntKG62nbIwpYvoIx PrmHbPS1nVa7E4wXHRi/TMU7va6uFKIOD36oFls0JrxhIA40kTJubJ7ETNVmct+8k1YJ rUpsGAuorCuzDjBVWktTxqiiO4yZdOBJiXiMfwrEngv6DjMuUbMoXcRKx+ZTLqPJ5Izd Rt69PJETQTEYtijsNXDyblbMUhXRrwm8dk1Q/3zRUmm19n0K/zJCdXv2ahYc5oUDpV3m WANuTUO32Q1ejUFlAMPES42IDqoamMf6RFwZhb0m6MiZo/ER8v0SjUSloNrjrnolNknU NSUw== X-Gm-Message-State: AOAM533oPvYzlpMLmaeD45P87/gcR5L1sWwe/pwLQlhbW+VGCfJ0vLPL lnEcpiOqnOdSAANQaOoYY6fDCobIcM0s3F11ue4= X-Google-Smtp-Source: ABdhPJwPrc2brSY51Jemoc1Ool0peHgtG1w5vJoWpMbIe3gOcn3jDMfE16YdYSq+dD1cuuL54tZhZ2ztVhxI1VG+dCY= X-Received: by 2002:a25:b206:: with SMTP id i6mr21622638ybj.499.1615591922586; Fri, 12 Mar 2021 15:32:02 -0800 (PST) MIME-Version: 1.0 References: <CA+YkXXz9aHfZtt-it_8w4ovF=-QaZ4_9vwDS0Kz36qhHwVDC5Q@mail.gmail.com> <3d65-604bed00-17d-6093c680@171273340> <CA+YkXXzNAWrPPJfDtB-DXaSf9yoojkuEXeCXzkB2_cMtyHfFXA@mail.gmail.com> In-Reply-To: <CA+YkXXzNAWrPPJfDtB-DXaSf9yoojkuEXeCXzkB2_cMtyHfFXA@mail.gmail.com> From: Lonero Foundation <loneroassociation@gmail.com> Date: Fri, 12 Mar 2021 18:31:51 -0500 Message-ID: <CA+YkXXw5uh4yfvqDiBBEXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com> To: "email@yancy.lol" <email@yancy.lol> Content-Type: multipart/alternative; boundary="000000000000a5d83c05bd5f4e9f" 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] 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: Fri, 12 Mar 2021 23:32:06 -0000 --000000000000a5d83c05bd5f4e9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also, I already stated I was referring to signature validation cryptography in that aspect: https://wizardforcel.gitbooks.io/practical-cryptography-for-developers-book= /content/digital-signatures/ecdsa-sign-verify-examples.html My BIP has a primary purpose in regards to what I want to develop proofs for and the different cryptographic elements I want to develop proofs for. That said to those who disagree with the premise, I do prefer constructive feedback over insults or making fun of one another. After all this is an improvement proposal with a specific purpose aiming to develop a specific thing, not a guy who is just wanting to copy and paste a repository and call it a day. Best regards, Andrew On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation < loneroassociation@gmail.com> wrote: > Hi, I also want to emphasize that my main point isn't just to create a BT= C > hardfork or become another Bitcoin Cash, Gold, or SV. The main point in > regards to this BIP actually expands POW rather than replaces or creates = an > alternative. Many of the problems faced in regards to security in the > future as well as sustainability is something I believe lots of the chang= es > I am proposing can fix. In regards to technological implementation, once > this is assigned draft status I am more than willing to create preprints > explaining the cryptography, hashing algorithm improvements, and consensu= s > that I am working on. This is a highly technologically 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 point at least for draft status prior to > working on technological implementation. > > Best regards, Andrew > > On Fri, Mar 12, 2021 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote: > >> I think Andrew himself is an algo. The crypto training set must not be >> very good. >> >> Cheers, >> -Yancy >> >> On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev < >> bitcoin-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 merit, 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 preprints or publications to go in the references >> implementation section and start dev work before upgrading to final stat= us. >> >> This will take about 400 hours of my time, but is something I am >> personally looking into developing as a hard fork. >> >> Keep in mind 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 >> >> 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 suggest you start here: >>> >>> https://en.bitcoin.it/wiki/Proof_of_burn >>> https://bitcointalk.org/index.php?topic=3D225690.0 >>> >>> proof-of-burn is a nice alternative to proof-of-work. i always >>> suspected that, if designed correctly, it could 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 development/referenc= e >>> implementation. >>> > >>> > Best regards, Andrew >>> > >>> > 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.med= iawiki >>> >> 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 w= hat >>> I want to work on. >>> >> >>> >> Best regards, Andrew >>> >> >>> >> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation < >>> loneroassociation@gmail.com> wrote: >>> >>> >>> >>> [off-list] >>> >>> >>> >>> Okay. I will do so 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=A1bad= o, >>> >>>> 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. H= ad >>> trouble finding the article online so take it with a grain of salt. The >>> point though is that both servers and ASIC specific hardware would stil= l be >>> able to benefit from the cryptography upgrade I am proposing, as this w= as >>> in relation to the disinfranchisemet point. >>> >>>> > >>> >>>> > That said, I think the best way to move forward is to submit a >>> BIP pull request for a draft via GitHub using BIP #2's draft format and= any >>> questions people have can be answered in the reqeust's comments. That w= ay >>> people don't have to get emails everytime there is a reply, but replies >>> still get seen as opposed to offline discussion. Since the instructions= say >>> to email bitcoin-dev before doing a bip draft, I have done that. Since >>> people want to see the draft beforehand and it isn't merged manually >>> anyways, I think it is the easiest way to handle this. >>> >>>> > >>> >>>> > I'm also okay w/ continuing the discussion on bitcoin-dev but >>> rather form a discussion on git instead given I don't want to accidenta= lly >>> 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 benefi= t >>> from a hybrid proof, and the fact that it is hybrid in that manner woul= dn'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-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/ >>> 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. The= re >>> 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 ha= ve >>> only against this is the Proof of Memory fallacy, which is only partial= ly >>> true. Given how the current hashing algorithm works, hard memory alloca= tion >>> 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 the traditional rule of millions of years to break all of Bitco= in's >>> cryptography now comes down to minutes. Bitcoin is going to have to >>> eventually radically upgrade their cryptography and hashing algo in the >>> future regardless. I want to integrate some form of NP complexity in >>> regards to the hybrid cryptography I'm aiming to provide which includes= a >>> polynomial time algorithm in the cryptography. More than likely the fir= st >>> version of my BTC hard fork will be coded in a way where integrating su= ch >>> complexity in the future only requires a soft fork or minor upgrade to = its >>> chain. >>> >>>> >>> >>> >>>> >>> In regards to the argument, "As a separate issue, proposing a >>> hard fork in the hashing algorithm will invalidate the enormous amount = of >>> capital expenditure by mining entities and disincentivize future capita= l >>> expenditure into mining hardware that may compute these more "useful" >>> proofs of work." >>> >>>> >>> >>> >>>> >>> A large portion of BTC is already mined through AWS servers an= d >>> non-asic specific hardware anyways. A majority of them would benefit fr= om a >>> hybrid proof, and the fact that it is hybrid in that manner wouldn't >>> disenfranchise currently optimized mining entities as well. >>> >>>> >>> >>> >>>> >>> There are other reasons why a cryptography upgrade like this i= s >>> beneficial. Theoretically one can argue BItcoin isn't fully decentraliz= ed. >>> It is few unsolved mathematical proofs away from being entirely broken.= My >>> goal outside of efficiency is to build cryptography in a way that preve= nts >>> such an event from happening in the future, if it was to ever happen. I >>> have various research in regards to this area and work alot with >>> distributed computing. I believe if the BTC community likes such a >>> proposal, I would single handedly be able to build the cryptographic pr= oof >>> myself (though would like as many open source contributors as I can get= :) >>> >>>> >>> >>> >>>> >>> Anyways just something to consider. We are in the same space i= n >>> regards to what warrants a shitcoin or the whole argument against staki= ng. >>> >>>> >>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-st= op-telling-us-that-you-arent-pi3s3yjl >>> >>>> >>> >>> >>>> >>> Best regards, Andrew >>> >>>> >>> >>> >>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland < >>> keagan.mcclelland@gmail.com> wrote: >>> >>>> >>>> >>> >>>> >>>> It is important to understand that it is critical for the wor= k >>> to be "useless" in order for the security model to be the same. If the = work >>> was useful it provides an avenue for actors to have nothing at stake wh= en >>> submitting a proof of work, since the marginal cost of block constructi= on >>> will be lessened by the fact that the work was useful in a different >>> context and therefore would have been done anyway. This actually degrad= es >>> the security of the network in the process. >>> >>>> >>>> >>> >>>> >>>> As a separate issue, proposing a hard fork in the hashing >>> algorithm will invalidate the enormous amount of capital expenditure by >>> mining entities and disincentivize future capital expenditure into mini= ng >>> 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 m= ore >>> risk meaning that no entity is tying their own interests to that of the >>> bitcoin network at large. It also puts the developers in a position whe= re >>> they can be bribed by entities with a vested interest in deciding what = the >>> new "useful" proof of work should be. >>> >>>> >>>> >>> >>>> >>>> All of these things make the Bitcoin network worse off. >>> >>>> >>>> >>> >>>> >>>> Keagan >>> >>>> >>>> >>> >>>> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via >>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> >>>>> >>> >>>> >>>>> Also in regards to my other email, I forgot to iterate that >>> my cryptography proposal helps behind the efficiency category but also >>> tackles problems such as NP-Completeness or Halting which is something = the >>> BTC network could be vulnerable to in the future. For sake of simplicit= y, I >>> do want to do this BIP because it tackles lots of the issues in regards= to >>> this manner and can provide useful insight to the community. If things = such >>> as bigger block height have been proposed as hard forks, I feel at the = very >>> least an upgrade regarding the hashing algorithm and cryptography does = at >>> least warrant some discussion. Anyways I hope I can send you my BIP, ju= st >>> let me know on the preferred format? >>> >>>> >>>>> >>> >>>> >>>>> Best regards, Andrew >>> >>>> >>>>> >>> >>>> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation < >>> loneroassociation@gmail.com> wrote: >>> >>>> >>>>>> >>> >>>> >>>>>> Hi, this isn't about the energy efficient argument in >>> regards to renewables or mining devices but a better cryptography layer= to >>> get the most out of your hashing for validation. I do understand the >>> arbitrariness of it, but do want to still propose a document. Do I use = the >>> Media Wiki format on GitHub and just attach it as my proposal? >>> >>>> >>>>>> >>> >>>> >>>>>> Best regards, Andrew >>> >>>> >>>>>> >>> >>>> >>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom < >>> c1.devrandom@niftybox.net> wrote: >>> >>>> >>>>>>> >>> >>>> >>>>>>> Hi Ryan and Andrew, >>> >>>> >>>>>>> >>> >>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev = < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> >>>>>>>> >>> >>>> >>>>>>>> >>> >>>> >>>>>>>> https://www.truthcoin.info/blog/pow-cheapest/ >>> >>>> >>>>>>>> "Nothing is Cheaper than Proof of Work" >>> >>>> >>>>>>>> on | 04 Aug 2015 >>> >>>> >>>>>>>> >>> >>>> >>>>>>> >>> >>>> >>>>>>> Just to belabor this a bit, the paper demonstrates that th= e >>> mining market will tend to expend resources equivalent to miner reward.= It >>> does not prove that mining work has to expend *energy* as a primary cos= t. >>> >>>> >>>>>>> >>> >>>> >>>>>>> Some might argue that energy expenditure has negative >>> externalities and that we should move to other resources. I would argu= e >>> that the negative externalities will go away soon because of the move t= o >>> renewables, so the point is likely moot. >>> >>>> >>>>>>> >>> >>>> >>>>> _______________________________________________ >>> >>>> >>>>> bitcoin-dev mailing list >>> >>>> >>>>> bitcoin-dev@lists.linuxfoundation.org >>> >>>> >>>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>>> >>> >>> >>>> >>> _______________________________________________ >>> >>>> >>> bitcoin-dev mailing list >>> >>>> >>> bitcoin-dev@lists.linuxfoundation.org >>> >>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>>> > >>> >>>> > _______________________________________________ >>> >>>> > bitcoin-dev mailing list >>> >>>> > bitcoin-dev@lists.linuxfoundation.org >>> >>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> > >>> > _______________________________________________ >>> > bitcoin-dev mailing list >>> > bitcoin-dev@lists.linuxfoundation.org >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> >> > > --000000000000a5d83c05bd5f4e9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Also, I already stated I was referring to signature v= alidation cryptography in that aspect: <a href=3D"https://wizardforcel.gitb= ooks.io/practical-cryptography-for-developers-book/content/digital-signatur= es/ecdsa-sign-verify-examples.html">https://wizardforcel.gitbooks.io/practi= cal-cryptography-for-developers-book/content/digital-signatures/ecdsa-sign-= verify-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 elemen= ts I want to develop proofs for.</div><div>That said to those who disagree = with the premise, I do prefer constructive feedback over insults or making = fun of one another. After all this is an improvement proposal with a specif= ic purpose aiming to develop a specific thing, not a guy who is just wantin= g to copy and paste a repository and call it a day.</div><div><br></div><di= v>Best regards, Andrew<br></div></div><br><div class=3D"gmail_quote"><div d= ir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 12, 2021 at 6:21 PM Lonero Foun= dation <<a href=3D"mailto:loneroassociation@gmail.com">loneroassociation= @gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><div dir=3D"ltr"><div>Hi, I also want to emphasize that my main = point isn't just to create a BTC hardfork or become another Bitcoin Cas= h, Gold, or SV. The main point in regards to this BIP actually expands POW = rather than replaces or creates an alternative. Many of the problems faced = in regards to security in the future as well as sustainability is something= I believe lots of the changes I am proposing can fix. In regards to techno= logical implementation, once this is assigned draft status I am more than w= illing to create preprints explaining the cryptography, hashing algorithm i= mprovements, and consensus that I am working on. This is a highly technolog= ically complex idea that I am willing to "call my bluff on" and e= xpand upon. As for it being a draft, I think this is a good starting point = at least for draft status prior to working on technological implementation.= </div><div><br></div><div>Best regards, Andrew<br></div></div><br><div clas= s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 12, 202= 1 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote:<br></div><block= quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1= px solid rgb(204,204,204);padding-left:1ex">I think Andrew himself is an al= go.=C2=A0 The crypto training set must not be very good.<br><br>Cheers,<br>= -Yancy<br><br>On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bi= tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ= et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>=C2= =A0<blockquote type=3D"cite" cite=3D"http://CA+YkXXz9aHfZtt-it_8w4ovF=3D-Qa= Z4_9vwDS0Kz36qhHwVDC5Q@mail.gmail.com"><div dir=3D"auto">Hi, I awkwardly ph= rased that part, I was referring to key validation in relation to that sect= ion as well as the hashing related to those keys. I might rephrase it.=C2= =A0<div dir=3D"auto">=C2=A0</div><div dir=3D"auto">In regards to technical = merit, the main purpose of the BIP is to get a sense of the idea. Once I ge= t assigned a BIP draft #, I am willing to follow it up with many preprints = or publications to go in the references implementation section and start de= v work before upgrading to final status.</div><div dir=3D"auto">=C2=A0</div= ><div dir=3D"auto">This will take about 400 hours of my time, but is someth= ing I am personally looking into developing as a hard fork.</div><div dir= =3D"auto">=C2=A0</div><div dir=3D"auto">Keep in mind this is a draft, so af= ter it is assigned a number to references I do at the very least hope to de= scribe various parts of the cryptographic proofs and algorithmic structure = I am hoping for.</div><div dir=3D"auto">=C2=A0</div><div dir=3D"auto">Best = regards, Andrew</div></div>=C2=A0<div class=3D"gmail_quote"><div dir=3D"ltr= " class=3D"gmail_attr">On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty <<a = href=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>> wrote:<= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex">secp236k1 isn't = a hashing algo.=C2=A0 =C2=A0your 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" href=3D"https://en.bitcoin.it/wiki/Proof_of_burn= " target=3D"_blank">https://en.bitcoin.it/wiki/Proof_of_burn</a><br><a rel= =3D"noreferrer noreferrer" href=3D"https://bitcointalk.org/index.php?topic= =3D225690.0" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D22= 5690.0</a><br><br>proof-of-burn is a nice alternative to proof-of-work.=C2= =A0 =C2=A0i always<br>suspected that, if designed correctly, it could be a = proven<br>equivalent.=C2=A0 =C2=A0you could spin up a fork of bitcoin that = allows aged,<br>burned, coins instead of POW that would probably work just = fine.<br><br>- erik<br><br>On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundati= on via bitcoin-dev<br><<a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@= lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat= ion.org</a>> wrote:<br>><br>> Hi, I have submitted the BIP Pull Re= quest here: <a rel=3D"noreferrer noreferrer" href=3D"https://github.com/bit= coin/bips/pull/1084" target=3D"_blank">https://github.com/bitcoin/bips/pull= /1084</a><br>><br>> Hoping to receive a BIP # for the draft prior to = development/reference implementation.<br>><br>> Best regards, Andrew<= br>><br>> On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <<a rel= =3D"noreferrer" href=3D"mailto:loneroassociation@gmail.com" target=3D"_blan= k">loneroassociation@gmail.com</a>> wrote:<br>>><br>>> Hi, h= ere is the list to the BIP proposal on my own repo: <a rel=3D"noreferrer no= referrer" href=3D"https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main= /bip-draft.mediawiki" target=3D"_blank">https://github.com/Mentors4EDU/bip-= amkn-posthyb/blob/main/bip-draft.mediawiki</a><br>>> Can I submit a p= ull 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, Andrew<br>>><br>>> On Sat, Mar 6= , 2021, 10:42 AM Lonero Foundation <<a rel=3D"noreferrer" href=3D"mailto= :loneroassociation@gmail.com" target=3D"_blank">loneroassociation@gmail.com= </a>> wrote:<br>>>><br>>>> [off-list]<br>>>><= br>>>> Okay. I will do so and post the link here for discussion be= fore doing a pull request on BIP's repo as the best way to handle it.<b= r>>>><br>>>> Best regards, Andrew<br>>>><br>>= >> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe <<a rel=3D"norefer= rer" href=3D"mailto:ricardojdfilipe@gmail.com" target=3D"_blank">ricardojdf= ilipe@gmail.com</a>> wrote:<br>>>>><br>>>>> As s= aid before, you are free to create the BIP in your own repository<br>>&g= t;>> and bring it to discussion on the mailing list. then you can do = a PR<br>>>>><br>>>>> Lonero Foundation via bitcoin-= dev<br>>>>> <<a rel=3D"noreferrer" href=3D"mailto:bitcoin-de= v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound= ation.org</a>> escreveu no dia s=C3=A1bado,<br>>>>> 6/03/202= 1 =C3=A0(s) 08:58:<br>>>>> ><br>>>>> > I know= Ethereum had an outlandishly large percentage of nodes running on AWS, I h= eard the same thing is for Bitcoin but for mining. Had trouble finding the = article online so take it with a grain of salt. The point though is that bo= th servers and ASIC specific hardware would still be able to benefit from t= he cryptography upgrade I am proposing, as this was in relation to the disi= nfranchisemet 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 p= eople have can be answered in the reqeust's comments. That way people d= on't have to get emails everytime there is a reply, but replies still g= et seen as opposed to offline discussion. Since the instructions say to ema= il bitcoin-dev before doing a bip draft, I have done that. Since people wan= t to see the draft beforehand and it isn't merged manually anyways, I t= hink it is the easiest way to handle this.<br>>>>> ><br>>= >>> > 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.<br>>>>>= ; ><br>>>>> > Does that seem fine?<br>>>>> &g= t;<br>>>>> > Best regards, Andrew<br>>>>> ><b= r>>>>> > On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland <= <a rel=3D"noreferrer" href=3D"mailto:keagan.mcclelland@gmail.com" target=3D= "_blank">keagan.mcclelland@gmail.com</a>> wrote:<br>>>>> >= ;><br>>>>> >> > A large portion of BTC is already m= ined through AWS servers and 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 entit= ies as well.<br>>>>> >><br>>>>> >> My i= nstincts tell me that this is an outlandish claim. Do you have supporting e= vidence for this?<br>>>>> >><br>>>>> >>= Keagan<br>>>>> >><br>>>>> >> On Fri, M= ar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <<a rel=3D"noref= errer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla= nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>>>>>= ; >>><br>>>>> >>> Actually I mentioned a proo= f of space and time hybrid which is much different than staking. Sorry to d= raw for the confusion as PoC is more commonly used then PoST.<br>>>&g= t;> >>> There is a way to make PoC cryptographically compatible= w/ Proof of Work as it normally stands: <a rel=3D"noreferrer noreferrer" h= ref=3D"https://en.wikipedia.org/wiki/Proof_of_space" target=3D"_blank">http= s://en.wikipedia.org/wiki/Proof_of_space</a><br>>>>> >>&g= t; It has rarely been done though given the technological complexity of bei= ng both CPU compatible and memory-hard compatible. There are lots of benefi= ts outside of the realm of efficiency, and I already looked into numerous f= ault tolerant designs as well and what others in the cryptography community= attempted to propose. The actual argument you have only against this is th= e Proof of Memory fallacy, which is only partially true. Given how the curr= ent hashing algorithm works, hard memory allocation wouldn't be of much= benefit given it is more optimized for CPU/ASIC specific mining. I'm w= orking towards a hybrid mechanism that fixes that. BTW: The way Bitcoin cur= rently stands in its cryptography still needs updating regardless. If someo= ne figures out NP hardness or the halting problem the traditional rule of m= illions 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 a= iming to provide which includes a polynomial time algorithm in the cryptogr= aphy. 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 requires a so= ft fork or minor upgrade to its chain.<br>>>>> >>><br>= >>>> >>> In regards to the argument, "As a separa= te issue, proposing a hard fork in the hashing algorithm will invalidate th= e enormous amount of capital expenditure by mining entities and disincentiv= ize future capital expenditure into mining hardware that may compute these = more "useful" proofs of work."<br>>>>> >>&= gt;<br>>>>> >>> A large portion of BTC is already mine= d through AWS servers and 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 is beneficial= . Theoretically one can argue BItcoin isn't fully decentralized. It is = few unsolved mathematical proofs away from being entirely broken. My goal o= utside of efficiency is to build cryptography in a way that prevents such a= n event from happening in the future, if it was to ever happen. I have vari= ous research in regards to this area and work alot with distributed computi= ng. I believe if the BTC community likes such a proposal, I would single ha= ndedly be able to build the cryptographic proof myself (though would like a= s many open source contributors as I can get :)<br>>>>> >>= ;><br>>>>> >>> Anyways just something to consider. = We are in the same space in regards to what warrants a shitcoin or the whol= e argument against staking.<br>>>>> >>> <a rel=3D"nore= ferrer noreferrer" href=3D"https://hackernoon.com/ethereum-you-are-a-centra= lized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl" target=3D"_bl= ank">https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-s= top-telling-us-that-you-arent-pi3s3yjl</a><br>>>>> >>>= <br>>>>> >>> Best regards,=C2=A0 Andrew<br>>>>= ;> >>><br>>>>> >>> On Fri, Mar 5, 2021 at = 4:11 PM Keagan McClelland <<a rel=3D"noreferrer" href=3D"mailto:keagan.m= cclelland@gmail.com" target=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 same. If the = work was useful it provides an avenue for actors to have nothing at stake w= hen submitting a proof of work, since the marginal cost of block constructi= on will be lessened by the fact that the work was useful in a different con= text and therefore would have been done anyway. This actually degrades the = security of the network in the process.<br>>>>> >>>>= ;<br>>>>> >>>> As a separate issue, proposing a har= d fork in the hashing algorithm will invalidate the enormous amount of capi= tal expenditure by mining entities and disincentivize future capital expend= iture into mining hardware that may compute these more "useful" p= roofs of work. This is because any change in the POW algorithm will be cons= idered unstable and subject to change in the future. This puts the entire n= etwork at even more risk meaning that no entity is tying their own interest= s 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 de= ciding what the new "useful" proof of work should be.<br>>>= >> >>>><br>>>>> >>>> All of these= things make the Bitcoin network worse off.<br>>>>> >>>= ;><br>>>>> >>>> Keagan<br>>>>> >&= gt;>><br>>>>> >>>> On Fri, Mar 5, 2021 at 1:4= 8 PM Lonero Foundation via bitcoin-dev <<a rel=3D"noreferrer" href=3D"ma= ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l= ists.linuxfoundation.org</a>> wrote:<br>>>>> >>>>= ;><br>>>>> >>>>> Also in regards to my other = email, I forgot to iterate that my cryptography proposal helps behind the e= fficiency category but also tackles problems such as NP-Completeness or Hal= ting which is something the BTC network could be vulnerable to in the futur= e. For sake of simplicity, I do want to do this BIP because it tackles lots= of the issues in regards to this manner and can provide useful insight to = the community. If things such as bigger block height have been proposed as = hard forks, I feel at the very least an upgrade regarding the hashing algor= ithm 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?<br>>&g= t;>> >>>>><br>>>>> >>>>> Be= st regards, Andrew<br>>>>> >>>>><br>>>>= > >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation &= lt;<a rel=3D"noreferrer" href=3D"mailto:loneroassociation@gmail.com" target= =3D"_blank">loneroassociation@gmail.com</a>> wrote:<br>>>>> = >>>>>><br>>>>> >>>>>> Hi, t= his 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 yo= ur hashing for validation. I do understand the arbitrariness 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?<br>>>>> >>>>>= ><br>>>>> >>>>>> Best regards, Andrew<br>&= gt;>>> >>>>>><br>>>>> >>>&g= t;>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <<a rel=3D"noreferrer= " href=3D"mailto:c1.devrandom@niftybox.net" target=3D"_blank">c1.devrandom@= niftybox.net</a>> wrote:<br>>>>> >>>>>>>= ;<br>>>>> >>>>>>> Hi Ryan and Andrew,<br>&= gt;>>> >>>>>>><br>>>>> >>&g= t;>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-de= v <<a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundatio= n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrot= e:<br>>>>> >>>>>>>><br>>>>>= >>>>>>>><br>>>>> >>>>>&= gt;>>=C2=A0 =C2=A0<a rel=3D"noreferrer noreferrer" href=3D"https://ww= w.truthcoin.info/blog/pow-cheapest/" target=3D"_blank">https://www.truthcoi= n.info/blog/pow-cheapest/</a><br>>>>> >>>>>>&= gt;>=C2=A0 =C2=A0 =C2=A0"Nothing is Cheaper than Proof of Work"= ;<br>>>>> >>>>>>>>=C2=A0 =C2=A0 =C2=A0o= n | 04 Aug 2015<br>>>>> >>>>>>>><br>>= ;>>> >>>>>>><br>>>>> >>>= >>>> Just to belabor this a bit, the paper demonstrates that th= e mining market will tend to expend resources equivalent to miner reward.= =C2=A0 It does not prove that mining work has to expend *energy* as a prima= ry cost.<br>>>>> >>>>>>><br>>>>&g= t; >>>>>>> Some might argue that energy expenditure ha= s negative externalities and that we should move to other resources.=C2=A0 = I would argue that the negative externalities will go away soon because of = the move to renewables, so the point is likely moot.<br>>>>> &g= t;>>>>>><br>>>>> >>>>> _______= ________________________________________<br>>>>> >>>&g= t;> bitcoin-dev mailing list<br>>>>> >>>>> <a= rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t= arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>>>>&= gt; >>>>> <a rel=3D"noreferrer noreferrer" href=3D"https://l= ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">ht= tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>>>= ;>> >>><br>>>>> >>> ___________________= ____________________________<br>>>>> >>> bitcoin-dev m= ailing list<br>>>>> >>> <a rel=3D"noreferrer" href=3D"= mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev= @lists.linuxfoundation.org</a><br>>>>> >>> <a rel=3D"n= oreferrer noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/lis= tinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br>>>>> ><br>>>>> &= gt; _______________________________________________<br>>>>> >= ; bitcoin-dev mailing list<br>>>>> > <a rel=3D"noreferrer" h= ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc= oin-dev@lists.linuxfoundation.org</a><br>>>>> > <a rel=3D"no= referrer noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/list= info/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailm= an/listinfo/bitcoin-dev</a><br>><br>> _______________________________= ________________<br>> bitcoin-dev mailing list<br>> <a rel=3D"norefer= rer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank= ">bitcoin-dev@lists.linuxfoundation.org</a><br>> <a rel=3D"noreferrer no= referrer" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoi= n-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo= /bitcoin-dev</a></blockquote></div></blockquote><br><br><br>=C2=A0 </blockquote></div> </blockquote></div> --000000000000a5d83c05bd5f4e9f--