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 21A75C0001 for ; Sat, 6 Mar 2021 15:21:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 03AFA43001 for ; Sat, 6 Mar 2021 15:21:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 L8pQkywXFwWA for ; Sat, 6 Mar 2021 15:21:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by smtp2.osuosl.org (Postfix) with ESMTPS id 781A642FB0 for ; Sat, 6 Mar 2021 15:21:25 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id bd6so7319094edb.10 for ; Sat, 06 Mar 2021 07:21:25 -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 :content-transfer-encoding; bh=43oA/MMNav6YMY6kApkYlI2AlIDAbEXHGxNtXAr1dv0=; b=k7v8F7BY3r/8jhoABBh50FyI0GBZ54J1kVCvTX9IvhWUnJlZ6TMVmMNlw3WSTa897+ fDZO9U9RwSe70dbR7njrt3PKOjNchK12/qMy0pegQpdNG4q/fCFpZcZYnSJYt+wNfZRH X64UMFTP5rxs7cczLyqQ17Y6gzsT0cqgmZl7vU14R2y6eIiP+aAMR4/AYG12HMV8Uw6p hz7gXCRwCclOX4zSeHodzyGbWOqkPZUmobWLL/O4uH4KrnmmhIjUqlk/GQxuN87G+Vrt RN16c5SNgHyhOSI5ys9/Qypy+Gs995gVxId7dIgTlxDBdVwx2LzlDyRCvUS+7i7gMxHM 0IGA== 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:content-transfer-encoding; bh=43oA/MMNav6YMY6kApkYlI2AlIDAbEXHGxNtXAr1dv0=; b=a5bkIS+QtrE1JALpXTCFcgbd/STYU5WQDWXQkaiYZThxrMfVIE86zfsmlFmIJP1Zqg /rBxJalBepGlghbSR37KWMucHr3++wbirCWEMPPWVoqLhjeJKdMnNL/hO0jPFkYQhbaE SrFT7iWRAy0nczVLMn3zE3rC+yS4/a2w1UBIhr8TKgCTfQ3iISMraOEtMiU1RU4Ddzay IjyzNBtLkPtPyGJwF5Fn0Crvzqv/jJI57ICiftwQgY9cL+Tpx8iguG43VxEFGWYcm3k9 vRK8LlYg3S/MuOTepsPBUpRmzzc4P+5ZNbHIjdAkknPW0cs44V5bUPiLX+pm1LToC1R9 ckQg== X-Gm-Message-State: AOAM533hLuMt+A4RpyqPaXiAIl45hlVZtwzYbV/o2tKygji+mFjO+lCl B7r3Uw65/O/93/OCVS6X3gSBwcIIRyPyhhDuu9c= X-Google-Smtp-Source: ABdhPJyGhRYjIfq8JoOSiX8Xnrgxv1BJ93s2zeIWfhziWMZJZ8sbrDujRaUevWhdRL4L5K2vUlv7MfYk+oR37ov+55s= X-Received: by 2002:a50:fe06:: with SMTP id f6mr14283852edt.349.1615044084185; Sat, 06 Mar 2021 07:21:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ricardo Filipe Date: Sat, 6 Mar 2021 15:21:12 +0000 Message-ID: To: Lonero Foundation , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 06 Mar 2021 18:13:21 +0000 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 15:21:28 -0000 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=A1bado, 6/03/2021 =C3=A0(s) 08:58: > > I know Ethereum had an outlandishly large percentage of nodes running on = AWS, I heard the same thing is for Bitcoin but for mining. Had trouble find= ing the article online so take it with a grain of salt. The point though is= that both servers and ASIC specific hardware would still be able to benefi= t 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 r= equest 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 see= n as opposed to offline discussion. Since the instructions say to email bit= coin-dev before doing a bip draft, I have done that. Since people want to s= ee 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 som= e 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-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 disenfranch= ise currently optimized mining entities as well. >> >> My instincts tell me that this is an outlandish claim. Do you have suppo= rting 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 is much dif= ferent than staking. Sorry to draw for the confusion as PoC is more commonl= y used then PoST. >>> There is a way to make PoC cryptographically compatible w/ Proof of Wor= k as it normally stands: https://en.wikipedia.org/wiki/Proof_of_space >>> It has rarely been done though given the technological complexity of be= ing both CPU compatible and memory-hard compatible. There are lots of benef= its outside of the realm of efficiency, and I already looked into numerous = fault tolerant designs as well and what others in the cryptography communit= y attempted to propose. The actual argument you have only against this is t= he Proof of Memory fallacy, which is only partially true. Given how the cur= rent hashing algorithm works, hard memory allocation wouldn't be of much be= nefit 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 figu= res 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 cryptograph= y 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 provid= e 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 mino= r 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 ex= penditure 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-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 disenfranchi= se currently optimized mining entities as well. >>> >>> There are other reasons why a cryptography upgrade like this is benefic= ial. Theoretically one can argue BItcoin isn't fully decentralized. It is f= ew unsolved mathematical proofs away from being entirely broken. My goal ou= tside 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 vario= us research in regards to this area and work alot with distributed computin= g. I believe if the BTC community likes such a proposal, I would single han= dedly 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-st= op-telling-us-that-you-arent-pi3s3yjl >>> >>> Best regards, Andrew >>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland 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 us= eful it provides an avenue for actors to have nothing at stake when submitt= ing 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 th= erefore 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 wi= ll invalidate the enormous amount of capital expenditure by mining entities= and disincentivize future capital expenditure into mining hardware that ma= y 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 ent= ity is tying their own interests to that of the bitcoin network at large. I= t also puts the developers in a position where they can be bribed by entiti= es with a vested interest in deciding what the new "useful" proof of work s= hould 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 crypto= graphy proposal helps behind the efficiency category but also tackles probl= ems such as NP-Completeness or Halting which is something the BTC network c= ould be vulnerable to in the future. For sake of simplicity, I do want to d= o 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 b= lock height have been proposed as hard forks, I feel at the very least an u= pgrade regarding the hashing algorithm and cryptography does at least warra= nt some discussion. Anyways I hope I can send you my BIP, just let me know = on the preferred format? >>>>> >>>>> Best regards, Andrew >>>>> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation wrote: >>>>>> >>>>>> Hi, this isn't about the energy efficient argument in regards to ren= ewables or mining devices but a better cryptography layer to get the most o= ut 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 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 n= ot 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 negati= ve externalities will go away soon because of the move to renewables, so th= e point is likely moot. >>>>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev