Return-Path: <loneroassociation@gmail.com> Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B0C33C0001 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 15:02:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 88D954AC55 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 15:02:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, T_KAM_HTML_FONT_INVALID=0.01] 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 WGxR_08VEYsv for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 15:02:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by smtp4.osuosl.org (Postfix) with ESMTPS id BD78C4EC18 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 15:02:17 +0000 (UTC) Received: by mail-yb1-xb35.google.com with SMTP id h82so28491555ybc.13 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 13 Mar 2021 07:02:17 -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=hcBEiK5BT6uwq787bPfzTCYpHaLxLWoMBfkCR5OTfnk=; b=QVpDB9WvdtrG1xSJvR2iPUS5/3DDhpTx4Yrf+CLQ6thaVEdbkPIoM2meWVMfDwB0X7 yohucjb/CNGyxXtW9qCFawbKSYuQ3E6jW5ZBLn8oBbTAVKNk6iqNW+S+e4MOZ0xmSQM+ GGMbQxjP5LaetW7u9ZoK5v2CBCE2/ZWLr3e5VBYwE021tKKGfh6c6qCY6Sun/PBBozS/ yXNeXw5cgx8l4vVHqPIh3MTMoLCkjqHMcW3IAr1I9f21za2nrK8vqaYSLagMsSwjpzHU lTYxh/7hN/zX+V8H3bnPV4fN/zl2TyMmuTgXOnot32F2XUiadK7Xhr9xNd02cIqr5E21 nELw== 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=hcBEiK5BT6uwq787bPfzTCYpHaLxLWoMBfkCR5OTfnk=; b=CVRG9ZhmVmc3BzfuVuEXkOpiyxuxALjK+IJNzXGD5K1gjomj2O/bxanMaSG70nxbNU Qx+lOj3J9XKpRchH61T+yEo5HOUKSCueQuCNt34rG2E2dr6tLMDaWzAatysywh5oQrns YHZq+LNz63HCECbdUttvJ+uW2rBnWc3bW8WimbijEqoEIwo5uq+yP3dMZOeWmNo+NOEX 1ISluiteMWGnObnauzhHGfiExhGxu6Vpu0rOEA4ghBoNmPPq2xE7sGm43MEMvd660iAJ GJria6sBktaH/YgTF0g86ldXfGWZIQgjs6XeNFy+dNsl7+lYLCYljXPsF/CQdLDLWF6l m/Rw== X-Gm-Message-State: AOAM531OoPt1LRB7PSzxD1W2XBvbgCuNXbrODZ6rIEaUfGnniAAWVAPH tzVhrZf/Hty8AFYXtYDxMvyHSi22PyelU1srSrM= X-Google-Smtp-Source: ABdhPJysH1McyVhgBw3OTNoNUwwC5qq7YwyawXdEmuQ5uGjHXwqHjNj8x2HL0r/UngZRenDe2bYUzUdA8XsKJGl7Gqc= X-Received: by 2002:a5b:591:: with SMTP id l17mr26191754ybp.60.1615647736601; Sat, 13 Mar 2021 07:02:16 -0800 (PST) MIME-Version: 1.0 References: <CA+YkXXw5uh4yfvqDiBBEXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com> <1802-604c7400-4d1-7b635e80@91248813> In-Reply-To: <1802-604c7400-4d1-7b635e80@91248813> From: Lonero Foundation <loneroassociation@gmail.com> Date: Sat, 13 Mar 2021 10:02:05 -0500 Message-ID: <CA+YkXXzPt8vf=bfpW+NBqH_G7sTiyFcGSZa+j31Fx_O5ir93Cw@mail.gmail.com> To: email@yancy.lol Content-Type: multipart/alternative; boundary="0000000000006c1e8705bd6c4d79" 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: Sat, 13 Mar 2021 15:02:20 -0000 --0000000000006c1e8705bd6c4d79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I know the differences between the cryptographic hashing algorithm and key validation. I know hashing is for SHA, but was referring to asymmetric cryptography in regards to the key validation. I should have used a different term though instead of, "In regards to cryptographic hashing,", I should have stated in regards to cryptographic key validation. There are a few other dubious clarifications or minor edits I should make in order to not draw confusion. I will do a repo update today. Honest mistake, but enough with the sarcasm. Best regards, Andrew On Sat, Mar 13, 2021, 3:13 AM email@yancy.lol <email@yancy.lol> wrote: > My email was not intended as an insult. Your proposal seemed a bit like > gibberish and made some obvious mistakes as pointed out before (such as > conflating secp256k1 with sha256), and so I was genuinely curious if you > were a bot spamming the list. > > > Maybe a more interesting topic is, can GPT3 be used to generate a BIP? > How long before our AI overlord produces improvements to Bitcoin? At wha= t > 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> wrote: > > > Also, I already stated I was referring to signature validation > cryptography in that aspect: > https://wizardforcel.gitbooks.io/practical-cryptography-for-developers-bo= ok/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 constructiv= e > 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 >> 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 chan= ges >> 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 consens= us >> 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 draf= t, >> 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 reference= s >>> implementation section and start dev work before upgrading to final sta= tus. >>> >>> 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.me= diawiki >>>> >> 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, Andrew >>>> >> >>>> >> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation < >>>> loneroassociation@gmail.com> wrote: >>>> >>> >>>> >>> [off-list] >>>> >>> >>>> >>> Okay. I will do so and post the link here for discussion before >>>> doing a pull request on BIP's repo as the best way to handle it. >>>> >>> >>>> >>> Best regards, Andrew >>>> >>> >>>> >>> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe < >>>> ricardojdfilipe@gmail.com> wrote: >>>> >>>> >>>> >>>> As said before, you are free to create the BIP in your own >>>> repository >>>> >>>> and bring it to discussion on the mailing list. then you can do a >>>> PR >>>> >>>> >>>> >>>> Lonero Foundation via bitcoin-dev >>>> >>>> <bitcoin-dev@lists.linuxfoundation.org> escreveu no dia s=C3=A1ba= do, >>>> >>>> 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 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 sti= ll 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 >>>> BIP pull request for a draft via GitHub using BIP #2's draft format an= d any >>>> questions people have can be answered in the reqeust's comments. That = way >>>> people don't have to get emails everytime there is a reply, but replie= s >>>> still get seen as opposed to offline discussion. Since the instruction= s 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 accident= ally >>>> 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 benef= it >>>> 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 >>>> 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 i= s >>>> 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. Th= ere >>>> 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 h= ave >>>> only against this is the Proof of Memory fallacy, which is only partia= lly >>>> true. Given how the current hashing algorithm works, hard memory alloc= ation >>>> 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 tha= t. >>>> 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 Bitc= oin's >>>> cryptography now comes down to minutes. Bitcoin is going to have to >>>> eventually radically upgrade their cryptography and hashing algo in th= e >>>> future regardless. I want to integrate some form of NP complexity in >>>> regards to the hybrid cryptography I'm aiming to provide which include= s a >>>> polynomial time algorithm in the cryptography. More than likely the fi= rst >>>> version of my BTC hard fork will be coded in a way where integrating s= uch >>>> 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 capit= al >>>> 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 benef= it >>>> from a hybrid proof, and the fact that it is hybrid in that manner wou= ldn'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 outside of efficiency is to build cryptograph= y 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 wo= rk >>>> alot with distributed computing. I believe if the BTC community likes = such >>>> a proposal, I would single handedly be able to build the cryptographic >>>> 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 >>>> in regards to what warrants a shitcoin or the whole argument against >>>> staking. >>>> >>>> >>> >>>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-s= top-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. I= f the >>>> work was useful it provides an avenue for actors to have nothing at st= ake >>>> 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 >>>> algorithm will invalidate the enormous amount of capital expenditure b= y >>>> mining entities and disincentivize future capital expenditure into min= ing >>>> hardware that may compute these more "useful" proofs of work. This is >>>> because any change in the POW algorithm will be considered unstable an= d >>>> 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 th= e >>>> bitcoin network at large. It also puts the developers in a position wh= ere >>>> they can be bribed by entities with a vested interest in deciding what= the >>>> new "useful" proof of work should be. >>>> >>>> >>>> >>>> >>>> >>>> All of these things make the Bitcoin network worse off. >>>> >>>> >>>> >>>> >>>> >>>> Keagan >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via >>>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> >>>> >>>>> >>>> >>>> >>>>> Also in regards to my other email, I forgot to iterate that >>>> my cryptography proposal helps behind the efficiency category but also >>>> tackles problems such as NP-Completeness or Halting which is something= the >>>> BTC network could be vulnerable to in the future. For sake of simplici= ty, I >>>> do want to do this BIP because it tackles lots of the issues in regard= s 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, j= ust >>>> 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 laye= r 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 >>>> 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 arg= ue >>>> 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-dev >>>> >>>> >>> >>>> >>>> >>> _______________________________________________ >>>> >>>> >>> 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 >>> >>> >>> >>> >>> >> >> > > > --0000000000006c1e8705bd6c4d79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Hi, I know the differences between the cryptographic hash= ing algorithm and key validation. I know hashing is for SHA, but was referr= ing to=C2=A0<span>asymmetric cryptography in regards to the key validation.= I should have used a different term though instead of, "In regards to= cryptographic hashing,", I should have stated in regards to cryptogra= phic key validation. There are a few other dubious clarifications or minor = edits I should make in order to not draw confusion. I will do a repo update= today. Honest mistake, but enough with the sarcasm.</span><div dir=3D"auto= "><span><br></span></div><div dir=3D"auto">Best regards, Andrew</div></div>= <br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat= , Mar 13, 2021, 3:13 AM email@yancy.lol <email@yancy.lol> wrote:<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr" style=3D"line-height:1.3= 8;margin-top:0pt;margin-bottom:0pt" id=3D"m_-7605373105595509035m_815842019= 9876589271m_-1581779554600417290m_-1741129009180998294m_3490105251412115872= m_-7757793637796267019m_-5697419812760722977docs-internal-guid-4056a8b1-7ff= f-9296-3427-4d2e04c785c7"><span style=3D"font-size:11pt;font-family:Arial;b= ackground-color:transparent;font-weight:400;font-style:normal;font-variant:= normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">M= y email was not intended as an insult.=C2=A0 Your proposal seemed a bit lik= e gibberish and made some obvious mistakes as pointed out before (such as c= onflating secp256k1 with sha256), and so I was genuinely curious if you wer= e a bot spamming the list.</span></p>=C2=A0<p dir=3D"ltr" style=3D"line-hei= ght:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;fo= nt-family:Arial;background-color:transparent;font-weight:400;font-style:nor= mal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-= space:pre-wrap">Maybe a more interesting topic is, can GPT3 be used to gene= rate 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 frequ= ency?=C2=A0 Will we have lost the war to our new centralized overlord?</spa= n></p><br>Cheers,<br>-Yancy<br><br><br>On Saturday, March 13, 2021 00:31 CE= T, Lonero Foundation <<a href=3D"mailto:loneroassociation@gmail.com" rel= =3D"noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noref= errer" target=3D"_blank">loneroassociation@gmail.com</a>> wrote:<br>=C2= =A0<blockquote type=3D"cite" cite=3D"http://CA+YkXXw5uh4yfvqDiBBEXcq188PEGk= u-NFFAq7uNuAFTG3ooTQ@mail.gmail.com"><div dir=3D"ltr"><div>Also, I already = stated I was referring to signature validation cryptography in that aspect:= <a href=3D"https://wizardforcel.gitbooks.io/practical-cryptography-for-dev= elopers-book/content/digital-signatures/ecdsa-sign-verify-examples.html" re= l=3D"noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer nore= ferrer" target=3D"_blank">https://wizardforcel.gitbooks.io/practical-crypto= graphy-for-developers-book/content/digital-signatures/ecdsa-sign-verify-exa= mples.html</a></div><div>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.</div><div>That said to those who disagree with the p= remise, 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.</div><div>=C2=A0</div><div>Best r= egards, Andrew</div></div>=C2=A0<div class=3D"gmail_quote"><div dir=3D"ltr"= class=3D"gmail_attr">On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation <= ;<a href=3D"mailto:loneroassociation@gmail.com" rel=3D"noreferrer noreferre= r noreferrer noreferrer noreferrer noreferrer noreferrer" target=3D"_blank"= >loneroassociation@gmail.com</a>> wrote:</div><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= ,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi, I also want to emphasize = that my main point isn't just to create a BTC hardfork or become anothe= r 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 pr= oblems 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 rega= rds to technological implementation, once this is assigned draft status I a= m more than willing to create preprints explaining the cryptography, hashin= g algorithm improvements, and consensus that I am working on. This is a hig= hly technologically complex idea that I am willing to "call my bluff o= n" and expand upon. As for it being a draft, I think this is a good st= arting point at least for draft status prior to working on technological im= plementation.</div><div>=C2=A0</div><div>Best regards, Andrew</div></div>= =C2=A0<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On F= ri, Mar 12, 2021 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote:<= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex">I think Andrew himse= lf is an algo.=C2=A0 The crypto training set must not be very good.<br><br>= Cheers,<br>-Yancy<br><br>On Friday, March 12, 2021 17:54 CET, Lonero Founda= tion via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio= n.org" rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer norefe= rrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a= >> wrote:<br>=C2=A0<blockquote type=3D"cite" cite=3D"http://CA+YkXXz9aHf= Ztt-it_8w4ovF=3D-QaZ4_9vwDS0Kz36qhHwVDC5Q@mail.gmail.com"><div dir=3D"auto"= >Hi, I awkwardly phrased that part, I was referring to key validation in re= lation to that section as well as the hashing related to those keys. I migh= t rephrase it.=C2=A0<div dir=3D"auto">=C2=A0</div><div dir=3D"auto">In rega= rds to technical merit, the main purpose of the BIP is to get a sense of th= e idea. Once I get assigned a BIP draft #, I am willing to follow it up wit= h many preprints or publications to go in the references implementation sec= tion and start dev work before upgrading to final status.</div><div dir=3D"= auto">=C2=A0</div><div dir=3D"auto">This will take about 400 hours of my ti= me, but is something I am personally looking into developing as a hard fork= .</div><div dir=3D"auto">=C2=A0</div><div dir=3D"auto">Keep in mind this is= a draft, so after it is assigned a number to references I do at the very l= east hope to describe various parts of the cryptographic proofs and algorit= hmic 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 A= ronesty <<a href=3D"mailto:erik@q32.com" rel=3D"noreferrer noreferrer no= referrer noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">eri= k@q32.com</a>> wrote:</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= 1ex">secp236k1 isn't a hashing algo.=C2=A0 =C2=A0your BIP needs about 1= 0 more pages<br>and some degree of technical merit.<br><br>i suggest you st= art here:<br><br><a rel=3D"noreferrer noreferrer noreferrer noreferrer nore= ferrer noreferrer noreferrer noreferrer noreferrer" href=3D"https://en.bitc= oin.it/wiki/Proof_of_burn" target=3D"_blank">https://en.bitcoin.it/wiki/Pro= of_of_burn</a><br><a rel=3D"noreferrer noreferrer noreferrer noreferrer nor= eferrer noreferrer noreferrer noreferrer noreferrer" href=3D"https://bitcoi= ntalk.org/index.php?topic=3D225690.0" target=3D"_blank">https://bitcointalk= .org/index.php?topic=3D225690.0</a><br><br>proof-of-burn is a nice alternat= ive to proof-of-work.=C2=A0 =C2=A0i always<br>suspected that, if designed c= orrectly, it could be a proven<br>equivalent.=C2=A0 =C2=A0you could spin up= a fork of bitcoin that allows aged,<br>burned, coins instead of POW that w= ould probably work just fine.<br><br>- erik<br><br>On Thu, Mar 11, 2021 at = 11:56 AM Lonero Foundation via bitcoin-dev<br><<a rel=3D"noreferrer nore= ferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" h= ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc= oin-dev@lists.linuxfoundation.org</a>> wrote:<br>><br>> Hi, I have= submitted the BIP Pull Request here: <a rel=3D"noreferrer noreferrer noref= errer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" hr= ef=3D"https://github.com/bitcoin/bips/pull/1084" target=3D"_blank">https://= github.com/bitcoin/bips/pull/1084</a><br>><br>> Hoping to receive a B= IP # for the draft prior to development/reference implementation.<br>><b= r>> Best regards, Andrew<br>><br>> On Mon, Mar 8, 2021, 6:40 PM Lo= nero Foundation <<a rel=3D"noreferrer noreferrer noreferrer noreferrer n= oreferrer noreferrer noreferrer noreferrer" href=3D"mailto:loneroassociatio= n@gmail.com" target=3D"_blank">loneroassociation@gmail.com</a>> wrote:<b= r>>><br>>> Hi, here is the list to the BIP proposal on my own r= epo: <a rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer noref= errer noreferrer noreferrer noreferrer" href=3D"https://github.com/Mentors4= EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki" target=3D"_blank">https= ://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki</a= ><br>>> Can I submit a pull request on the BIPs repo for this to go i= nto draft mode? Also, I think this provides at least some more insight on w= hat I want to work on.<br>>><br>>> Best regards, Andrew<br>>= ><br>>> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <<a rel= =3D"noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noref= errer noreferrer" href=3D"mailto:loneroassociation@gmail.com" target=3D"_bl= ank">loneroassociation@gmail.com</a>> wrote:<br>>>><br>>>= > [off-list]<br>>>><br>>>> 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.<br>>>><br>>>> Best regards= , Andrew<br>>>><br>>>> On Sat, Mar 6, 2021, 10:21 AM Rica= rdo Filipe <<a rel=3D"noreferrer noreferrer noreferrer noreferrer norefe= rrer noreferrer noreferrer noreferrer" href=3D"mailto:ricardojdfilipe@gmail= .com" target=3D"_blank">ricardojdfilipe@gmail.com</a>> wrote:<br>>>= ;>><br>>>>> As said before, you are free to create the BI= P in your own repository<br>>>>> and bring it to discussion on = the mailing list. then you can do a PR<br>>>>><br>>>>&= gt; Lonero Foundation via bitcoin-dev<br>>>>> <<a rel=3D"nor= eferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer n= oreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"= _blank">bitcoin-dev@lists.linuxfoundation.org</a>> escreveu no dia s=C3= =A1bado,<br>>>>> 6/03/2021 =C3=A0(s) 08:58:<br>>>>>= ><br>>>>> > I know Ethereum had an outlandishly large pe= rcentage of nodes running 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. 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 was in relation to the disinfranchisemet point.<br>>>>&g= t; ><br>>>>> > That said, I think the best way to move fo= rward is to submit a BIP pull request for a draft via GitHub using BIP #2&#= 39;s draft format and any questions people have can be answered in the reqe= ust'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 discussi= on. Since the instructions say to email bitcoin-dev before doing a bip draf= t, I have done that. Since people want to see the draft beforehand and it i= sn't merged manually anyways, I think it is the easiest way to handle t= his.<br>>>>> ><br>>>>> > I'm also okay w/= continuing the discussion on bitcoin-dev but rather form a discussion on g= it instead given I don't want to accidentally impolitely bother people = given this is a moderated list and we already established some interest for= at least a draft.<br>>>>> ><br>>>>> > Does t= hat seem fine?<br>>>>> ><br>>>>> > Best regar= ds, Andrew<br>>>>> ><br>>>>> > On Fri, Mar 5,= 2021, 7:41 PM Keagan McClelland <<a rel=3D"noreferrer noreferrer norefe= rrer noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D"mailto= :keagan.mcclelland@gmail.com" target=3D"_blank">keagan.mcclelland@gmail.com= </a>> wrote:<br>>>>> >><br>>>>> >> &= gt; A large portion of BTC is already mined through AWS servers and non-asi= c 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 disenfra= nchise currently optimized mining entities as well.<br>>>>> >= ;><br>>>>> >> My instincts tell me that this is an out= landish claim. Do you have supporting evidence for this?<br>>>>>= ; >><br>>>>> >> Keagan<br>>>>> >>= <br>>>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundat= ion via bitcoin-dev <<a rel=3D"noreferrer noreferrer noreferrer noreferr= er noreferrer noreferrer noreferrer noreferrer" href=3D"mailto:bitcoin-dev@= lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat= ion.org</a>> wrote:<br>>>>> >>><br>>>>>= >>> Actually I mentioned a proof of space and time hybrid which i= s much different than staking. Sorry to draw for the confusion as PoC is mo= re commonly used then PoST.<br>>>>> >>> There is a way= to make PoC cryptographically compatible w/ Proof of Work as it normally s= tands: <a rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer nor= eferrer noreferrer noreferrer noreferrer" href=3D"https://en.wikipedia.org/= wiki/Proof_of_space" target=3D"_blank">https://en.wikipedia.org/wiki/Proof_= of_space</a><br>>>>> >>> It has rarely been done thoug= h given the technological complexity of being both CPU compatible and memor= y-hard compatible. There are lots of benefits outside of the realm of effic= iency, and I already looked into numerous fault tolerant designs as well an= d what others in the cryptography community attempted to propose. The actua= l argument you have only against this is the Proof of Memory fallacy, which= is only partially true. Given how the current hashing algorithm works, har= d memory allocation wouldn't be of much benefit given it is more optimi= zed for CPU/ASIC specific mining. I'm working towards a hybrid mechanis= m that fixes that. BTW: The way Bitcoin currently stands in its cryptograph= y still needs updating regardless. If someone figures out NP hardness or th= e 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 complexity in r= egards to the hybrid cryptography I'm aiming to provide which includes = a polynomial time algorithm in the cryptography. 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 soft fork or minor upgrade 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 exp= enditure by mining entities and disincentivize future capital expenditure i= nto mining hardware that may compute these more "useful" proofs o= f work."<br>>>>> >>><br>>>>> >>= > A large portion of BTC is already mined through AWS servers and non-as= ic specific hardware anyways. A majority of them would benefit from a hybri= d proof, and the fact that it is hybrid in that manner wouldn't disenfr= anchise currently optimized mining entities as well.<br>>>>> &g= t;>><br>>>>> >>> There are other reasons why a c= ryptography upgrade like this is beneficial. Theoretically one can argue BI= tcoin isn't fully decentralized. It is few unsolved mathematical proofs= away from being entirely broken. My goal outside of efficiency is to build= cryptography in a way that prevents such an event from happening in the fu= ture, 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 communi= ty likes such a proposal, I would single handedly be able to build the cryp= tographic proof myself (though would like as many open source contributors = as I can get :)<br>>>>> >>><br>>>>> >&g= t;> Anyways just something to consider. We are in the same space in rega= rds to what warrants a shitcoin or the whole argument against staking.<br>&= gt;>>> >>> <a rel=3D"noreferrer noreferrer noreferrer nor= eferrer noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D"htt= ps://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-tell= ing-us-that-you-arent-pi3s3yjl" target=3D"_blank">https://hackernoon.com/et= hereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-= pi3s3yjl</a><br>>>>> >>><br>>>>> >>&= gt; Best regards,=C2=A0 Andrew<br>>>>> >>><br>>>= >> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <= <a rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer= noreferrer noreferrer" href=3D"mailto:keagan.mcclelland@gmail.com" target= =3D"_blank">keagan.mcclelland@gmail.com</a>> wrote:<br>>>>> = >>>><br>>>>> >>>> It is important to un= derstand that it is critical for the work to be "useless" in orde= r for the security model to be the same. If the work was useful it provides= an avenue for actors to have nothing at stake when submitting a proof of w= ork, 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 ha= ve been done anyway. This actually degrades the security of the network in = the process.<br>>>>> >>>><br>>>>> >&= gt;>> As a separate issue, proposing a hard fork in the hashing algor= ithm will invalidate the enormous amount of capital expenditure by mining e= ntities and disincentivize future capital expenditure into mining hardware = that may compute these more "useful" proofs of work. This is beca= use 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 me= aning that no entity is tying their own interests to that of the bitcoin ne= twork 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 "u= seful" proof of work should be.<br>>>>> >>>><b= r>>>>> >>>> All of these things make the Bitcoin ne= twork worse off.<br>>>>> >>>><br>>>>> &= gt;>>> Keagan<br>>>>> >>>><br>>>>= > >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via = bitcoin-dev <<a rel=3D"noreferrer noreferrer noreferrer noreferrer noref= errer noreferrer noreferrer noreferrer" href=3D"mailto:bitcoin-dev@lists.li= nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<= /a>> wrote:<br>>>>> >>>>><br>>>>>= >>>>> Also in regards to my other email, I forgot to iterat= e that my cryptography proposal helps behind the efficiency category but al= so tackles problems such as NP-Completeness or Halting which is something t= he 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 = 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 doe= s at least warrant some discussion. Anyways I hope I can send you my BIP, j= ust let me know on the preferred format?<br>>>>> >>>&g= t;><br>>>>> >>>>> Best regards, Andrew<br>>= ;>>> >>>>><br>>>>> >>>>>= On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <<a rel=3D"noreferrer n= oreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer= " href=3D"mailto:loneroassociation@gmail.com" target=3D"_blank">loneroassoc= iation@gmail.com</a>> wrote:<br>>>>> >>>>>>= ;<br>>>>> >>>>>> 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 validati= on. 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 m= y proposal?<br>>>>> >>>>>><br>>>>>= ; >>>>>> Best regards, Andrew<br>>>>> >>= ;>>>><br>>>>> >>>>>> On Fri, Mar = 5, 2021, 10:07 AM Devrandom <<a rel=3D"noreferrer noreferrer noreferrer = noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D"mailto:c1.d= evrandom@niftybox.net" target=3D"_blank">c1.devrandom@niftybox.net</a>> = wrote:<br>>>>> >>>>>>><br>>>>>= >>>>>>> Hi Ryan and Andrew,<br>>>>> >&= gt;>>>>><br>>>>> >>>>>>> On= Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <<a rel=3D"noref= errer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer nor= eferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b= lank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>>>>&= gt; >>>>>>>><br>>>>> >>>>&g= t;>>><br>>>>> >>>>>>>>=C2=A0 = =C2=A0<a rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer nore= ferrer noreferrer noreferrer noreferrer" href=3D"https://www.truthcoin.info= /blog/pow-cheapest/" target=3D"_blank">https://www.truthcoin.info/blog/pow-= cheapest/</a><br>>>>> >>>>>>>>=C2=A0 = =C2=A0 =C2=A0"Nothing is Cheaper than Proof of Work"<br>>>&= gt;> >>>>>>>>=C2=A0 =C2=A0 =C2=A0on | 04 Aug 201= 5<br>>>>> >>>>>>>><br>>>>> = >>>>>>><br>>>>> >>>>>>&g= t; Just to belabor this a bit, the paper demonstrates that the mining marke= t will tend to expend resources equivalent to miner reward.=C2=A0 It does n= ot prove that mining work has to expend *energy* as a primary cost.<br>>= >>> >>>>>>><br>>>>> >>>&= gt;>>> Some might argue that energy expenditure has negative exter= nalities and that we should move to other resources.=C2=A0 I would argue th= at the negative externalities will go away soon because of the move to rene= wables, so the point is likely moot.<br>>>>> >>>>&g= t;>><br>>>>> >>>>> _______________________= ________________________<br>>>>> >>>>> bitcoin-d= ev mailing list<br>>>>> >>>>> <a rel=3D"noreferr= er noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer norefe= rrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan= k">bitcoin-dev@lists.linuxfoundation.org</a><br>>>>> >>&g= t;>> <a rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer= noreferrer noreferrer noreferrer noreferrer" href=3D"https://lists.linuxfo= undation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.= linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>>>>> &g= t;>><br>>>>> >>> _______________________________= ________________<br>>>>> >>> bitcoin-dev mailing list<= br>>>>> >>> <a rel=3D"noreferrer noreferrer noreferrer= noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D"mailto:bit= coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin= uxfoundation.org</a><br>>>>> >>> <a rel=3D"noreferrer = noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferre= r noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bi= tcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/list= info/bitcoin-dev</a><br>>>>> ><br>>>>> > ____= ___________________________________________<br>>>>> > bitcoi= n-dev mailing list<br>>>>> > <a rel=3D"noreferrer noreferrer= noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D= "mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de= v@lists.linuxfoundation.org</a><br>>>>> > <a rel=3D"noreferr= er noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer norefe= rrer noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/listinfo= /bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/l= istinfo/bitcoin-dev</a><br>><br>> ___________________________________= ____________<br>> bitcoin-dev mailing list<br>> <a rel=3D"noreferrer = noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferre= r" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br>> <a rel=3D"noreferrer nore= ferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer no= referrer" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoi= n-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo= /bitcoin-dev</a></blockquote></div></blockquote><br><br><br>=C2=A0</blockqu= ote></div></blockquote></div></blockquote><br><br><br>=C2=A0 </blockquote></div> --0000000000006c1e8705bd6c4d79--