From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1D7D5C0001 for ; Sat, 13 Mar 2021 08:13:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id F34334EC3B for ; Sat, 13 Mar 2021 08:13:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9OpforMjilM for ; Sat, 13 Mar 2021 08:13:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) by smtp4.osuosl.org (Postfix) with ESMTPS id 26C7A4EC3A for ; Sat, 13 Mar 2021 08:13:28 +0000 (UTC) Received: from sogo1.sd4.0x35.net (sogo1.sd4.0x35.net [10.200.201.51]) (Authenticated sender: email@yancy.lol) by relay12.mail.gandi.net (Postfix) with ESMTPA id 9B5A4200004; Sat, 13 Mar 2021 08:13:25 +0000 (UTC) From: "email@yancy.lol" In-Reply-To: Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------" X-Forward: 127.0.0.1 Date: Sat, 13 Mar 2021 09:13:25 +0100 To: "Lonero Foundation" MIME-Version: 1.0 Message-ID: <1802-604c7400-4d1-7b635e80@91248813> User-Agent: SOGoMail 5.0.1 X-Mailman-Approved-At: Sat, 13 Mar 2021 22:53:20 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] =?utf-8?q?BIP_Proposal=3A_Consensus_=28hard_fork=29?= =?utf-8?q?_PoST_Datastore_for_Energy_Efficient_Mining?= X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2021 08:13:33 -0000 ------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 16332 My email was not intended as an insult.=C2=A0 Your proposal seemed a bi= t like gibberish and made some obvious mistakes as pointed out before (= such as conflating secp256k1 with sha256), and so I was genuinely curio= us if you were a bot spamming the list.=C2=A0 Maybe a more interesting topic is, can GPT3 be used to generate a BIP?=C2= =A0 How long before our AI overlord produces improvements to Bitcoin?=C2= =A0 At what point will the AI have more than 51% of commit frequency?=C2= =A0 Will we have lost the war to our new centralized overlord? Cheers, -Yancy On Saturday, March 13, 2021 00:31 CET, Lonero Foundation wrote: =C2=A0Also, I already stated I was referring to signature validation cr= yptography in that aspect: https://wizardforcel.gitbooks.io/practical-c= ryptography-for-developers-book/content/digital-signatures/ecdsa-sign-v= erify-examples.htmlMy BIP has a primary purpose in regards to what I wa= nt to develop proofs for and the different cryptographic elements I wan= t to develop proofs for.That said to those who disagree with the premis= e, I do prefer constructive feedback over insults or making fun of one = another. After all this is an improvement proposal with a specific purp= ose aiming to develop a specific thing, not a guy who is just wanting t= o copy and paste a repository and call it a day.=C2=A0Best regards, And= rew=C2=A0On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation wrote:Hi, I also want to emphasize that my main point= isn't just to create a BTC hardfork or become another Bitcoin Cash, Go= ld, or SV. The main point in regards to this BIP actually expands POW r= ather than replaces or creates an alternative. Many of the problems fac= ed in regards to security in the future as well as sustainability is so= mething I believe lots of the changes I am proposing can fix. In regard= s to technological implementation, once this is assigned draft status I= am more than willing to create preprints explaining the cryptography, = hashing algorithm improvements, and consensus that I am working on. Thi= s is a highly technologically complex idea that I am willing to "call m= y bluff on" and expand upon. As for it being a draft, I think this is a= good starting point at least for draft status prior to working on tech= nological implementation.=C2=A0Best regards, Andrew=C2=A0On Fri, Mar 12= , 2021 at 5:37 PM email@yancy.lol wrote:I think Andre= w himself is an algo.=C2=A0 The crypto training set must not be very go= od. Cheers, -Yancy On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev = wrote: =C2=A0Hi, I awkwardly phrased that part, I was referring to key validat= ion in relation to that section as well as the hashing related to those= keys. I might rephrase it.=C2=A0=C2=A0In regards to technical merit, t= he main purpose of the BIP is to get a sense of the idea. Once I get as= signed a BIP draft #, I am willing to follow it up with many preprints = or publications to go in the references implementation section and star= t dev work before upgrading to final status.=C2=A0This will take about = 400 hours of my time, but is something I am personally looking into dev= eloping as a hard fork.=C2=A0Keep in mind this is a draft, so after it = is assigned a number to references I do at the very least hope to descr= ibe various parts of the cryptographic proofs and algorithmic structure= I am hoping for.=C2=A0Best regards, Andrew=C2=A0On Fri, Mar 12, 2021, = 10:03 AM Erik Aronesty wrote:secp236k1 isn't a hashing a= lgo.=C2=A0 =C2=A0your BIP needs about 10 more pages and some degree of technical merit. i suggest you start here: https://en.bitcoin.it/wiki/Proof=5Fof=5Fburn https://bitcointalk.org/index.php?topic=3D225690.0 proof-of-burn is a nice alternative to proof-of-work.=C2=A0 =C2=A0i alw= ays suspected that, if designed correctly, it could be a proven equivalent.=C2=A0 =C2=A0you could spin up a fork of bitcoin that allows= aged, burned, coins instead of POW that would probably work just fine. - erik On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundation via bitcoin-dev wrote: > > Hi, I have submitted the BIP Pull Request here: https://github.com/bi= tcoin/bips/pull/1084 > > Hoping to receive a BIP # for the draft prior to development/referenc= e implementation. > > Best regards, Andrew > > On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation wrote: >> >> Hi, here is the list to the BIP proposal on my own repo: https://git= hub.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki >> Can I submit a pull request on the BIPs repo for this to go into dra= ft mode? Also, I think this provides at least some more insight on what= I want to work on. >> >> Best regards, Andrew >> >> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation wrote: >>> >>> [off-list] >>> >>> Okay. I will do so and post the link here for discussion before doi= ng a pull request on BIP's repo as the best way to handle it. >>> >>> Best regards, Andrew >>> >>> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe wrote: >>>> >>>> As said before, you are free to create the BIP in your own reposit= ory >>>> and bring it to discussion on the mailing list. then you can do a = PR >>>> >>>> Lonero Foundation via bitcoin-dev >>>> escreveu no dia s=C3=A1bad= o, >>>> 6/03/2021 =C3=A0(s) 08:58: >>>> > >>>> > I know Ethereum had an outlandishly large percentage of nodes ru= nning on AWS, I heard the same thing is for Bitcoin but for mining. Had= trouble finding the article online so take it with a grain of salt. Th= e point though is that both servers and ASIC specific hardware would st= ill be able to benefit from the cryptography upgrade I am proposing, as= this was in relation to the disinfranchisemet point. >>>> > >>>> > That said, I think the best way to move forward is to submit a B= IP pull request for a draft via GitHub using BIP #2's draft format and = any questions people have can be answered in the reqeust's comments. Th= at way people don't have to get emails everytime there is a reply, but = replies still get seen as opposed to offline discussion. Since the inst= ructions say to email bitcoin-dev before doing a bip draft, I have done= that. Since people want to see the draft beforehand and it isn't merge= d manually anyways, I think it is the easiest way to handle this. >>>> > >>>> > I'm also okay w/ continuing the discussion on bitcoin-dev but ra= ther form a discussion on git instead given I don't want to accidentall= y impolitely bother people given this is a moderated list and we alread= y established some interest for at least a draft. >>>> > >>>> > Does that seem fine? >>>> > >>>> > Best regards, Andrew >>>> > >>>> > On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland wrote: >>>> >> >>>> >> > A large portion of BTC is already mined through AWS servers a= nd non-asic specific hardware anyways. A majority of them would benefit= from a hybrid proof, and the fact that it is hybrid in that manner wou= ldn't disenfranchise currently optimized mining entities as well. >>>> >> >>>> >> My instincts tell me that this is an outlandish claim. Do you h= ave supporting evidence for this? >>>> >> >>>> >> Keagan >>>> >> >>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-de= v wrote: >>>> >>> >>>> >>> Actually I mentioned a proof of space and time hybrid which is= much different than staking. Sorry to draw for the confusion as PoC is= more commonly used then PoST. >>>> >>> There is a way to make PoC cryptographically compatible w/ Pro= of of Work as it normally stands: https://en.wikipedia.org/wiki/Proof=5F= of=5Fspace >>>> >>> It has rarely been done though given the technological complex= ity of being both CPU compatible and memory-hard compatible. There are = lots of benefits outside of the realm of efficiency, and I already look= ed into numerous fault tolerant designs as well and what others in the = cryptography community attempted to propose. The actual argument you ha= ve only against this is the Proof of Memory fallacy, which is only part= ially true. Given how the current hashing algorithm works, hard memory = allocation wouldn't be of much benefit given it is more optimized for C= PU/ASIC specific mining. I'm working towards a hybrid mechanism that fi= xes that. BTW: The way Bitcoin currently stands in its cryptography sti= ll needs updating regardless. If someone figures out NP hardness or the= halting problem the traditional rule of millions of years to break all= of Bitcoin's cryptography now comes down to minutes. Bitcoin is going = to have to eventually radically upgrade their cryptography and hashing = algo in the future regardless. I want to integrate some form of NP comp= lexity in regards to the hybrid cryptography I'm aiming to provide whic= h includes a polynomial time algorithm in the cryptography. More than l= ikely the first version of my BTC hard fork will be coded in a way wher= e integrating such complexity in the future only requires a soft fork o= r minor upgrade to its chain. >>>> >>> >>>> >>> In regards to the argument, "As a separate issue, proposing a = hard fork in the hashing algorithm will invalidate the enormous amount = of capital expenditure by mining entities and disincentivize future cap= ital expenditure into mining hardware that may compute these more "usef= ul" proofs of work." >>>> >>> >>>> >>> A large portion of BTC is already mined through AWS servers an= d non-asic specific hardware anyways. A majority of them would benefit = from a hybrid proof, and the fact that it is hybrid in that manner woul= dn't disenfranchise currently optimized mining entities as well. >>>> >>> >>>> >>> There are other reasons why a cryptography upgrade like this i= s beneficial. Theoretically one can argue BItcoin isn't fully decentral= ized. It is few unsolved mathematical proofs away from being entirely b= roken. My goal outside of efficiency is to build cryptography in a way = that prevents such an event from happening in the future, if it was to = ever happen. I have various research in regards to this area and work a= lot with distributed computing. I believe if the BTC community likes su= ch a proposal, I would single handedly be able to build the cryptograph= ic proof myself (though would like as many open source contributors as = I can get :) >>>> >>> >>>> >>> Anyways just something to consider. We are in the same space i= n regards to what warrants a shitcoin or the whole argument against sta= king. >>>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocu= rrency-stop-telling-us-that-you-arent-pi3s3yjl >>>> >>> >>>> >>> Best regards,=C2=A0 Andrew >>>> >>> >>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland wrote: >>>> >>>> >>>> >>>> It is important to understand that it is critical for the wor= k to be "useless" in order for the security model to be the same. If th= e work was useful it provides an avenue for actors to have nothing at s= take when submitting a proof of work, since the marginal cost of block = construction will be lessened by the fact that the work was useful in a= different context and therefore would have been done anyway. This actu= ally degrades the security of the network in the process. >>>> >>>> >>>> >>>> As a separate issue, proposing a hard fork in the hashing alg= orithm will invalidate the enormous amount of capital expenditure by mi= ning entities and disincentivize future capital expenditure into mining= hardware that may compute these more "useful" proofs of work. This is = because any change in the POW algorithm will be considered unstable and= subject to change in the future. This puts the entire network at even = more risk meaning that no entity is tying their own interests to that o= f the bitcoin network at large. It also puts the developers in a positi= on where they can be bribed by entities with a vested interest in decid= ing what the new "useful" proof of work should be. >>>> >>>> >>>> >>>> All of these things make the Bitcoin network worse off. >>>> >>>> >>>> >>>> Keagan >>>> >>>> >>>> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-= dev wrote: >>>> >>>>> >>>> >>>>> Also in regards to my other email, I forgot to iterate that = my cryptography proposal helps behind the efficiency category but also = tackles problems such as NP-Completeness or Halting which is something = the BTC network could be vulnerable to in the future. For sake of simpl= icity, I do want to do this BIP because it tackles lots of the issues i= n regards to this manner and can provide useful insight to the communit= y. If things such as bigger block height have been proposed as hard for= ks, I feel at the very least an upgrade regarding the hashing algorithm= and cryptography does at least warrant some discussion. Anyways I hope= I can send you my BIP, just let me know on the preferred format? >>>> >>>>> >>>> >>>>> Best regards, Andrew >>>> >>>>> >>>> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation wrote: >>>> >>>>>> >>>> >>>>>> Hi, this isn't about the energy efficient argument in regar= ds to renewables or mining devices but a better cryptography layer to g= et the most out of your hashing for validation. I do understand the arb= itrariness of it, but do want to still propose a document. Do I use the= Media Wiki format on GitHub and just attach it as my proposal? >>>> >>>>>> >>>> >>>>>> Best regards, Andrew >>>> >>>>>> >>>> >>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom wrote: >>>> >>>>>>> >>>> >>>>>>> Hi Ryan and Andrew, >>>> >>>>>>> >>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev = wrote: >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>>=C2=A0 =C2=A0https://www.truthcoin.info/blog/pow-cheapest/= >>>> >>>>>>>>=C2=A0 =C2=A0 =C2=A0"Nothing is Cheaper than Proof of Work= " >>>> >>>>>>>>=C2=A0 =C2=A0 =C2=A0on | 04 Aug 2015 >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>>> Just to belabor this a bit, the paper demonstrates that th= e mining market will tend to expend resources equivalent to miner rewar= d.=C2=A0 It does not prove that mining work has to expend *energy* as a= primary cost. >>>> >>>>>>> >>>> >>>>>>> Some might argue that energy expenditure has negative exte= rnalities and that we should move to other resources.=C2=A0 I would arg= ue that the negative externalities will go away soon because of the mov= e to renewables, so the point is likely moot. >>>> >>>>>>> >>>> >>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F >>>> >>>>> bitcoin-dev mailing list >>>> >>>>> bitcoin-dev@lists.linuxfoundation.org >>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d= ev >>>> >>> >>>> >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F >>>> >>> bitcoin-dev mailing list >>>> >>> bitcoin-dev@lists.linuxfoundation.org >>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev= >>>> > >>>> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F >>>> > bitcoin-dev mailing list >>>> > bitcoin-dev@lists.linuxfoundation.org >>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =C2=A0 =C2=A0 ------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Length: 25217

