From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E9A33C0001 for ; Sat, 6 Mar 2021 00:57:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id D05A842FFB for ; Sat, 6 Mar 2021 00:57:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-vmoraNmY_h for ; Sat, 6 Mar 2021 00:57:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by smtp2.osuosl.org (Postfix) with ESMTPS id 2E17D42FAF for ; Sat, 6 Mar 2021 00:57:49 +0000 (UTC) Received: by mail-yb1-xb2d.google.com with SMTP id 133so3843286ybd.5 for ; Fri, 05 Mar 2021 16:57:49 -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=vS5oWdZPtoQAdvNx3GMvxRPlxwaSEPvNqgJtiK+lFUY=; b=Z4NPnZOYa1P/n3pU1ULPtRmx0wuB/OGy5bJzCzoYXlJwzUlDTmJ9VtsgJgnIoCGyyc 2IXWL9qygciWY1x3a/JPKYQy0C21MCBwfN82dcj3+US7mAHdZ6VAuBnOXMf2a3WWDa91 ms+My2l2ZOYe86nlTRl7W6MYpEMpk3mMEbdp87kZbQ/Bvv+7tzQPlUB7r+kP9jbNH1eK 2xjgjV+D1KdqhIwiNTO8Zp8ApTu+J6UnTVZpRHYNM2JnBvxayl4vs+QOB267OikBDuMq Z42pcRloZYDX2d0ZQvxVhg86C7e49RiXkMWpDy7q9QJoQpmk/ZJGsY6uF3QYKCm1tuzu dsrA== 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=vS5oWdZPtoQAdvNx3GMvxRPlxwaSEPvNqgJtiK+lFUY=; b=IaxpzkzBfYifBI+cGCkGp4Ybsg4K9166Hih073mh3cJBRW2zpbf7XmIf5284NXnFZ9 bgoVjUgq9sAvx3M+lXUHUG2Dyoa7Gv4jxoPz+r/urvNBr6/sdI60utNxIXoMOmv4RN/S fXW75Yp4+fgwTyKIw32QcC49UCxiTth3pMlQhJmKAdxNLd8HBtLn9sFdslglhYZWViyB uLGLbsdRZem6oM6FdEBUhtahjl367iOO4KK7FLQQerWC+yMpAKt/1ENt3SS8kHFMzPJG oJ59OUai7g70jsHzNMwZkLh2edACaDlZfGP3FMZvR49EhjkewM5E+vCYhoppmH1V90DA 82nw== X-Gm-Message-State: AOAM533P35XOn8TxulGbp03ommZ5fXOlqhUj4VWUPhIXy+0ScLo0D6LQ dAXk7CniQWpNaX2C0+5lKGQWKgp65CQQQROlnmw= X-Google-Smtp-Source: ABdhPJyTBk0hcWHPjTDXOc3KXpJfoIsDusHtvHixSMlCPeWJ6alRSG/0EJXMRN1g5Zj+B68xmLQMyDPLQVcYm4iKXDQ= X-Received: by 2002:a25:d704:: with SMTP id o4mr16459492ybg.6.1614992267975; Fri, 05 Mar 2021 16:57:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Lonero Foundation Date: Fri, 5 Mar 2021 19:57:36 -0500 Message-ID: To: Keagan McClelland Content-Type: multipart/alternative; boundary="00000000000072a3b005bcd3b0bd" X-Mailman-Approved-At: Sat, 06 Mar 2021 08:58:05 +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, 06 Mar 2021 00:57:51 -0000 --00000000000072a3b005bcd3b0bd Content-Type: text/plain; charset="UTF-8" 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. 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. That said, I think the best way to move forward is to submit a BIP pull request for a draft via GitHub using BIP #2's draft format and any questions people have can be answered in the reqeust's comments. That 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 instructions say to email bitcoin-dev before doing a bip draft, I have done that. Since people want to see the draft beforehand and it isn't merged manually anyways, I think it is the easiest way to handle this. I'm also okay w/ continuing the discussion on bitcoin-dev but rather form a discussion on git instead given I don't want to accidentally impolitely bother people given this is a moderated list and we already established some interest for at least a draft. Does that seem fine? 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 and non-asic > specific hardware anyways. A majority of them would benefit from a hybrid > proof, and the fact that it is hybrid in that manner wouldn't > disenfranchise currently optimized mining entities as well. > > My instincts tell me that this is an outlandish claim. Do you have > supporting evidence for this? > > Keagan > > On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Actually I mentioned a proof of space and time hybrid which is much >> different than staking. Sorry to draw for the confusion as PoC is 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. There 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 have only against >> this is the 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 >> 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 Bitcoin's >> cryptography now comes down to minutes. Bitcoin is going to have to >> eventually radically upgrade their cryptography and hashing algo in the >> future regardless. I want to integrate some form of NP complexity in >> regards to the hybrid cryptography I'm 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 >> expenditure by mining entities and disincentivize future capital >> expenditure into mining hardware that may compute these more "useful" >> proofs of work." >> >> A large portion of BTC is already mined through AWS servers and non-asic >> specific hardware anyways. A majority of them would benefit from a hybrid >> proof, and the fact that it is hybrid in that manner wouldn't >> disenfranchise currently optimized mining entities as well. >> >> There are other reasons why a cryptography upgrade like this is >> beneficial. Theoretically one can argue BItcoin isn't fully decentralized. >> It is few unsolved mathematical proofs away from being entirely broken. My >> goal 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 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-stop-telling-us-that-you-arent-pi3s3yjl >> >> Best regards, Andrew >> >> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland < >> keagan.mcclelland@gmail.com> wrote: >> >>> It is important to understand that it is critical for the work to be >>> "useless" in order for the security model to be the same. If the work was >>> useful it provides an avenue for actors 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 been done anyway. This actually 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 by mining 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 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 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 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 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 < >>>> loneroassociation@gmail.com> wrote: >>>> >>>>> Hi, this isn't about the energy efficient argument in regards to >>>>> renewables or mining devices but a better cryptography layer to get the >>>>> most out of your hashing for validation. I do understand the arbitrariness >>>>> of it, but do want to still propose a document. Do I use the Media Wiki >>>>> format on GitHub and just attach it as my proposal? >>>>> >>>>> Best regards, Andrew >>>>> >>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom >>>>> wrote: >>>>> >>>>>> Hi Ryan and Andrew, >>>>>> >>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev < >>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>>>> >>>>>>> >>>>>>> https://www.truthcoin.info/blog/pow-cheapest/ >>>>>>> "Nothing is Cheaper than Proof of Work" >>>>>>> on | 04 Aug 2015 >>>>>>> >>>>>>> >>>>>> Just to belabor this a bit, the paper demonstrates that the mining >>>>>> market will tend to expend resources equivalent to miner reward. It does >>>>>> not prove that mining work has to expend *energy* as a primary cost. >>>>>> >>>>>> Some might argue that energy expenditure has negative externalities >>>>>> and that we should move to other resources. I would argue that the >>>>>> negative externalities will go away soon because of the move to renewables, >>>>>> so the point is likely moot. >>>>>> >>>>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --00000000000072a3b005bcd3b0bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I know Ethereum had an outlandishly large percentage of n= odes 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 b= e able to benefit from the cryptography upgrade I am proposing, as this was= in relation to the disinfranchisemet point.=C2=A0

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 f= ormat and any questions people have can be answered in the reqeust's co= mments. That way people don't have to get emails everytime there is a r= eply, but replies still get seen as opposed to offline discussion. Since th= e instructions say to email bitcoin-dev before doing a bip draft, I have do= ne that. Since people want to see the draft beforehand and it isn't mer= ged manually anyways, I think it is the easiest way to handle this.=C2=A0

