path: root/41/8eabb651c9c519a7ba9ac036f21808266678c4

Return-Path: <loneroassociation@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E9A33C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  6 Mar 2021 00:57:49 +0000 (UTC)
Received: by mail-yb1-xb2d.google.com with SMTP id 133so3843286ybd.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CA+YkXXxUdZFYTa1c-F=-FzoQQVtV3GUmE2Okec-zRAD3xS1qAQ@mail.gmail.com>
 <CAMnpzfop8ttqjMAKoS37zpQV6WiZfi1Bn+y_e-HaepTiD4Vm1Q@mail.gmail.com>
 <CAB0O3SVNyr_t23Y0LyT0mSaf6LONFRLYJ8qzO7rcdJFnrGccFw@mail.gmail.com>
 <CA+YkXXwkSCu=2UOEhzFBzGDHo1c=Ewqsnxp632ke3jdH1ff5WA@mail.gmail.com>
 <CA+YkXXwfS7eer5Za_ed9tCNdfOp4c3nV_X=mfXzoDxMm6BrizQ@mail.gmail.com>
 <CALeFGL31M5DAULLRtCwjPYHaPVqsVqREUg6WQ2-cuj23SNk=BA@mail.gmail.com>
 <CA+YkXXwBMG6YUAhf-2U5EV5Ep5RgG2foc9chramNFN5=AQ=-EA@mail.gmail.com>
 <CALeFGL3E-rWW9aJkwre_3UF44vbNxPH2436DvaQdHoqEQ5b+eg@mail.gmail.com>
In-Reply-To: <CALeFGL3E-rWW9aJkwre_3UF44vbNxPH2436DvaQdHoqEQ5b+eg@mail.gmail.com>
From: Lonero Foundation <loneroassociation@gmail.com>
Date: Fri, 5 Mar 2021 19:57:36 -0500
Message-ID: <CA+YkXXyBmOootb=Kt6CH3yquYVnAZd=fJQqiF_A3p_pkB8QC3g@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000072a3b005bcd3b0bd"
X-Mailman-Approved-At: Sat, 06 Mar 2021 08:58:05 +0000
Cc: Bitcoin Protocol Discussion <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: 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 <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 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 <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 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

<div dir=3D"auto">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<div dir=3D"auto"><br></d=
iv><div dir=3D"auto">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&#39;s draft f=
ormat and any questions people have can be answered in the reqeust&#39;s co=
mments. That way people don&#39;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&#39;t mer=
ged manually anyways, I think it is the easiest way to handle this.=C2=A0</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m also okay w/ cont=
inuing the discussion on bitcoin-dev but rather form a discussion on git in=
stead given I don&#39;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.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Does that =
seem fine?<br><div dir=3D"auto"><br></div><div dir=3D"auto">Best regards, A=
ndrew</div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland &lt;<a href=
=3D"mailto:keagan.mcclelland@gmail.com">keagan.mcclelland@gmail.com</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">&gt; 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&#39;t disenfranchise cu=
rrently optimized mining entities as well.<div><br></div><div>My instincts =
tell me that this is an outlandish claim. Do you have supporting evidence f=
or this?</div><div><br></div><div>Keagan</div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 5, 2021 at 3:22 P=
M Lonero Foundation via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div>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.</div><div>There is a way to make PoC cryptographic=
ally compatible 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.wikipedia.org/wiki/Proof_of_space</a></div><div>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&#39;t be of much benefit given it is more optimize=
d
 for CPU/ASIC specific mining. I&#39;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&#39;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&#39;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.</div=
><div><br></div><div>In regards to the argument, &quot;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 &quot;useful&quot; proofs of work.&quo=
t;</div><div><br></div><div>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&#39;t=20
disenfranchise currently optimized mining entities as well.<br></div><div><=
br></div><div>
 There are other reasons why a cryptography upgrade like this is=20
beneficial. Theoretically one can argue BItcoin isn&#39;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 :)</div><div><br></div><div>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.</div><div><a hre=
f=3D"https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-s=
top-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 regar=
ds,=C2=A0 Andrew</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland &lt;=
<a href=3D"mailto:keagan.mcclelland@gmail.com" target=3D"_blank" rel=3D"nor=
eferrer">keagan.mcclelland@gmail.com</a>&gt; wrote:<br></div><blockquote cl=
ass=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"ltr">It is important to und=
erstand that it is critical for the work to be &quot;useless&quot; 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.<div><br></div><div>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 &quot;useful&quot; 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 &quot;useful&quot; proof of work should be.</div><div><br>=
</div><div>All of these things make the Bitcoin network worse off.</div><di=
v><br></div><div>Keagan</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundat=
ion via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"auto">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?<div dir=3D"auto"><br></div><div d=
ir=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, 10:12 AM Lonero =
Foundation &lt;<a href=3D"mailto:loneroassociation@gmail.com" target=3D"_bl=
ank" rel=3D"noreferrer">loneroassociation@gmail.com</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">Hi, th=
is isn&#39;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?<div dir=3D"auto"><br></div><div dir=3D"au=
to">Best regards, Andrew</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Mar 5, 2021, 10:07 AM Devrandom &lt;<=
a href=3D"mailto:c1.devrandom@niftybox.net" rel=3D"noreferrer noreferrer" t=
arget=3D"_blank">c1.devrandom@niftybox.net</a>&gt; wrote:<br></div><blockqu=
ote 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=
"><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" r=
el=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br>
=C2=A0 <a href=3D"https://www.truthcoin.info/blog/pow-cheapest/" rel=3D"nor=
eferrer noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">http=
s://www.truthcoin.info/blog/pow-cheapest/</a><br>
=C2=A0 =C2=A0 &quot;Nothing is Cheaper than Proof of Work&quot;<br>
=C2=A0 =C2=A0 on | 04 Aug 2015<br>
<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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</div><div><br></div></div></div></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--00000000000072a3b005bcd3b0bd--