From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6116DC0001 for ; Fri, 5 Mar 2021 22:50:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5521760664 for ; Fri, 5 Mar 2021 22:50:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW8S_IuTmcUP for ; Fri, 5 Mar 2021 22:50:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by smtp3.osuosl.org (Postfix) with ESMTPS id 5A07E6064A for ; Fri, 5 Mar 2021 22:50:00 +0000 (UTC) Received: by mail-pl1-x629.google.com with SMTP id z5so2170541plg.3 for ; Fri, 05 Mar 2021 14:50:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=M17I8bPFZcsNgSnzchxmk3iApRpKPejjuIRcVpa0tU4=; b=fQHlBE5pQBRdh87sso+IFYMAg0DC7axUmTzVtRJ0N5vVdD6N2H7CCdwdUdXZXXIiAN EUcdf/N5XsqyE7bqPV8kkjev2fXkjyaB2BfWOOHKbvFwgysvnA3odojifqEAWKadAZ9t ajutce5yvDRpX/iumeD0tIBiR//6QQhmpN8b4/bOAj66ekz8eYGgatjBQPCF24ZMoZrB i/YacJn+gu/X4l3sPX/+qagJScXylPowXRJ7ZgS7Oeaj06teUT7uPhZx6yUNUWg3cstf vVLdInkTgdFIRd/xBkpIdY6+Ry2v0i6ds42gfOnU8j/WhXgYBo9jRpe8UXAdrhdEuexo RtKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=M17I8bPFZcsNgSnzchxmk3iApRpKPejjuIRcVpa0tU4=; b=omYX9tW+vBfZ65TBU8Ds9xS6585V5IrvK6P38q6+UmOsCOC9kXr5BL3eak4f4zgKD3 +C/zgbvKEiVnFCgbj1tVnnJmtz9lcBfURvQTlyrYSrDFIDArwRO1IJva8qangCsH9fZH pmsKNid66zR8bedrQRPJL4Aceu/VGw43bjUu1JBBzCriJSPkP74xTbbthyoVt33Krdp0 h1gSkNdHRPfbnYCsS18xgGK6ubsDia/mzasrqBugXi5Md51Fb7kMD2ZwnZKjFKhNT2TP yRVsE9GyGeaIsYcjaqygn01VE4XMADNeZ6aCU/t/W40OjVMQWBSU5r79vYyLbWxeKFHs ZYUg== X-Gm-Message-State: AOAM532xgAIGDcjktlAGg/4prjJLRGbF3YXc3dzM9M+OESymfqPdjmXw SdJJKyc2/BcvDemcJOHYXhxGDcg9AXmPmw== X-Google-Smtp-Source: ABdhPJzt978PGsdOCQOm+ewiytF9VTUv076p0HH0C3I9rSCX0KBoTopQtu9fwjC988uuygQtWbYKvw== X-Received: by 2002:a17:903:102:b029:e5:fc29:de83 with SMTP id y2-20020a1709030102b02900e5fc29de83mr3264992plc.31.1614984599505; Fri, 05 Mar 2021 14:49:59 -0800 (PST) Received: from ?IPv6:2600:380:707e:3fea:d1ed:f262:c787:7ca4? ([2600:380:707e:3fea:d1ed:f262:c787:7ca4]) by smtp.gmail.com with ESMTPSA id z2sm3529471pfc.8.2021.03.05.14.49.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Mar 2021 14:49:59 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-0F0F32C6-D063-448D-B75C-B599CE508F81 Content-Transfer-Encoding: 7bit From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Fri, 5 Mar 2021 14:49:57 -0800 Message-Id: <974C7CF0-5087-4120-B860-35FAEF39EA95@voskuil.org> References: In-Reply-To: To: Lonero Foundation X-Mailer: iPhone Mail (18D52) Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 22:50:03 -0000 --Apple-Mail-0F0F32C6-D063-448D-B75C-B599CE508F81 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI it=E2=80=99s generally considered bad form repost a private thread, espe= cially one you initiate. ... It=E2=80=99s typically more effective to generate some community support bef= ore actually submitting a BIP. Otherwise the process gets easily overwhelmed= . This is likely why you aren=E2=80=99t getting a response. You can draft th= e BIP in your own repo and collect feedback from interested parties. Posting a link to your research/code is a good start. I=E2=80=99d be happy t= o look at an overview of the central principles. I=E2=80=99m not a cryptogra= pher. I write code, but I look at these things from economic principles. So f= ar all I have to go on is that you go =E2=80=9Cmuch beyond=E2=80=9D Chia. Th= at=E2=80=99s not really anything. e > On Mar 5, 2021, at 14:03, Lonero Foundation w= rote: >=20 > =EF=BB=BF > Hi, Eric. Chia's network is a bad example. They go after energy consumptio= n in the wrong way entirely. True, it requires a comparable cost of hardware= . I am trying to tackle cryptography in a way that goes much beyond that. Pa= rt of what I am doing includes lowering invalided proofs while trying to get= the best of both worlds in regards to PoW and PoC. It is an efficiency issu= e to the core. In regards to the mechanisms of how I will do that, I suggest= you look at the entire proposal which is why I am hoping the BIP team would= be so gracious as to allow me to draft it out on GitHub. >=20 > Best regards, Andrew >=20 >> On Fri, Mar 5, 2021, 4:42 PM Eric Voskuil wrote: >> How is the argument against PoM only partially true? >>=20 >> I wrote this as soon as I saw Chia. Had two debates on Twitter with Brahm= , before he blocked me. Two years later, after they finally realized I was c= orrect, one of their PhDs contacted me and told me. Better to flesh this out= early. They had already raised $20 and done their research, so he wasn=E2=80= =99t exactly in a listening mode. >>=20 >> e >>=20 >>>> On Mar 5, 2021, at 13:20, Lonero Foundation wrote: >>>>=20 >>> =EF=BB=BF >>> Actually I mentioned a proof of space and time hybrid which is much diff= erent than staking. Sorry to draw for the confusion as PoC is more commonly u= sed 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 bei= ng both CPU compatible and memory-hard compatible. There are lots of benefit= s outside of the realm of efficiency, and I already looked into numerous fau= lt tolerant designs as well and what others in the cryptography community at= tempted to propose. The actual argument you have only against this is the Pr= oof of Memory fallacy, which is only partially true. Given how the current h= ashing algorithm works, hard memory allocation wouldn't be of much benefit g= iven 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 i= ts cryptography still needs updating regardless. If someone figures out NP h= ardness or the halting problem the traditional rule of millions of years to b= reak all of Bitcoin's cryptography now comes down to minutes. Bitcoin is goi= ng to have to eventually radically upgrade their cryptography and hashing al= go in the future regardless. I want to integrate some form of NP complexity i= n regards to the hybrid cryptography I'm aiming to provide which includes a p= olynomial time algorithm in the cryptography. More than likely the first ver= sion of my BTC hard fork will be coded in a way where integrating such compl= exity in the future only requires a soft fork or minor upgrade to its chain.= >>>=20 >>> In regards to the argument, "As a separate issue, proposing a hard fork i= n the hashing algorithm will invalidate the enormous amount of capital expen= diture by mining entities and disincentivize future capital expenditure into= mining hardware that may compute these more "useful" proofs of work." >>>=20 >>> 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 p= roof, and the fact that it is hybrid in that manner wouldn't disenfranchise c= urrently optimized mining entities as well. >>>=20 >>> There are other reasons why a cryptography upgrade like this is benefici= al. Theoretically one can argue BItcoin isn't fully decentralized. It is few= unsolved mathematical proofs away from being entirely broken. My goal outsi= de of efficiency is to build cryptography in a way that prevents such an eve= nt from happening in the future, if it was to ever happen. I have various re= search in regards to this area and work alot with distributed computing. I b= elieve if the BTC community likes such a proposal, I would single handedly b= e able to build the cryptographic proof myself (though would like as many op= en source contributors as I can get :) >>>=20 >>> Anyways just something to consider. We are in the same space in regards t= o what warrants a shitcoin or the whole argument against staking. >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-sto= p-telling-us-that-you-arent-pi3s3yjl >>>=20 >>> Best regards, Andrew >>>=20 >>>> On Fri, Mar 5, 2021 at 3:53 PM Eric Voskuil wrote: >>>> =EF=BB=BFHi Andrew, >>>>=20 >>>> Do you mean that you can reduce the cost of executing the cryptography a= t a comparable level of security? If so this will only have the effect of in= creasing the amount of it that is required to consume the same cost. >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox= >>>>=20 >>>> You mentioned a staking hybrid in your original post. >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fall= acy >>>>=20 >>>> This would be a change to dynamics - the economic forces at work. Staki= ng is not censorship resistant >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fal= lacy >>>>=20 >>>> and is therefore what I refer to as cryptodynamically insecure. >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Prin= ciples >>>>=20 >>>> As such it wouldn=E2=80=99t likely be considered as a contribution to B= itcoin. It might of course be useful in some other context. >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definitio= n >>>>=20 >>>> But BIPs are proposals aimed at Bitcoin improvement. >>>>=20 >>>> https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_= a_BIP >>>>=20 >>>> Non-staking attempts to improve energy efficiency are either proof of w= ork in disguise, such as proof of memory: >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fa= llacy >>>>=20 >>>> or attempts to repurpose =E2=80=9Cwasteful=E2=80=9D computing, such as b= y finding prime numbers, which does not imply a reduction in dedicated energ= y consumption. >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Pri= nciple >>>>=20 >>>> Finally, waste and renewable energy approaches at =E2=80=9Ccarbon=E2=80= =9D (vs energy) reduction must still consume the same in cost as the reward.= In other words, the apparent benefit represents a temporary market shift, w= ith advantage to first movers. The market will still consume what it consume= s. If the hashing energy was free all reward consumption would shift to oper= ations. >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fa= llacy >>>>=20 >>>> The motivation behind these attempts is naively understandable, but bas= ed on a false premise. >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Falla= cy >>>>=20 >>>> The one thing that reduces Bitcoin energy consumption is an increase in= energy cost relative to block reward. >>>>=20 >>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Exhaustion-= Fallacy >>>>=20 >>>> e >>>>=20 >>>>>> On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev wrote: >>>>>>=20 >>>>> =EF=BB=BF >>>>> Hi, this isn't about the energy efficient argument in regards to renew= ables or mining devices but a better cryptography layer to get the most out o= f your hashing for validation. I do understand the arbitrariness of it, but d= o want to still propose a document. Do I use the Media Wiki format on GitHub= and just attach it as my proposal? >>>>>=20 >>>>> Best regards, Andrew >>>>>=20 >>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom w= rote: >>>>>> Hi Ryan and Andrew, >>>>>>=20 >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev wrote: >>>>>>>=20 >>>>>>> https://www.truthcoin.info/blog/pow-cheapest/ >>>>>>> "Nothing is Cheaper than Proof of Work" >>>>>>> on | 04 Aug 2015 >>>>>>>=20 >>>>>>=20 >>>>>> Just to belabor this a bit, the paper demonstrates that the mining ma= rket will tend to expend resources equivalent to miner reward. It does not p= rove that mining work has to expend *energy* as a primary cost. >>>>>>=20 >>>>>> Some might argue that energy expenditure has negative externalities a= nd that we should move to other resources. I would argue that the negative e= xternalities will go away soon because of the move to renewables, so the poi= nt is likely moot.=20 >>>>>>=20 >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-0F0F32C6-D063-448D-B75C-B599CE508F81 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
FYI it=E2=80=99s generally c= onsidered bad form repost a private thread, especially one you initiate.