I'm also okay w/ cont= inuing the discussion on bitcoin-dev but rather form a discussion on git in= stead given I don't want to accidentally impolitely bother people given= this is a moderated list and we already established some interest for at l= east a draft.

Does that = seem fine?

Best regards, A= ndrew

On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland <keagan.mcclelland@gmail.com>= wrote:
> A lar= ge portion of BTC is already mined through AWS servers and non-asic specifi= c hardware anyways. A majority of them would benefit from a hybrid proof, a= nd the fact that it is hybrid in that manner wouldn't disenfranchise cu= rrently optimized mining entities as well.

My instincts = tell me that this is an outlandish claim. Do you have supporting evidence f= or this?

Keagan

On Fri, Mar 5, 2021 at 3:22 P= M Lonero Foundation via bitcoin-dev <bitcoin-dev@list= s.linuxfoundation.org> wrote:
Actually I mentioned a proof of = space and time hybrid which is much different than staking. Sorry to draw for the confusion as PoC is more=20 commonly used then PoST.
There is a way to make PoC cryptographic= ally 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. There are lots of=20 benefits outside of the realm of efficiency, and I already looked into=20 numerous fault tolerant designs as well and what others in the=20 cryptography community attempted to propose. The actual argument you=20 have only against this is the Proof of Memory fallacy, which is only=20 partially true. Given how the current hashing algorithm works, hard=20 memory allocation wouldn't be of much benefit given it is more optimize= d for CPU/ASIC specific mining. I'm working towards a hybrid mechanism= =20 that fixes that. BTW: The way Bitcoin currently stands in its=20 cryptography still needs updating regardless. If someone figures out NP=20 hardness or the halting problem the traditional rule of millions of=20 years to break all of Bitcoin's cryptography now comes down to minutes.= =20 Bitcoin is going to have to eventually radically upgrade their=20 cryptography and hashing algo in the future regardless. I want to=20 integrate some form of NP complexity in regards to the hybrid=20 cryptography I'm aiming to provide which includes a polynomial time=20 algorithm in the cryptography. More than likely the first version of my=20 BTC hard fork will be coded in a way where integrating such complexity=20 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=20 entities and disincentivize future capital expenditure into mining=20 hardware that may compute these more "useful" proofs of work.&quo= t;

A large portion of BTC is already mined through AWS servers and non-asic=20 specific hardware anyways. A majority of them would benefit from a=20 hybrid proof, and the fact that it is hybrid in that manner wouldn't=20 disenfranchise currently optimized mining entities as well.
<= br>
There are other reasons why a cryptography upgrade like this is=20 beneficial. Theoretically one can argue BItcoin isn't fully=20 decentralized. It is few unsolved mathematical proofs away from being=20 entirely broken. My goal outside of efficiency is to build cryptography=20 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 alot with distributed computing. I believe if the BTC community=20 likes such a proposal, I would single handedly be able to build the=20 cryptographic proof myself (though would like as many open source=20 contributors as I can get :)

Anyways just=20 something to consider. We are in the same space in regards to what=20 warrants a shitcoin or the whole argument against staking.

Best regar= ds,=C2=A0 Andrew

On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <= keagan.mcclelland@gmail.com> wrote:
It is important to und= erstand that it is critical for the work to be "useless" in order= for the security model to be the same. If the work was useful it provides = an avenue for actors to have nothing at stake when submitting a proof of wo= rk, since the marginal cost of block construction will be lessened by the f= act that the work was useful=C2=A0in a different context and therefore woul= d have been done anyway. This actually degrades the security of the network= in the process.

As a separate issue, proposing a hard f= ork in the hashing algorithm will invalidate the enormous amount of capital= expenditure by mining entities and disincentivize future capital expenditu= re into mining hardware that may compute these more "useful" proo= fs of work. This is because any change in the POW algorithm will be conside= red unstable and subject to change in the future. This puts the entire netw= ork 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 po= sition 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 Foundat= ion via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
Also in regards to my other email, I forgot to itera= te that my cryptography proposal helps behind the efficiency category but a= lso tackles problems such as NP-Completeness or Halting which is something = the BTC network could be vulnerable to in the future. For sake of simplicit= y, I do want to do this BIP because it tackles lots of the issues in 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 th= e very least an upgrade regarding the hashing algorithm and cryptography do= es 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 <loneroassociation@gmail.com> wrote:
Hi, th= is isn't about the energy efficient argument in regards to renewables o= r mining devices but a better cryptography layer to get the most out of you= r hashing for validation. I do understand the arbitrariness of it, but do w= ant to still propose a document. Do I use the Media Wiki format on GitHub a= nd just attach it as my proposal?

Best regards, Andrew

On Fri, Mar 5, 2021, 10:07 AM Devrandom <<= a href=3D"mailto:c1.devrandom@niftybox.net" rel=3D"noreferrer noreferrer" t= arget=3D"_blank">c1.devrandom@niftybox.net> wrote:
Hi Ryan and Andrew,

On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via= bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:

=C2=A0 http= s://www.truthcoin.info/blog/pow-cheapest/
=C2=A0 =C2=A0 "Nothing is Cheaper than Proof of Work"
=C2=A0 =C2=A0 on | 04 Aug 2015


Just to belabor this a bit, the paper = demonstrates that the mining market will tend to expend resources equivalen= t to miner reward.=C2=A0 It does not prove that mining work has to expend *= energy* as a primary cost.

Some might argue th= at energy expenditure has negative externalities and that we should move to= other resources.=C2=A0 I would argue that the negative externalities will = go away soon because of the move to renewables, so the point is likely moo= t.=C2=A0

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--00000000000072a3b005bcd3b0bd--