From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B0C33C0001 for ; 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 ; 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 ; 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 ; Sat, 13 Mar 2021 15:02:17 +0000 (UTC) Received: by mail-yb1-xb35.google.com with SMTP id h82so28491555ybc.13 for ; 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: <1802-604c7400-4d1-7b635e80@91248813> In-Reply-To: <1802-604c7400-4d1-7b635e80@91248813> From: Lonero Foundation Date: Sat, 13 Mar 2021 10:02:05 -0500 Message-ID: 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 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: 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 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 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 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/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 >>>> >>>> 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 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 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
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=A0asymmetric 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.

Best regards, Andrew
=
On Sat= , Mar 13, 2021, 3:13 AM email@yancy.lol <email@yancy.lol> wrote:
<= /div>

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.

=C2=A0

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?


Cheers,
-Yancy


On Saturday, March 13, 2021 00:31 CE= T, Lonero Foundation <loneroassociation@gmail.com> wrote:
=C2= =A0
Also, I already = stated I was referring to signature validation cryptography in that aspect:= https://wizardforcel.gitbooks.io/practical-crypto= graphy-for-developers-book/content/digital-signatures/ecdsa-sign-verify-exa= mples.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 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.
=C2=A0
Best r= egards, Andrew
=C2=A0
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 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.
=C2=A0
Best regards, Andrew
= =C2=A0
On F= ri, Mar 12, 2021 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote:<= /div>
I think Andrew himse= lf is an algo.=C2=A0 The crypto training set must not be very good.

= Cheers,
-Yancy

On Friday, March 12, 2021 17:54 CET, Lonero Founda= tion via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=C2=A0
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
=C2=A0
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.
=C2=A0
This will take about 400 hours of my ti= me, but is something I am personally looking into developing as a hard fork= .
=C2=A0
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.
=C2=A0
Best regards, Andrew
=C2=A0
=
On Fri, Mar 12, 2021, 10:03 AM Erik A= ronesty <eri= k@q32.com> wrote:
secp236k1 isn't a hashing algo.=C2=A0 =C2=A0your BIP needs about 1= 0 more pages
and some degree of technical merit.

i suggest you st= art here:

https://en.bitcoin.it/wiki/Pro= of_of_burn
https://bitcointalk= .org/index.php?topic=3D225690.0

proof-of-burn is a nice alternat= ive to proof-of-work.=C2=A0 =C2=A0i always
suspected that, if designed c= orrectly, 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 w= ould probably work just fine.

- erik

On Thu, Mar 11, 2021 at = 11:56 AM Lonero Foundation via bitcoin-dev
<bitc= oin-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 B= IP # for the draft prior to development/reference implementation.
>> Best regards, Andrew
>
> On Mon, Mar 8, 2021, 6:40 PM Lo= nero Foundation <loneroassociation@gmail.com> wrote:>>
>> Hi, here is the list to the BIP proposal on my own r= epo: https= ://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki
>> 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.
>>
>> 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 Rica= rdo Filipe <ricardojdfilipe@gmail.com> wrote:
>>= ;>>
>>>> As said before, you are free to create the BI= P 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 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.
>>>&g= t; >
>>>> > 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.
>>>> >
>>>> > 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.
>>>> >
>>>> > Does t= hat seem fine?
>>>> >
>>>> > Best regar= ds, Andrew
>>>> >
>>>> > On Fri, Mar 5,= 2021, 7:41 PM Keagan McClelland <keagan.mcclelland@gmail.com= > wrote:
>>>> >>
>>>> >> &= 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.
>>>> >= ;>
>>>> >> My instincts tell me that this is an out= landish claim. Do you have supporting evidence for this?
>>>>= ; >>
>>>> >> Keagan
>>>> >>=
>>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundat= ion via bitcoin-dev <bitcoin-dev@lists.linuxfoundat= ion.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 mo= re commonly used then PoST.
>>>> >>> There is a way= to make PoC cryptographically compatible w/ Proof of Work as it normally s= tands: https://en.wikipedia.org/wiki/Proof_= of_space
>>>> >>> 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.
>>>> >>>
>>>> >>> 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."
>>>> >>>
>>>> >>= > 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.
>>>> &g= t;>>
>>>> >>> 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 :)
>>>> >>>
>>>> >&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.
&= gt;>>> >>> https://hackernoon.com/et= hereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-= pi3s3yjl
>>>> >>>
>>>> >>&= gt; 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 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.
>>>> >>>>
>>>> >&= 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.
>>>> >>>>>>>> >>>> All of these things make the Bitcoin ne= twork worse off.
>>>> >>>>
>>>> &= gt;>>> Keagan
>>>> >>>>
>>>= > >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<= /a>> wrote:
>>>> >>>>>
>>>>= >>>>> 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?
>>>> >>>&g= t;>
>>>> >>>>> Best regards, Andrew
>= ;>>> >>>>>
>>>> >>>>>= On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <loneroassoc= iation@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 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?
>>>> >>>>>>
>>>>= ; >>>>>> Best regards, Andrew
>>>> >>= ;>>>>
>>>> >>>>>> On Fri, Mar = 5, 2021, 10:07 AM Devrandom <c1.devrandom@niftybox.net> = wrote:
>>>> >>>>>>>
>>>>= >>>>>>> Hi Ryan and Andrew,
>>>> >&= gt;>>>>>
>>>> >>>>>>> On= Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>&= gt; >>>>>>>>
>>>> >>>>&g= t;>>>
>>>> >>>>>>>>=C2=A0 = =C2=A0https://www.truthcoin.info/blog/pow-= cheapest/
>>>> >>>>>>>>=C2=A0 = =C2=A0 =C2=A0"Nothing is Cheaper than Proof of Work"
>>&= gt;> >>>>>>>>=C2=A0 =C2=A0 =C2=A0on | 04 Aug 201= 5
>>>> >>>>>>>>
>>>> = >>>>>>>
>>>> >>>>>>&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.
>= >>> >>>>>>>
>>>> >>>&= 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.
>>>> >>>>&g= t;>>
>>>> >>>>> _______________________= ________________________
>>>> >>>>> bitcoin-d= ev mailing list
>>>> >>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> >>&g= t;>> https://lists.= linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> &g= t;>>
>>>> >>> _______________________________= ________________
>>>> >>> bitcoin-dev mailing list<= br>>>>> >>> bitcoin-dev@lists.lin= uxfoundation.org
>>>> >>> https://lists.linuxfoundation.org/mailman/list= info/bitcoin-dev
>>>> >
>>>> > ____= ___________________________________________
>>>> > bitcoi= n-dev mailing list
>>>> > bitcoin-de= v@lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/l= istinfo/bitcoin-dev
>
> ___________________________________= ____________
> bitcoin-dev mailing list
> = bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo= /bitcoin-dev



=C2=A0



=C2=A0
--0000000000006c1e8705bd6c4d79--