...

It=E2=80=99s typically more effective to generate= some community support before actually submitting a BIP. Otherwise the proc= ess gets easily overwhelmed. This is likely why you aren=E2=80=99t getting a= response. You can draft the BIP in your own repo and collect feedback from i= nterested parties.

Posting a link to your research/code is a go= od start. I=E2=80=99d be happy to look at an overview of the central princip= les. I=E2=80=99m not a cryptographer. I write code, but I look at these thin= gs from economic principles. So far all I have to go on is that you go =E2=80= =9Cmuch beyond=E2=80=9D Chia. That=E2=80=99s not really anything.


On Mar 5, 2021= , at 14:03, Lonero Foundation <loneroassociation@gmail.com> wrote:
=
=EF=BB=BF<= div dir=3D"auto">Hi, Eric. Chia's network is a bad example. They go after en= ergy consumption in the wrong way entirely. True, it requires a comparable c= ost of hardware. I am trying to tackle cryptography in a way that goes much b= eyond that. Part of what I am doing includes lowering invalided proofs while= trying to get the best of both worlds in regards to PoW and PoC. It is an e= fficiency issue to the core. In regards to the mechanisms of how I will do t= hat, I suggest you look at the entire proposal which is why I am hoping the B= IP team would be so gracious as to allow me to draft it out on GitHub.

