path: root/83/39ad77118859303056188c4179abef59eb9319

Return-Path: <eric@voskuil.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6116DC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 22:50:00 +0000 (UTC)
Received: by mail-pl1-x629.google.com with SMTP id z5so2170541plg.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <eric@voskuil.org>
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: <CA+YkXXxzURKiD5r9ATG8CefRzyh9CKzF4Cwzd3-Mr5v5XrzinA@mail.gmail.com>
In-Reply-To: <CA+YkXXxzURKiD5r9ATG8CefRzyh9CKzF4Cwzd3-Mr5v5XrzinA@mail.gmail.com>
To: Lonero Foundation <loneroassociation@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: 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 <loneroassociation@gmail.com> 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 <eric@voskuil.org> 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 <loneroassociation@gmail.co=
m> 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 <eric@voskuil.org> 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 <bitcoin-=
dev@lists.linuxfoundation.org> 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 <c1.devrandom@niftybox.net> w=
rote:
>>>>>> Hi Ryan and Andrew,
>>>>>>=20
>>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><div dir=3D"ltr" style=3D"=
caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">FYI it=E2=80=99s generally c=
onsidered bad form repost a private thread, especially one you initiate.</di=
v><div dir=3D"ltr" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"=
><br></div><div dir=3D"ltr" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0=
, 0, 0);">...</div><div dir=3D"ltr" style=3D"caret-color: rgb(0, 0, 0); colo=
r: rgb(0, 0, 0);"><br></div><div dir=3D"ltr" style=3D"caret-color: rgb(0, 0,=
 0); color: rgb(0, 0, 0);">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.</div><div dir=3D"ltr" style=3D"caret-color: rgb(0, 0, 0);=
 color: rgb(0, 0, 0);"><br></div><div dir=3D"ltr" style=3D"caret-color: rgb(=
0, 0, 0); color: rgb(0, 0, 0);">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.</div><div d=
ir=3D"ltr" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></d=
iv><div dir=3D"ltr" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);=
">e</div></div><div dir=3D"ltr"><br><blockquote type=3D"cite">On Mar 5, 2021=
, at 14:03, Lonero Foundation &lt;loneroassociation@gmail.com&gt; wrote:<br>=
<br></blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=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.<div d=
ir=3D"auto"><br></div><div dir=3D"auto">Best regards, Andrew</div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar=
 5, 2021, 4:42 PM Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.org">eric@=
voskuil.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
auto"><div dir=3D"ltr">How is the argument against PoM only partially true?<=
/div><div dir=3D"ltr"><br></div><div dir=3D"ltr">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.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div dir=3D"ltr=
"><br><blockquote type=3D"cite">On Mar 5, 2021, at 13:20, Lonero Foundation &=
lt;<a href=3D"mailto:loneroassociation@gmail.com" target=3D"_blank" rel=3D"n=
oreferrer">loneroassociation@gmail.com</a>&gt; wrote:<br><br></blockquote></=
div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr"><di=
v>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.</div><div>There is a way to make PoC cryptographically compati=
ble w/ Proof of Work as it normally stands: <a href=3D"https://en.wikipedia.=
org/wiki/Proof_of_space" target=3D"_blank" rel=3D"noreferrer">https://en.wik=
ipedia.org/wiki/Proof_of_space</a></div><div>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.</div><div><br></div><div>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."</div><div><br=
></div><div>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.<br></div><div></div><div=
><br></div><div> 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 :)</div><div><br></div><div>=
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.</div><div><a h=
ref=3D"https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-=
stop-telling-us-that-you-arent-pi3s3yjl" target=3D"_blank" rel=3D"noreferrer=
">https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-=
telling-us-that-you-arent-pi3s3yjl</a></div><div><br></div><div>Best regards=
,&nbsp; Andrew<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, Mar 5, 2021 at 3:53 PM Eric Voskuil &lt;<a hr=
ef=3D"mailto:eric@voskuil.org" target=3D"_blank" rel=3D"noreferrer">eric@vos=
kuil.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"auto"><div dir=3D"ltr">=EF=BB=BFHi Andrew,<div dir=3D"ltr"=
><div dir=3D"ltr"><br></div><div dir=3D"ltr">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.</div><div dir=3D"ltr"><br></div><div dir=3D=
"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/Effici=
ency-Paradox" target=3D"_blank" rel=3D"noreferrer">https://github.com/libbit=
coin/libbitcoin-system/wiki/Efficiency-Paradox</a></div><div dir=3D"ltr"><br=
></div><div dir=3D"ltr">You mentioned a staking hybrid in your original post=
.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github=
.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fallacy" target=3D"_bla=
nk" rel=3D"noreferrer">https://github.com/libbitcoin/libbitcoin-system/wiki/=
Hybrid-Mining-Fallacy</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><=
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</span></div><div d=
ir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitco=
in/libbitcoin-system/wiki/Proof-of-Stake-Fallacy" target=3D"_blank" rel=3D"n=
oreferrer">https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Sta=
ke-Fallacy</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">and is there=
fore what I refer to as cryptodynamically insecure.</div><div dir=3D"ltr"><b=
r></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoin=
-system/wiki/Cryptodynamic-Principles" target=3D"_blank" rel=3D"noreferrer">=
https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principle=
s</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"></div><div dir=3D"ltr=
">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.</div><div dir=3D"lt=
r"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbi=
tcoin-system/wiki/Shitcoin-Definition" target=3D"_blank" rel=3D"noreferrer">=
https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definition</a>=
</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">But BIPs are proposals aim=
ed at Bitcoin improvement.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">=
<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#Wh=
at_is_a_BIP" target=3D"_blank" rel=3D"noreferrer">https://github.com/bitcoin=
/bips/blob/master/bip-0001.mediawiki#What_is_a_BIP</a></div><div dir=3D"ltr"=
><br></div><div dir=3D"ltr">Non-staking attempts to improve energy efficienc=
y are either proof of work in disguise, such as proof of memory:</div><div d=
ir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitco=
in/libbitcoin-system/wiki/Proof-of-Memory-Fallacy" target=3D"_blank" rel=3D"=
noreferrer">https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Me=
mory-Fallacy</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">or attempt=
s to repurpose =E2=80=9Cwasteful=E2=80=9D computing, such as by finding prim=
e numbers, which<span style=3D"color:rgb(0,0,0)">&nbsp;does not imply a redu=
ction in dedicated energy consumption.</span></div><div dir=3D"ltr"><br></di=
v><div dir=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoin-syste=
m/wiki/Dedicated-Cost-Principle" target=3D"_blank" rel=3D"noreferrer">https:=
//github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle</a><=
/div><div dir=3D"ltr"><br></div><div dir=3D"ltr">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.</div><div dir=3D"ltr"><b=
r></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoin=
-system/wiki/Byproduct-Mining-Fallacy" target=3D"_blank" rel=3D"noreferrer">=
https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fallac=
y</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">The motivation behind=
 these attempts is naively understandable, but based on a false premise.</di=