My email was not intended as an insult.  Your proposal seeme= d a bit like gibberish and made some obvious mistakes as pointed out be= fore (such as conflating secp256k1 with sha256), and so I was genuinely= curious if you were a bot spamming the list.

 

M= aybe a more interesting topic is, can GPT3 be used to generate a BIP?&n= bsp; How long before our AI overlord produces improvements to Bitcoin?&= nbsp; At what point will the AI have more than 51% of commit frequency?=   Will we have lost the war to our new centralized overlord?


Cheers,
-Yancy


On Saturday, March 13, = 2021 00:31 CET, Lonero Foundation <loneroassociation@gmail.com> w= rote:
 
A= lso, I already stated I was referring to signature validation cryptogra= phy in that aspect: https://wizardforcel.gitbooks.io/practical-cry= ptography-for-developers-book/content/digital-signatures/ecdsa-sign-ver= ify-examples.html
My BIP has a primary purpose in regards= to what I want to develop proofs for and the different cryptographic e= lements I want to develop proofs for.
That said to those who = disagree with the premise, I do prefer constructive feedback over insul= ts or making fun of one another. After all this is an improvement propo= sal with a specific purpose aiming to develop a specific thing, not a g= uy who is just wanting to copy and paste a repository and call it a day= .
 
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 c= reate a BTC hardfork or become another Bitcoin Cash, Gold, or SV. The m= ain point in regards to this BIP actually expands POW rather than repla= ces or creates an alternative. Many of the problems faced in regards to= security in the future as well as sustainability is something I believ= e lots of the changes I am proposing can fix. In regards to technologic= al implementation, once this is assigned draft status I am more than wi= lling to create preprints explaining the cryptography, hashing algorith= m improvements, and consensus that I am working on. This is a highly te= chnologically complex idea that I am willing to "call my bluff on" and = expand upon. As for it being a draft, I think this is a good starting p= oint at least for draft status prior to working on technological implem= entation.
 