Best regards, Andrew

=
On Fri, Mar= 5, 2021, 4:42 PM Eric Voskuil <eric@= voskuil.org> wrote:
How is the argument against PoM only partially true?<= /div>

I wrote this as soon as I s= aw Chia. Had two debates on Twitter with Brahm, before he blocked me. Two ye= ars later, after they finally realized I was correct, one of their PhDs cont= acted me and told me. Better to flesh this out early. They had already raise= d $20 and done their research, so he wasn=E2=80=99t exactly in a listening m= ode.

e

On Mar 5, 2021, at 13:20, Lonero Foundation &= lt;loneroassociation@gmail.com> wrote:

=EF=BB=BF
Actually I mentioned a proof of space and time hybrid which is much differ= ent than staking. Sorry to draw for the confusion as PoC is more commonly us= ed then PoST.
There is a way to make PoC cryptographically compati= ble w/ Proof of Work as it normally stands: https://en.wik= ipedia.org/wiki/Proof_of_space
It has rarely been done though g= iven the technological complexity of being both CPU compatible and memory-ha= rd 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 argum= ent 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 a= llocation wouldn't be of much benefit given it is more optimized for CPU/ASI= C specific mining. I'm working towards a hybrid mechanism that fixes that. B= TW: The way Bitcoin currently stands in its cryptography still needs updatin= g regardless. If someone figures out NP hardness or the halting problem the t= raditional rule of millions of years to break all of Bitcoin's cryptography n= ow comes down to minutes. Bitcoin is going to have to eventually radically u= pgrade their cryptography and hashing algo in the future regardless. I want t= o 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 cry= ptography. More than likely the first version of my BTC hard fork will be co= ded in a way where integrating such complexity in the future only requires a= soft fork or minor upgrade to its chain.