v><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/=
libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy" target=3D"_blank" re=
l=3D"noreferrer">https://github.com/libbitcoin/libbitcoin-system/wiki/Energy=
-Waste-Fallacy</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">The one t=
hing that reduces Bitcoin energy consumption is an increase in energy cost r=
elative to block reward.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a=
 href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Exhaust=
ion-Fallacy" target=3D"_blank" rel=3D"noreferrer">https://github.com/libbitc=
oin/libbitcoin-system/wiki/Energy-Exhaustion-Fallacy</a></div><div dir=3D"lt=
r"><br></div><div dir=3D"ltr">e</div><div dir=3D"ltr"><br><blockquote type=3D=
"cite">On Mar 5, 2021, at 07:30, Lonero Foundation via bitcoin-dev &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D=
"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></b=
lockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=
=3D"auto">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?<div dir=3D"auto"><br></div><div dir=3D=
"auto">Best regards, Andrew</div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 5, 2021, 10:07 AM Devrandom &lt;=
<a href=3D"mailto:c1.devrandom@niftybox.net" target=3D"_blank" rel=3D"norefe=
rrer">c1.devrandom@niftybox.net</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"ltr"><div>Hi Ryan=
 and Andrew,<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev &lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer no=
referrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b=
r>
&nbsp; <a href=3D"https://www.truthcoin.info/blog/pow-cheapest/" rel=3D"nore=
ferrer noreferrer noreferrer noreferrer" target=3D"_blank">https://www.truth=
coin.info/blog/pow-cheapest/</a><br>
&nbsp; &nbsp; "Nothing is Cheaper than Proof of Work"<br>
&nbsp; &nbsp; on | 04 Aug 2015<br>
<br></blockquote><div><br></div><div>Just to belabor this a bit, the paper d=
emonstrates that the mining market will tend to expend resources equivalent t=
o miner reward.&nbsp; It does not prove that mining work has to expend *ener=
gy* as a primary cost.<br></div><div><br></div><div>Some might argue that en=
ergy expenditure has negative externalities and that we should move to other=
 resources.&nbsp; I would argue that the negative externalities will go away=
 soon because of the move to renewables, so the point is likely  moot.&nbsp;=
</div><div><br></div></div></div></div>
</blockquote></div>
<span>_______________________________________________</span><br><span>bitcoi=
n-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linux=
foundation.org</a></span><br><span><a href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noreferrer">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></di=
v></blockquote></div></div></div></blockquote></div>
</div></blockquote></div></blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-0F0F32C6-D063-448D-B75C-B599CE508F81--