Best regards, Andrew
&n= bsp;
On Fri, Mar 12, 2021 at 5:37 PM email@yancy.lol <email@yancy.lol&g= t; wrote:
= I think Andrew himself is an algo.  The crypto training set must n= ot be very good.

Cheers,
-Yancy

On Friday, M= arch 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:
 
Hi, I awkwardly ph= rased that part, I was referring to key validation in relation to that = section as well as the hashing related to those keys. I might rephrase = it. 
 
In regards to = technical merit, the main purpose of the BIP is to get a sense of the i= dea. Once I get assigned a BIP draft #, I am willing to follow it up wi= th many preprints or publications to go in the references implementatio= n section and start dev work before upgrading to final status.
 
This will take about 400 h= ours of my time, but is something I am personally looking into developi= ng as a hard fork.
 
Keep in mind this is a draft, so after it is assigned a number to refe= rences I do at the very least hope to describe various parts of the cry= ptographic proofs and algorithmic structure I am hoping for.
 
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=5Fof=5Fburn
h= ttps://bitcointalk.org/index.php?topic=3D225690.0

proof-= of-burn is a nice alternative to proof-of-work.   i alwayssuspected that, if designed correctly, it could be a proven
equ= ivalent.   you could spin up a fork of bitcoin that allows ag= ed,
burned, coins instead of POW that would probably work just fin= e.

