Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 784C7C0001 for ; 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 ; 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 ; 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 ; Fri, 12 Mar 2021 23:32:03 +0000 (UTC) Received: by mail-yb1-xb2b.google.com with SMTP id c131so27052234ybf.7 for ; 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: <3d65-604bed00-17d-6093c680@171273340> In-Reply-To: From: Lonero Foundation Date: Fri, 12 Mar 2021 18:31:51 -0500 Message-ID: To: "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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 >>> 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 >>> >>>> 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 >>> 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 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
Also, I already stated I was referring to signature v= alidation cryptography in that aspect: https://wizardforcel.gitbooks.io/practi= cal-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 elemen= ts 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 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.

Best regards, Andrew

On Fri, Mar 12, 2021 at 6:21 PM Lonero Foun= dation <loneroassociation= @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 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.=

Best regards, Andrew

On Fri, Mar 12, 202= 1 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote:
I think Andrew himself is an al= go.=C2=A0 The crypto training set must not be very good.

Cheers,
= -Yancy

On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bi= tcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=C2= =A0
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
=C2=A0
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.
=C2=A0
This will take about 400 hours of my time, but is someth= ing I am personally looking into developing as a hard fork.
=C2=A0
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.
=C2=A0
Best = regards, Andrew
=C2=A0
On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty <erik@q32.com> wrote:<= /div>
secp236k1 isn't = a hashing algo.=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_of_burn
https://bitcointalk.org/index.php?topic=3D22= 5690.0

proof-of-burn is a nice alternative to proof-of-work.=C2= =A0 =C2=A0i always
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 Foundati= on via bitcoin-dev
<bitcoin-dev@lists.linuxfoundat= ion.org> wrote:
>
> Hi, I have submitted the BIP Pull Re= quest here: https://github.com/bitcoin/bips/pull= /1084
>
> Hoping to receive a BIP # for the draft prior to = development/reference implementation.
>
> Best regards, Andrew<= br>>
> On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <loneroassociation@gmail.com> wrote:
>>
>> Hi, h= ere is the list to the BIP proposal on my own repo: https://github.com/Mentors4EDU/bip-= amkn-posthyb/blob/main/bip-draft.mediawiki
>> Can I submit a 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.
>= >
>> Best regards, Andrew
>>
>> On Sat, Mar 6= , 2021, 10:42 AM Lonero Foundation <loneroassociation@gmail.com= > wrote:
>>>
>>> [off-list]
>>><= 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.>>>
>>> Best regards, Andrew
>>>
>= >> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe <ricardojdf= ilipe@gmail.com> wrote:
>>>>
>>>> As s= aid before, you are free to create the BIP in your own repository
>&g= t;>> and bring it to discussion on the mailing list. then you can do = a PR
>>>>
>>>> Lonero Foundation via bitcoin-= dev
>>>> <bitcoin-dev@lists.linuxfound= ation.org> escreveu no dia s=C3=A1bado,
>>>> 6/03/202= 1 =C3=A0(s) 08:58:
>>>> >
>>>> > 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.
>>>> >
>>>> > 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.
>>>> >
>= >>> > I'm also okay w/ continuing the discussion on bitcoin= -dev but rather form a discussion on git instead given I don't want to = accidentally impolitely bother people given this is a moderated list and we= already established some interest for at least a draft.
>>>>= ; >
>>>> > Does that seem fine?
>>>> &g= t;
>>>> > 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 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.
>>>> >>
>>>> >> My i= nstincts tell me that this is an outlandish claim. Do you have supporting e= vidence for this?
>>>> >>
>>>> >>= Keagan
>>>> >>
>>>> >> On Fri, M= ar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>= ; >>>
>>>> >>> 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.
>>&g= t;> >>> There is a way to make PoC cryptographically compatible= w/ Proof of Work as it normally stands: http= s://en.wikipedia.org/wiki/Proof_of_space
>>>> >>&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.
>>>> >>>
= >>>> >>> 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."
>>>> >>&= gt;
>>>> >>> 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.
>>>> >>>
>>>> >>>= 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 :)
>>>> >>= ;>
>>>> >>> 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.
>>>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-s= top-telling-us-that-you-arent-pi3s3yjl
>>>> >>>=
>>>> >>> Best regards,=C2=A0 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 = 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.
>>>> >>>>= ;
>>>> >>>> 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.
>>= >> >>>>
>>>> >>>> All of these= things make the Bitcoin network worse off.
>>>> >>>= ;>
>>>> >>>> Keagan
>>>> >&= gt;>>
>>>> >>>> On Fri, Mar 5, 2021 at 1:4= 8 PM Lonero Foundation via bitcoin-dev <bitcoin-dev@l= ists.linuxfoundation.org> wrote:
>>>> >>>>= ;>
>>>> >>>>> 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?
>&g= t;>> >>>>>
>>>> >>>>> Be= st regards, Andrew
>>>> >>>>>
>>>= > >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation &= lt;loneroassociation@gmail.com> wrote:
>>>> = >>>>>>
>>>> >>>>>> 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?
>>>> >>>>>= >
>>>> >>>>>> Best regards, Andrew
&= gt;>>> >>>>>>
>>>> >>>&g= t;>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom@= niftybox.net> wrote:
>>>> >>>>>>>= ;
>>>> >>>>>>> Hi Ryan and Andrew,
&= gt;>>> >>>>>>>
>>>> >>&g= t;>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-de= v <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
>>>> >>>>>>>>
>>>>= >>>>>>>>
>>>> >>>>>&= gt;>>=C2=A0 =C2=A0https://www.truthcoi= n.info/blog/pow-cheapest/
>>>> >>>>>>&= gt;>=C2=A0 =C2=A0 =C2=A0"Nothing is Cheaper than Proof of Work"= ;
>>>> >>>>>>>>=C2=A0 =C2=A0 =C2=A0o= n | 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.= =C2=A0 It does not prove that mining work has to expend *energy* as a prima= ry cost.
>>>> >>>>>>>
>>>&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.
>>>> &g= t;>>>>>>
>>>> >>>>> _______= ________________________________________
>>>> >>>&g= t;> bitcoin-dev mailing list
>>>> >>>>> bitcoin-dev@lists.linuxfoundation.org
>>>&= gt; >>>>> ht= tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>= ;>> >>>
>>>> >>> ___________________= ____________________________
>>>> >>> bitcoin-dev m= ailing list
>>>> >>> bitcoin-dev= @lists.linuxfoundation.org
>>>> >>> https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
>>>> >
>>>> &= gt; _______________________________________________
>>>> >= ; bitcoin-dev mailing list
>>>> > bitc= oin-dev@lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailm= an/listinfo/bitcoin-dev
>
> _______________________________= ________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo= /bitcoin-dev



=C2=A0
--000000000000a5d83c05bd5f4e9f--