In regard= s to the argument, "As a separate issue, proposing a hard fork in the hashin= g 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."
A large portion of BTC is already mined through AWS servers and n= on-asic specific hardware anyways. A majority of them would benefit from a h= ybrid proof, and the fact that it is hybrid in that manner wouldn't disenfra= nchise currently optimized mining entities as well.

There are other reasons why a cryptography upgrade like thi= s is beneficial. Theoretically one can argue BItcoin isn't fully decentraliz= ed. It is few unsolved mathematical proofs away from being entirely broken. M= y 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 hav= e various research in regards to this area and work alot with distributed co= mputing. I believe if the BTC community likes such a proposal, I would singl= e handedly be able to build the cryptographic proof myself (though would lik= e as many open source contributors as I can get :)

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

Best regards= ,  Andrew

On Fri, Mar 5, 2021 at 3:53 PM Eric Voskuil <eric@vos= kuil.org> wrote:
=EF=BB=BFHi Andrew,

Do you mean that you can reduce= the cost of executing the cryptography at a comparable level of security? I= f so this will only have the effect of increasing the amount of it that is r= equired to consume the same cost.

You mentioned a staking hybrid in your original post= .


<= span style=3D"color:rgb(0,0,0)">This would be a change to dynamics - the eco= nomic forces at work. Staking is not censorship resistant


and is there= fore what I refer to as cryptodynamically insecure.

As such it wouldn=E2=80=99t likely be considered as a contribution to Bitc= oin. It might of course be useful in some other context.


But BIPs are proposals aim= ed at Bitcoin improvement.


Non-staking attempts to improve energy efficienc= y are either proof of work in disguise, such as proof of memory:


or attempt= s to repurpose =E2=80=9Cwasteful=E2=80=9D computing, such as by finding prim= e numbers, which does not imply a redu= ction in dedicated energy consumption.

https:= //github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle<= /div>

Finally, waste and renewabl= e energy approaches at =E2=80=9Ccarbon=E2=80=9D (vs energy) reduction must s= till consume the same in cost as the reward. In other words, the apparent be= nefit represents a temporary market shift, with advantage to first movers. T= he market will still consume what it consumes. If the hashing energy was fre= e all reward consumption would shift to operations.

The motivation behind= these attempts is naively understandable, but based on a false premise.


The one t= hing that reduces Bitcoin energy consumption is an increase in energy cost r= elative to block reward.

https://github.com/libbitc= oin/libbitcoin-system/wiki/Energy-Exhaustion-Fallacy

e

On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

=EF=BB=BF
Hi, this isn't about the energy efficient argument in regards to r= enewables 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, b= ut do want to still propose a document. Do I use the Media Wiki format on Gi= tHub 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 <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer no= referrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org= > wrote:
  https://www.truth= coin.info/blog/pow-cheapest/
    "Nothing is Cheaper than Proof of Work"
    on | 04 Aug 2015


Just to belabor this a bit, the paper d= emonstrates that the mining market will tend to expend resources equivalent t= o miner reward.  It does not prove that mining work has to expend *ener= gy* as a primary cost.

Some might argue that en= ergy 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. =

_______________________________________________
bitcoi= n-dev mailing list
bitcoin-dev@lists.linux= foundation.org
https= ://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-0F0F32C6-D063-448D-B75C-B599CE508F81--