- erik

On Thu, Mar 11, 2021 at 11:56 AM Lonero= Foundation via bitcoin-dev
<bitcoin-de= v@lists.linuxfoundation.org> wrote:
>
> Hi, I ha= ve submitted the BIP Pull Request here: https://github.com/bitcoin/bips/pull/1084
>
> Hop= ing to receive a BIP # for the draft prior to development/reference imp= lementation.
>
> Best regards, Andrew
>
&g= t; On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <lo= neroassociation@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.mediawiki
&g= t;> Can I submit a pull request on the BIPs repo for this to go into= draft mode? Also, I think this provides at least some more insight on = what I want to work on.
>>
>> Best regards, Andre= w
>>
>> On Sat, Mar 6, 2021, 10:42 AM Lonero Foun= dation <loneroassociation@gmail.com> wrote:>>>
>>> [off-list]
>>>
>= ;>> Okay. I will do so and post the link here for discussion befo= re doing a pull request on BIP's repo as the best way to handle it.
>>>
>>> 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
>>>>
&= gt;>>> Lonero Foundation via bitcoin-dev
>>>>= <bitcoin-dev@lists.linuxfoundation.org= > escreveu no dia s=C3=A1bado,
>>>> 6/03/2021 =C3=A0= (s) 08:58:
>>>> >
>>>> > I know= Ethereum had an outlandishly large percentage of nodes running on AWS,= I heard the same thing is for Bitcoin but for mining. Had trouble find= ing the article online so take it with a grain of salt. The point thoug= h is that both servers and ASIC specific hardware would still be able t= o benefit from the cryptography upgrade I am proposing, as this was in = relation to the disinfranchisemet point.
>>>> >
>>>> > That said, I think the best way to move forward= is to submit a BIP pull request for a draft via GitHub using BIP #2's = draft format and any questions people have can be answered in the reqeu= st's comments. That way people don't have to get emails everytime there= is a reply, but replies still get seen as opposed to offline discussio= n. Since the instructions say to email bitcoin-dev before doing a bip d= raft, I have done that. Since people want to see the draft beforehand a= nd it isn't merged manually anyways, I think it is the easiest way to h= andle this.
>>>> >
>>>> > I'm a= lso okay w/ continuing the discussion on bitcoin-dev but rather form a = discussion on git instead given I don't want to accidentally impolitely= bother people given this is a moderated list and we already establishe= d some interest for at least a draft.
>>>> >
&= gt;>>> > Does that seem fine?
>>>> >>>>> > Best regards, Andrew
>>>> >= ;
>>>> > On Fri, Mar 5, 2021, 7:41 PM Keagan McClel= land <keagan.mcclelland@gmail.com> wrote:
>>>> >>
>>>> >> > A large = portion of BTC is already mined through AWS servers and non-asic specif= ic hardware anyways. A majority of them would benefit from a hybrid pro= of, and the fact that it is hybrid in that manner wouldn't disenfranchi= se currently optimized mining entities as well.
>>>> &= gt;>
>>>> >> My instincts tell me that this i= s an outlandish claim. Do you have supporting evidence for this?
&= gt;>>> >>
>>>> >> Keagan
>= ;>>> >>
>>>> >> On Fri, Mar 5, 20= 21 at 3:22 PM Lonero Foundation via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>= ;>> >>>
>>>> >>> Actually I me= ntioned a proof of space and time hybrid which is much different than s= taking. Sorry to draw for the confusion as PoC is more commonly used th= en PoST.
>>>> >>> There is a way to make PoC = cryptographically compatible w/ Proof of Work as it normally stands: https://en.wikipedia.org/wiki/Pro= of=5Fof=5Fspace
>>>> >>> It has rarely be= en done though given the technological complexity of being both CPU com= patible and memory-hard compatible. There are lots of benefits outside = of the realm of efficiency, and I already looked into numerous fault to= lerant designs as well and what others in the cryptography community at= tempted to propose. The actual argument you have only against this is t= he Proof of Memory fallacy, which is only partially true. Given how the= current hashing algorithm works, hard memory allocation wouldn't be of= much benefit given it is more optimized for CPU/ASIC specific mining. = I'm working towards a hybrid mechanism that fixes that. BTW: The way Bi= tcoin currently stands in its cryptography still needs updating regardl= ess. If someone figures out NP hardness or the halting problem the trad= itional rule of millions of years to break all of Bitcoin's cryptograph= y now comes down to minutes. Bitcoin is going to have to eventually rad= ically upgrade their cryptography and hashing algo in the future regard= less. I want to integrate some form of NP complexity in regards to the = hybrid cryptography I'm aiming to provide which includes a polynomial t= ime algorithm in the cryptography. More than likely the first version o= f my BTC hard fork will be coded in a way where integrating such comple= xity in the future only requires a soft fork or minor upgrade to its ch= ain.
>>>> >>>
>>>> >>&= gt; In regards to the argument, "As a separate issue, proposing a hard = fork in the hashing algorithm will invalidate the enormous amount of ca= pital expenditure by mining entities and disincentivize future capital = expenditure into mining hardware that may compute these more "useful" p= roofs of work."
>>>> >>>
>>>>= ; >>> A large portion of BTC is already mined through AWS serv= ers and non-asic specific hardware anyways. A majority of them would be= nefit from a hybrid proof, and the fact that it is hybrid in that manne= r wouldn't disenfranchise currently optimized mining entities as well.<= br />>>>> >>>
>>>> >>> T= here are other reasons why a cryptography upgrade like this is benefici= al. Theoretically one can argue BItcoin isn't fully decentralized. It i= s few unsolved mathematical proofs away from being entirely broken. My = goal outside of efficiency is to build cryptography in a way that preve= nts such an event from happening in the future, if it was to ever happe= n. I have various research in regards to this area and work alot with d= istributed computing. I believe if the BTC community likes such a propo= sal, I would single handedly be able to build the cryptographic proof m= yself (though would like as many open source contributors as I can get = :)
>>>> >>>
>>>> >>>= ; Anyways just something to consider. We are in the same space in regar= ds to what warrants a shitcoin or the whole argument against staking.>>>> >>> https://= hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telli= ng-us-that-you-arent-pi3s3yjl
>>>> >>>>>>> >>> Best regards,  Andrew
>&g= t;>> >>>
>>>> >>> On Fri, Mar = 5, 2021 at 4:11 PM Keagan McClelland <keagan.mcclellan= d@gmail.com> wrote:
>>>> >>>>
= >>>> >>>> It is important to understand that it= is critical for the work to be "useless" in order for the security mod= el to be the same. If the work was useful it provides an avenue for act= ors to have nothing at stake when submitting a proof of work, since the= marginal cost of block construction will be lessened by the fact that = the work was useful in a different context and therefore would have bee= n done anyway. This actually degrades the security of the network in th= e process.
>>>> >>>>
>>>>= >>>> As a separate issue, proposing a hard fork in the has= hing algorithm will invalidate the enormous amount of capital expenditu= re by mining entities and disincentivize future capital expenditure int= o mining hardware that may compute these more "useful" proofs of work. = This is because any change in the POW algorithm will be considered unst= able and subject to change in the future. This puts the entire network = at even more risk meaning that no entity is tying their own interests t= o that of the bitcoin network at large. It also puts the developers in = a position where they can be bribed by entities with a vested interest = in deciding what the new "useful" proof of work should be.
>>= ;>> >>>>
>>>> >>>> All o= f these things make the Bitcoin network worse off.
>>>>= ; >>>>
>>>> >>>> Keagan
&= gt;>>> >>>>
>>>> >>>>= On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitcoin-dev <<= a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lis= ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org> w= rote:
>>>> >>>>>
>>>> = >>>>> Also in regards to my other email, I forgot to ite= rate that my cryptography proposal helps behind the efficiency category= but also tackles problems such as NP-Completeness or Halting which is = something the BTC network could be vulnerable to in the future. For sak= e of simplicity, I do want to do this BIP because it tackles lots of th= e issues in regards to this manner and can provide useful insight to th= e community. If things such as bigger block height have been proposed a= s hard forks, I feel at the very least an upgrade regarding the hashing= algorithm and cryptography does at least warrant some discussion. Anyw= ays I hope I can send you my BIP, just let me know on the preferred for= mat?
>>>> >>>>>
>>>> &= gt;>>>> Best regards, Andrew
>>>> >>= >>>
>>>> >>>>> On Fri, Mar 5, = 2021, 10:12 AM Lonero Foundation <loneroassociation@gm= ail.com> wrote:
>>>> >>>>>>>>>> >>>>>> Hi, this isn't about the = energy efficient argument in regards to renewables or mining devices bu= t a better cryptography layer to get the most out of your hashing for v= alidation. I do understand the arbitrariness of it, but do want to stil= l propose a document. Do I use the Media Wiki format on GitHub and just= attach it as my proposal?
>>>> >>>>>&g= t;
>>>> >>>>>> Best regards, Andrew<= br />>>>> >>>>>>
>>>> &g= t;>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <c1.devrandom@niftybox.net> wrote:
>>>>= >>>>>>>
>>>> >>>>>= ;>> Hi Ryan and Andrew,
>>>> >>>>>= ;>>
>>>> >>>>>>> On Fri, Ma= r 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>= ;>> >>>>>>>>
>>>> >&g= t;>>>>>>
>>>> >>>>>&g= t;>>   https://www= .truthcoin.info/blog/pow-cheapest/
>>>> >>&g= t;>>>>>     "Nothing is Cheaper than Proo= f of Work"
>>>> >>>>>>>> =    on | 04 Aug 2015
>>>> >>>>&g= t;>>>
>>>> >>>>>>>
= >>>> >>>>>>> Just to belabor this a bi= t, the paper demonstrates that the mining market will tend to expend re= sources equivalent to miner reward.  It does not prove that mining= work has to expend *energy* as a primary cost.
>>>> &= gt;>>>>>>
>>>> >>>>>&= gt;> Some might argue that energy expenditure has negative externali= ties and that we should move to other resources.  I would argue th= at the negative externalities will go away soon because of the move to = renewables, so the point is likely moot.
>>>> >>= >>>>>
>>>> >>>>> =5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>&= gt;>> >>>>> bitcoin-dev mailing list
>>= >> >>>>> bitcoin-dev@list= s.linuxfoundation.org
>>>> >>>>> https://lists.linux= foundation.org/mailman/listinfo/bitcoin-dev
>>>> &= gt;>>
>>>> >>> =5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>>>> >= ;>> bitcoin-dev mailing list
>>>> >>> <= a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lis= ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org
= >>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev
>>>> >
>>>> > =5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>&= gt;>> > bitcoin-dev mailing list
>>>> > bitcoin-dev@lists.linuxfoundation.org
&= gt;>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br />>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxf= oundation.org/mailman/listinfo/bitcoin-dev



 



  ------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539--------