diff options
author | Lonero Foundation <loneroassociation@gmail.com> | 2021-03-12 18:21:36 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2021-03-12 23:21:51 +0000 |
commit | 0583dbdaa8725ba168a53057ce395831879a1072 (patch) | |
tree | bf75eb3747a3e21d5cd5bcf7ad2fe0c135452b0b | |
parent | e45c07b22cea37f2caf7f4e27d8ee4c1c0e607f3 (diff) | |
download | pi-bitcoindev-0583dbdaa8725ba168a53057ce395831879a1072.tar.gz pi-bitcoindev-0583dbdaa8725ba168a53057ce395831879a1072.zip |
Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining
-rw-r--r-- | 3e/825c71e90b76ae7aa1f0090ab852fdbde34518 | 736 |
1 files changed, 736 insertions, 0 deletions
diff --git a/3e/825c71e90b76ae7aa1f0090ab852fdbde34518 b/3e/825c71e90b76ae7aa1f0090ab852fdbde34518 new file mode 100644 index 000000000..49d8df5ac --- /dev/null +++ b/3e/825c71e90b76ae7aa1f0090ab852fdbde34518 @@ -0,0 +1,736 @@ +Return-Path: <loneroassociation@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id E8FFAC0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Mar 2021 23:21:51 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id CDFC5400A4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Mar 2021 23:21:51 +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: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +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 LUJttSKAf0YS + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Mar 2021 23:21:49 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com + [IPv6:2607:f8b0:4864:20::b30]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 03CA0444E5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Mar 2021 23:21:48 +0000 (UTC) +Received: by mail-yb1-xb30.google.com with SMTP id f145so10654336ybg.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 12 Mar 2021 15:21:48 -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=Le1rcUYiDL2AfC8LPODDzEIp5m9utpJm6Y7a4MMQNB0=; + b=FAWJNxUD1nia/b42jEseOgm46tpGZpC7Q7Xd6qmE5+n93PHehuZBxRp8173atVOOMk + slbmS2msxsyPOvD8kfBGBHvC/PMXt0ES4zCYLQYazgyyV1PlJk/U+SV7IwxDFPDdudci + 3g4c+enLeY+TYT5gXupvrqLeLESlry8iThOq6kMoRd51Ne65qVg5XQWHEgngSM5pXjeS + QvPJ0gdM7cWAOUvd+Vu+Arit+bCotp7QonbpEA+hB4ygEs0IPw6pQOcLWVISweH7zmVw + wsIGyLErG+IDbZ2Fjr05hlpC2YdGbFM8adsZkjpmDtc8ydCZnrIDD99hksRqTk4lN1SX + Wm3w== +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=Le1rcUYiDL2AfC8LPODDzEIp5m9utpJm6Y7a4MMQNB0=; + b=CdyJ608gruViv3fOHu6Vny5yCxNDckYZhfGpFQUObK5K/OnicHyOLEmw3P3OuUO+uo + M5gysHbOdocejFpgBzzwY/pfNIKAvX9B8H3YIZcd0DbzxOMbllcU3HdB4hXkHvLphZb1 + aaALGm1WlIsWlYnHXYmSL0GyT8fvi3oZFbZXkODe/550ulAivITzvHIRF2d4nexhRq9+ + G1j0ov/peAvq1tFvoKOzvzQa4VWCLkBKRKQ7j2LQsfxFqKeisQg3m90EztCy4cS7mBnh + m8QSwHOj4KBUuHrrnhSeefJVP94OLm3815ooVuNZXvQ45b5o13WJRpVku91vLHi3nCth + GF5A== +X-Gm-Message-State: AOAM533Tx5KoHAuc4WZwIri7NLxRvEzqLqilvsJlP7wBJpr9llNYn0tQ + Tb2Q3imf5MdYu8TQYWSHt/QpQDE6ZzGdautJWjY= +X-Google-Smtp-Source: ABdhPJxA6eXDgRitQROtWQPfC+r3TxHaTw/O/nnjFXkXAQmu+49sDUidBcx4Z5zWgaW8X/CEV3QW9CjiHq/mqmE85bU= +X-Received: by 2002:a25:ae14:: with SMTP id a20mr23715460ybj.129.1615591307812; + Fri, 12 Mar 2021 15:21:47 -0800 (PST) +MIME-Version: 1.0 +References: <CA+YkXXz9aHfZtt-it_8w4ovF=-QaZ4_9vwDS0Kz36qhHwVDC5Q@mail.gmail.com> + <3d65-604bed00-17d-6093c680@171273340> +In-Reply-To: <3d65-604bed00-17d-6093c680@171273340> +From: Lonero Foundation <loneroassociation@gmail.com> +Date: Fri, 12 Mar 2021 18:21:36 -0500 +Message-ID: <CA+YkXXzNAWrPPJfDtB-DXaSf9yoojkuEXeCXzkB2_cMtyHfFXA@mail.gmail.com> +To: "email@yancy.lol" <email@yancy.lol> +Content-Type: multipart/alternative; boundary="00000000000001255805bd5f2a53" +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:21:52 -0000 + +--00000000000001255805bd5f2a53 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Hi, I also want to emphasize that my main point isn't just to create a BTC +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 changes +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 consensus +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 statu= +s. +> +> 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/reference +>> 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.medi= +awiki +>> >> Can I submit a pull request on the BIPs repo for this to go into draf= +t +>> mode? Also, I think this provides at least some more insight on what I w= +ant +>> 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 doin= +g +>> 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 reposito= +ry +>> >>>> and bring it to discussion on the mailing list. then you can do a P= +R +>> >>>> +>> >>>> 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. Ha= +d +>> 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 still= + be +>> able to benefit from the cryptography upgrade I am proposing, as this wa= +s +>> in relation to the disinfranchisemet point. +>> >>>> > +>> >>>> > That said, I think the best way to move forward is to submit a BI= +P +>> 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 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 accidental= +ly +>> 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 an= +d +>> 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 m= +ore +>> commonly used then PoST. +>> >>>> >>> There is a way to make PoC cryptographically compatible w/ Proo= +f +>> 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. Ther= +e +>> 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 t= +he +>> cryptography community attempted to propose. The actual argument you hav= +e +>> only against this is the Proof of Memory fallacy, which is only partiall= +y +>> true. Given how the current hashing algorithm works, hard memory allocat= +ion +>> 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 Bitcoi= +n'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 o= +f +>> 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 be "useless" in order for the security model to be the same. If the w= +ork +>> was useful it provides an avenue for actors to have nothing at stake whe= +n +>> 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 minin= +g +>> 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 mo= +re +>> 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 wher= +e +>> they can be bribed by entities with a vested interest in deciding what t= +he +>> 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 m= +y +>> 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 regard= +s +>> to renewables or mining devices but a better cryptography layer to get t= +he +>> 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.net> wrote: +>> >>>> >>>>>>> +>> >>>> >>>>>>> Hi Ryan and Andrew, +>> >>>> >>>>>>> +>> >>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev < +>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>> >>>> >>>>>>>> +>> >>>> >>>>>>>> +>> >>>> >>>>>>>> https://www.truthcoin.info/blog/pow-cheapest/ +>> >>>> >>>>>>>> "Nothing is Cheaper than Proof of Work" +>> >>>> >>>>>>>> on | 04 Aug 2015 +>> >>>> >>>>>>>> +>> >>>> >>>>>>> +>> >>>> >>>>>>> Just to belabor this a bit, the paper demonstrates that the +>> mining market will tend to expend resources equivalent to miner reward. = + It +>> does not prove that mining work has to expend *energy* as a primary 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-de= +v +>> >>>> >>> +>> >>>> >>> _______________________________________________ +>> >>>> >>> 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 +> +> +> +> +> + +--00000000000001255805bd5f2a53 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Hi, I also want to emphasize that my main point isn&#= +39;t just to create a BTC 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 changes I am proposing can fix. In regards to technological imp= +lementation, once this is assigned draft status I am more than willing to c= +reate preprints explaining the cryptography, hashing algorithm improvements= +, and consensus that I am working on. This is a highly technologically comp= +lex 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 fo= +r draft status prior to working on technological implementation.</div><div>= +<br></div><div>Best regards, Andrew<br></div></div><br><div class=3D"gmail_= +quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 12, 2021 at 5:37 P= +M email@yancy.lol <email@yancy.lol> wrote:<br></div><blockquote class= +=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= +b(204,204,204);padding-left:1ex">I think Andrew himself is an algo.=C2=A0 T= +he 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 bitcoin-dev &= +lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan= +k">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>=C2=A0<blockquot= +e type=3D"cite" cite=3D"http://CA+YkXXz9aHfZtt-it_8w4ovF=3D-QaZ4_9vwDS0Kz36= +qhHwVDC5Q@mail.gmail.com"><div dir=3D"auto">Hi, I awkwardly phrased that pa= +rt, I was referring to key validation in relation to that section as well a= +s 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 get assigned a BI= +P 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 u= +pgrading to final status.</div><div dir=3D"auto">=C2=A0</div><div dir=3D"au= +to">This will take about 400 hours of my time, but is something I am person= +ally 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 after it is assigne= +d a number to references I do at the very least hope to describe various pa= +rts 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:er= +ik@q32.com" target=3D"_blank">erik@q32.com</a>> wrote:</div><blockquote = +class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol= +id 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 techn= +ical merit.<br><br>i suggest you start here:<br><br><a rel=3D"noreferrer no= +referrer" href=3D"https://en.bitcoin.it/wiki/Proof_of_burn" target=3D"_blan= +k">https://en.bitcoin.it/wiki/Proof_of_burn</a><br><a rel=3D"noreferrer nor= +eferrer" href=3D"https://bitcointalk.org/index.php?topic=3D225690.0" target= +=3D"_blank">https://bitcointalk.org/index.php?topic=3D225690.0</a><br><br>p= +roof-of-burn is a nice alternative to proof-of-work.=C2=A0 =C2=A0i always<b= +r>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>burn= +ed, 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 Foundation via bitcoin-dev<b= +r><<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>> Hi, I have submitted the BIP Pull Request here: <a rel= +=3D"noreferrer noreferrer" href=3D"https://github.com/bitcoin/bips/pull/108= +4" target=3D"_blank">https://github.com/bitcoin/bips/pull/1084</a><br>><= +br>> Hoping to receive a BIP # for the draft prior to development/refere= +nce 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"_blank">loneroassociation= +@gmail.com</a>> wrote:<br>>><br>>> Hi, here is the list to t= +he BIP proposal on my own repo: <a rel=3D"noreferrer noreferrer" href=3D"ht= +tps://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki= +" target=3D"_blank">https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/ma= +in/bip-draft.mediawiki</a><br>>> 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.<br>>><br>>> Bes= +t regards, Andrew<br>>><br>>> On Sat, Mar 6, 2021, 10:42 AM Lon= +ero Foundation <<a rel=3D"noreferrer" href=3D"mailto:loneroassociation@g= +mail.com" target=3D"_blank">loneroassociation@gmail.com</a>> wrote:<br>&= +gt;>><br>>>> [off-list]<br>>>><br>>>> Okay= +. I will do so and post the link here for discussion before doing a pull re= +quest on BIP's repo as the best way to handle it.<br>>>><br>&g= +t;>> Best regards, Andrew<br>>>><br>>>> On Sat, Mar= + 6, 2021, 10:21 AM Ricardo Filipe <<a rel=3D"noreferrer" href=3D"mailto:= +ricardojdfilipe@gmail.com" target=3D"_blank">ricardojdfilipe@gmail.com</a>&= +gt; 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>>>>> Lonero Foundation via bitcoin-dev<br>>>>&= +gt; <<a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundat= +ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> es= +creveu no dia s=C3=A1bado,<br>>>>> 6/03/2021 =C3=A0(s) 08:58:<b= +r>>>>> ><br>>>>> > I know Ethereum had an out= +landishly large percentage of nodes running on AWS, I heard the same thing = +is for Bitcoin but for mining. Had trouble finding the article online so ta= +ke it with a grain of salt. The point though is that both servers and ASIC = +specific hardware would still be able to benefit from the cryptography upgr= +ade I am proposing, as this was in relation to the disinfranchisemet point.= +<br>>>>> ><br>>>>> > That said, I think the b= +est way to move forward is to submit a BIP pull request for a draft via Git= +Hub using BIP #2's draft format and any questions people have can be an= +swered in the reqeust's comments. That way people don't have to get= + emails everytime there is a reply, but replies still get seen as opposed t= +o offline discussion. Since the instructions say to email bitcoin-dev befor= +e doing a bip draft, I have done that. Since people want to see the draft b= +eforehand and it isn't merged manually anyways, I think it is the easie= +st way to handle this.<br>>>>> ><br>>>>> > I&= +#39;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 impolit= +ely bother people given this is a moderated list and we already established= + some interest for at least a draft.<br>>>>> ><br>>>&g= +t;> > Does that seem fine?<br>>>>> ><br>>>>&g= +t; > Best regards, Andrew<br>>>>> ><br>>>>> &= +gt; 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.mccl= +elland@gmail.com</a>> wrote:<br>>>>> >><br>>>>= +;> >> > A large portion of BTC is already mined through AWS ser= +vers and non-asic specific hardware anyways. A majority of them would benef= +it from a hybrid proof, and the fact that it is hybrid in that manner would= +n't disenfranchise currently optimized mining entities as well.<br>>= +>>> >><br>>>>> >> My instincts tell me tha= +t this is an outlandish claim. Do you have supporting evidence for this?<br= +>>>>> >><br>>>>> >> Keagan<br>>>&= +gt;> >><br>>>>> >> On Fri, Mar 5, 2021 at 3:22 P= +M Lonero Foundation via bitcoin-dev <<a rel=3D"noreferrer" href=3D"mailt= +o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list= +s.linuxfoundation.org</a>> wrote:<br>>>>> >>><br>&g= +t;>>> >>> Actually I mentioned a proof of space and time = +hybrid which is much different than staking. Sorry to draw for the confusio= +n as PoC is more commonly used then PoST.<br>>>>> >>> = +There is a way to make PoC cryptographically compatible w/ Proof of Work as= + it normally stands: <a rel=3D"noreferrer noreferrer" href=3D"https://en.wi= +kipedia.org/wiki/Proof_of_space" target=3D"_blank">https://en.wikipedia.org= +/wiki/Proof_of_space</a><br>>>>> >>> It has rarely bee= +n done though given the technological complexity of being both CPU compatib= +le and memory-hard compatible. There are lots of benefits outside of the re= +alm of efficiency, and I already looked into numerous fault tolerant design= +s as well and what others in the cryptography community attempted to propos= +e. The actual argument you have only against this is the Proof of Memory fa= +llacy, which is only partially true. Given how the current hashing algorith= +m 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 hyb= +rid mechanism that fixes that. BTW: The way Bitcoin currently stands in its= + cryptography still needs updating regardless. If someone figures out NP ha= +rdness 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 has= +hing algo in the future regardless. I want to integrate some form of NP com= +plexity in regards to the hybrid cryptography I'm aiming to provide whi= +ch includes a polynomial time algorithm in the cryptography. More than like= +ly the first version of my BTC hard fork will be coded in a way where integ= +rating such complexity in the future only requires a soft fork or minor upg= +rade to its chain.<br>>>>> >>><br>>>>> >= +;>> 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 e= +xpenditure into mining hardware that may compute these more "useful&qu= +ot; proofs of work."<br>>>>> >>><br>>>>&= +gt; >>> A large portion of BTC is already mined through AWS server= +s 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&#= +39;t disenfranchise currently optimized mining entities as well.<br>>>= +;>> >>><br>>>>> >>> There are other rea= +sons why a cryptography upgrade like this is beneficial. Theoretically one = +can argue BItcoin isn't fully decentralized. It is few unsolved mathema= +tical proofs away from being entirely broken. My goal outside of efficiency= + is to build cryptography in a way that prevents such an event from happeni= +ng in the future, if it was to ever happen. I have various research in rega= +rds 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 bu= +ild the cryptographic proof myself (though would like as many open source c= +ontributors as I can get :)<br>>>>> >>><br>>>>= +;> >>> Anyways just something to consider. We are in the same s= +pace in regards to what warrants a shitcoin or the whole argument against s= +taking.<br>>>>> >>> <a rel=3D"noreferrer noreferrer" h= +ref=3D"https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency= +-stop-telling-us-that-you-arent-pi3s3yjl" target=3D"_blank">https://hackern= +oon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-= +you-arent-pi3s3yjl</a><br>>>>> >>><br>>>>>= + >>> Best regards,=C2=A0 Andrew<br>>>>> >>><b= +r>>>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McCle= +lland <<a rel=3D"noreferrer" href=3D"mailto:keagan.mcclelland@gmail.com"= + target=3D"_blank">keagan.mcclelland@gmail.com</a>> wrote:<br>>>&g= +t;> >>>><br>>>>> >>>> It is importan= +t 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 p= +rovides an avenue for actors to have nothing at stake when submitting a pro= +of 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 w= +ould have been done anyway. This actually degrades the security of the netw= +ork in the process.<br>>>>> >>>><br>>>>>= +; >>>> As a separate issue, proposing a hard fork in the hashin= +g algorithm will invalidate the enormous amount of capital expenditure by m= +ining entities and disincentivize future capital expenditure into mining ha= +rdware 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 bit= +coin 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 of these things make the Bit= +coin network worse off.<br>>>>> >>>><br>>>>= +;> >>>> Keagan<br>>>>> >>>><br>>&= +gt;>> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundati= +on via bitcoin-dev <<a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@lis= +ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation= +.org</a>> wrote:<br>>>>> >>>>><br>>>>= +;> >>>>> Also in regards to my other email, I forgot to i= +terate that my cryptography proposal helps behind the efficiency category b= +ut also tackles problems such as NP-Completeness or Halting which is someth= +ing 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 in re= +gards to this manner and can provide useful insight to the community. If th= +ings such as bigger block height have been proposed as hard forks, I feel a= +t the very least an upgrade regarding the hashing algorithm and cryptograph= +y does at least warrant some discussion. Anyways I hope I can send you my B= +IP, just let me know on the preferred format?<br>>>>> >>&= +gt;>><br>>>>> >>>>> Best regards, Andrew<b= +r>>>>> >>>>><br>>>>> >>>>= +;> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <<a rel=3D"norefer= +rer" href=3D"mailto:loneroassociation@gmail.com" target=3D"_blank">loneroas= +sociation@gmail.com</a>> wrote:<br>>>>> >>>>>= +><br>>>>> >>>>>> 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 valid= +ation. I do understand the arbitrariness of it, but do want to still propos= +e a document. Do I use the Media Wiki format on GitHub and just attach it a= +s my proposal?<br>>>>> >>>>>><br>>>>= +> >>>>>> Best regards, Andrew<br>>>>> >= +>>>>><br>>>>> >>>>>> On Fri, M= +ar 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>>>>> >= +>>>>>><br>>>>> >>>>>>> O= +n Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <<a rel=3D"nore= +ferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>>>>&g= +t; >>>>>>>><br>>>>> >>>>>= +;>>><br>>>>> >>>>>>>>=C2=A0 = +=C2=A0<a rel=3D"noreferrer noreferrer" href=3D"https://www.truthcoin.info/b= +log/pow-cheapest/" target=3D"_blank">https://www.truthcoin.info/blog/pow-ch= +eapest/</a><br>>>>> >>>>>>>>=C2=A0 =C2= +=A0 =C2=A0"Nothing is Cheaper than Proof of Work"<br>>>>= +> >>>>>>>>=C2=A0 =C2=A0 =C2=A0on | 04 Aug 2015<b= +r>>>>> >>>>>>>><br>>>>> >= +;>>>>>><br>>>>> >>>>>>> = +Just to belabor this a bit, the paper demonstrates that the mining market w= +ill tend to expend resources equivalent to miner 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 negative external= +ities 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 renewab= +les, so the point is likely moot.<br>>>>> >>>>>&= +gt;><br>>>>> >>>>> __________________________= +_____________________<br>>>>> >>>>> bitcoin-dev = +mailing list<br>>>>> >>>>> <a rel=3D"noreferrer"= + href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi= +tcoin-dev@lists.linuxfoundation.org</a><br>>>>> >>>>= +;> <a rel=3D"noreferrer noreferrer" href=3D"https://lists.linuxfoundatio= +n.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfo= +undation.org/mailman/listinfo/bitcoin-dev</a><br>>>>> >>&= +gt;<br>>>>> >>> ______________________________________= +_________<br>>>>> >>> bitcoin-dev mailing list<br>>= +>>> >>> <a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@= +lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat= +ion.org</a><br>>>>> >>> <a rel=3D"noreferrer noreferre= +r" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi= +n-dev</a><br>>>>> ><br>>>>> > _______________= +________________________________<br>>>>> > bitcoin-dev maili= +ng list<br>>>>> > <a rel=3D"noreferrer" href=3D"mailto:bitco= +in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux= +foundation.org</a><br>>>>> > <a rel=3D"noreferrer noreferrer= +" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" t= +arget=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin= +-dev</a><br>><br>> _______________________________________________<br= +>> bitcoin-dev mailing 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"noreferrer noreferrer" href=3D"h= +ttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_b= +lank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></b= +lockquote></div></blockquote><br><br><br>=C2=A0 +</blockquote></div> + +--00000000000001255805bd5f2a53-- + + |