path: root/8f/e88abe479d3c2c6752ed0de385acaccef2ec18

Return-Path: <loneroassociation@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A7EF8C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 23:41:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id A2C1140149
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 23:41:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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,
 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 IRKN7NtVUGff
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 23:41:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com
 [IPv6:2607:f8b0:4864:20::b2f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id C2A7B4013B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 Mar 2021 23:41:02 +0000 (UTC)
Received: by mail-yb1-xb2f.google.com with SMTP id c131so11996422ybf.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 08 Mar 2021 15:41:02 -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;
 bh=97Ziy2tW41ZOPMJqPFzgj7k4KfEH3M6vJttpMCaxyEI=;
 b=toyrsE79ynDoYpU+N2eaLMZ1zTvmmexBHsvHC1P7XJTAz+uTd/v4O6RkOdJ60M0liZ
 BX/379rKs+1+v8jAuVH5K4xnaaA/P/24lNXYagAYGFerMmxKm+/o3NTyFt3bI3ulFhMW
 Z01Zze5h6JW+qUjqsS3J94912kPxmWjF/cJpGR2p9FyfiA9fkGhOaTqWyFkmPEqTmnqX
 q0fe7sRHNanmtkh2Me59ixZxbg+DXAM6Q+QHU3s6R3qnytU5Kg4zw/89NRLwtiQiDEz9
 dKMTxlCYlJwN9BDJOeIWOYzyuSL5xh/LPP0MpHU+uUysqgaap7xXrJd3Yx+qjRqZiy6d
 j/9w==
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;
 bh=97Ziy2tW41ZOPMJqPFzgj7k4KfEH3M6vJttpMCaxyEI=;
 b=lxz+mFRlK+2yFQBy496He3yL74SmepGmxCbvUIbCsTMOig3G+14bXXuoIJic8X5X2f
 w7oQi66mHXj94EC5knqzz29IWChybmKr4XN9TGbD7v7Rn+0VbkVh+V5HKkNJn21b/caM
 ckoDAN8t+neaoEdsqs9DRp07esVTQ9HfMYKCePUZwFTtpCAfT9zRw7/PyhnMXxUBPtFC
 NO8tWwCsTKcvIBF4cIJs1BSnBOpIoe671Wq5nvXqd9xXhFDALsTSC5ookCRj/abUL4Fk
 ijXueIk8afaQfkV8Y/TxPxVkYu8MGFjtJMzasFEUESgf//QN22SSSZ+puHkGUmTmIGVI
 P/SA==
X-Gm-Message-State: AOAM531muOQHyIsjBPOQvK/M8nWwJGxMK3pjJb3aJ3clEOQ1At2QmcmD
 lTPe/h7wgYfTHeMNgli16SJpnjO/WHwWLN9417280ERl
X-Google-Smtp-Source: ABdhPJxIa0DQ5b/vzUbBTsrWHBZRiopO8mqtgvBFDbp5UXnzKJYEL1PCC0yp2XYKgFEo7Da0xMJKb4xBJoJjEFXGq+0=
X-Received: by 2002:a25:d843:: with SMTP id p64mr35236196ybg.339.1615246861491; 
 Mon, 08 Mar 2021 15:41:01 -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>
 <CA+YkXXyBmOootb=Kt6CH3yquYVnAZd=fJQqiF_A3p_pkB8QC3g@mail.gmail.com>
 <CALC81CMDQf4PqxRisQw58OL7QSFeMcQTvLMvmtOGJ_ya4-dhLg@mail.gmail.com>
 <CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com>
In-Reply-To: <CA+YkXXyP=BQ_a42J=RE7HJFcJ73atyrt4KWKUG8LbsbW=u4b5w@mail.gmail.com>
From: Lonero Foundation <loneroassociation@gmail.com>
Date: Mon, 8 Mar 2021 18:40:50 -0500
Message-ID: <CA+YkXXw1AiMqCoPk_pUOdDMfkGF_T+aURGAjGK=MTa7jtAQchg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006764e105bd0ef725"
X-Mailman-Approved-At: Tue, 09 Mar 2021 08:25:34 +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 <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: Mon, 08 Mar 2021 23:41:04 -0000

--0000000000006764e105bd0ef725
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, here is the list to the BIP proposal on my own repo:
https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawi=
ki
Can I submit a pull request on the BIPs repo for this to go into draft
mode? Also, I think this provides at least some more insight on what I want
to work on.

Best regards, Andrew

On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <loneroassociation@gmail.co=
m>
wrote:

> [off-list]
>
> Okay. I will do so and post the link here for discussion before doing a
> pull request on BIP's repo as the best way to handle it.
>
> Best regards, Andrew
>
> On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe <ricardojdfilipe@gmail.com>
> wrote:
>
>> 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
>> <bitcoin-dev@lists.linuxfoundation.org> 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 troubl=
e
>> 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 ab=
le
>> 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 pul=
l
>> 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 wa=
y
>> 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 fro=
m 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 cryptogra=
phy
>> community attempted to propose. The actual argument you have only agains=
t
>> 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 th=
e
>> 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 firs=
t
>> version of my BTC hard fork will be coded in a way where integrating suc=
h
>> complexity in the future only requires a soft fork or minor upgrade to i=
ts
>> 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 fro=
m 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 decentralize=
d.
>> It is few unsolved mathematical proofs away from being entirely broken. =
My
>> goal outside of efficiency is to build cryptography in a way that preven=
ts
>> 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 pro=
of
>> 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 stakin=
g.
>> >>>
>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-sto=
p-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 b=
e
>> "useless" in order for the security model to be the same. If the work wa=
s
>> useful it provides an avenue for actors to have nothing at stake when
>> submitting a proof of work, since the marginal cost of block constructio=
n
>> will be lessened by the fact that the work was useful in a different
>> context and therefore would have been done anyway. This actually degrade=
s
>> 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 hardw=
are
>> 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 bitco=
in
>> network at large. It also puts the developers in a position where they c=
an
>> 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 tack=
les
>> 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 s=
uch
>> as bigger block height have been proposed as hard forks, I feel at the v=
ery
>> least an upgrade regarding the hashing algorithm and cryptography does a=
t
>> least warrant some discussion. Anyways I hope I can send you my BIP, jus=
t
>> 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 arbitrarine=
ss
>> 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.ne=
t>
>> 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
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--0000000000006764e105bd0ef725
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi, here is the list to the BIP proposal on my own repo: =
<a href=3D"https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-dr=
aft.mediawiki">https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bi=
p-draft.mediawiki</a><div dir=3D"auto">Can I submit a pull request on the B=
IPs repo for this to go into draft mode? Also, I think this provides at lea=
st some more insight on what I want to work on.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Best regards, Andrew</div></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Mar 6, 2021, 10:4=
2 AM Lonero Foundation &lt;<a href=3D"mailto:loneroassociation@gmail.com">l=
oneroassociation@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"auto"><div dir=3D"auto">[off-list]</div><div dir=3D"auto=
"><br></div>Okay. I will do so and post the link here for discussion before=
 doing a pull request on BIP&#39;s repo as the best way to handle=C2=A0it.<=
div dir=3D"auto"><br></div><div dir=3D"auto">Best regards, Andrew</div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S=
at, Mar 6, 2021, 10:21 AM Ricardo Filipe &lt;<a href=3D"mailto:ricardojdfil=
ipe@gmail.com" target=3D"_blank" rel=3D"noreferrer">ricardojdfilipe@gmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As said before, y=
ou are free to create the BIP in your own repository<br>
and bring it to discussion on the mailing list. then you can do a PR<br>
<br>
Lonero Foundation via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefer=
rer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; escreveu no dia s=C3=A1bado,<br>
6/03/2021 =C3=A0(s) 08:58:<br>
&gt;<br>
&gt; 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 f=
inding 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 ben=
efit from the cryptography upgrade I am proposing, as this was in relation =
to the disinfranchisemet point.<br>
&gt;<br>
&gt; That said, I think the best way to move forward is to submit a BIP pul=
l request for a draft via GitHub using BIP #2&#39;s draft format and any qu=
estions people have can be answered in the reqeust&#39;s comments. That way=
 people don&#39;t have to get emails everytime there is a reply, but replie=
s still get seen as opposed to offline discussion. Since the instructions s=
ay to email bitcoin-dev before doing a bip draft, I have done that. Since p=
eople want to see the draft beforehand and it isn&#39;t merged manually any=
ways, I think it is the easiest way to handle this.<br>
&gt;<br>
&gt; I&#39;m also okay w/ continuing the discussion on bitcoin-dev but rath=
er form a discussion on git instead given I don&#39;t want to accidentally =
impolitely bother people given this is a moderated list and we already esta=
blished some interest for at least a draft.<br>
&gt;<br>
&gt; Does that seem fine?<br>
&gt;<br>
&gt; Best regards, Andrew<br>
&gt;<br>
&gt; On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland &lt;<a href=3D"mailto:k=
eagan.mcclelland@gmail.com" rel=3D"noreferrer noreferrer" target=3D"_blank"=
>keagan.mcclelland@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; A large portion of BTC is already mined through AWS servers a=
nd non-asic specific hardware anyways. A majority of them would benefit fro=
m a hybrid proof, and the fact that it is hybrid in that manner wouldn&#39;=
t disenfranchise currently optimized mining entities as well.<br>
&gt;&gt;<br>
&gt;&gt; My instincts tell me that this is an outlandish claim. Do you have=
 supporting evidence for this?<br>
&gt;&gt;<br>
&gt;&gt; Keagan<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferr=
er noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 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 mor=
e commonly used then PoST.<br>
&gt;&gt;&gt; There is a way to make PoC cryptographically compatible w/ Pro=
of of Work as it normally stands: <a href=3D"https://en.wikipedia.org/wiki/=
Proof_of_space" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">=
https://en.wikipedia.org/wiki/Proof_of_space</a><br>
&gt;&gt;&gt; It has rarely been done though given the technological complex=
ity 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 ho=
w the current hashing algorithm works, hard memory allocation wouldn&#39;t =
be of much benefit given it is more optimized for CPU/ASIC specific mining.=
 I&#39;m working towards a hybrid mechanism that fixes that. BTW: The way B=
itcoin 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&#39;s cryptography now c=
omes down to minutes. Bitcoin is going to have to eventually radically upgr=
ade 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&#39;m aiming to provide which includes a polynomial time algorithm in th=
e 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 req=
uires a soft fork or minor upgrade to its chain.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; In regards to the argument, &quot;As a separate issue, proposi=
ng a hard fork in the hashing algorithm will invalidate the enormous amount=
 of capital expenditure by mining entities and disincentivize future capita=
l expenditure into mining hardware that may compute these more &quot;useful=
&quot; proofs of work.&quot;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; A large portion of BTC is already mined through AWS servers an=
d 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&#39;t=
 disenfranchise currently optimized mining entities as well.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; There are other reasons why a cryptography upgrade like this i=
s beneficial. Theoretically one can argue BItcoin isn&#39;t fully decentral=
ized. It is few unsolved mathematical proofs away from being entirely broke=
n. My goal outside of efficiency is to build cryptography in a way that pre=
vents 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 distrib=
uted computing. I believe if the BTC community likes such a proposal, I wou=
ld single handedly be able to build the cryptographic proof myself (though =
would like as many open source contributors as I can get :)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Anyways just something to consider. We are in the same space i=
n regards to what warrants a shitcoin or the whole argument against staking=
.<br>
&gt;&gt;&gt; <a href=3D"https://hackernoon.com/ethereum-you-are-a-centraliz=
ed-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl" rel=3D"noreferre=
r noreferrer noreferrer" target=3D"_blank">https://hackernoon.com/ethereum-=
you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yj=
l</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Best regards,=C2=A0 Andrew<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland &lt;<a href=
=3D"mailto:keagan.mcclelland@gmail.com" rel=3D"noreferrer noreferrer" targe=
t=3D"_blank">keagan.mcclelland@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; It is important to understand that it is critical for the =
work to be &quot;useless&quot; in order for the security model to be the sa=
me. 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 di=
fferent context and therefore would have been done anyway. This actually de=
grades the security of the network in the process.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; As a separate issue, proposing a hard fork in the hashing =
algorithm will invalidate the enormous amount of capital expenditure by min=
ing entities and disincentivize future capital expenditure into mining hard=
ware that may compute these more &quot;useful&quot; proofs of work. This is=
 because any change in the POW algorithm will be considered unstable and su=
bject to change in the future. This puts the entire network at even more ri=
sk meaning that no entity is tying their own interests to that of the bitco=
in network at large. It also puts the developers in a position where they c=
an be bribed by entities with a vested interest in deciding what the new &q=
uot;useful&quot; proof of work should be.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; All of these things make the Bitcoin network worse off.<br=
>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Keagan<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"=
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Also in regards to my other email, I forgot to iterate=
 that my cryptography proposal helps behind the efficiency category but als=
o tackles problems such as NP-Completeness or Halting which is something th=
e 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 s=
uch 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, ju=
st let me know on the preferred format?<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Best regards, Andrew<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation &lt;<a=
 href=3D"mailto:loneroassociation@gmail.com" rel=3D"noreferrer noreferrer" =
target=3D"_blank">loneroassociation@gmail.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Hi, this isn&#39;t about the energy efficient argu=
ment in regards to renewables or mining devices but a better cryptography l=
ayer to get the most out of your hashing for validation. I do understand th=
e arbitrariness of it, but do want to still propose a document. Do I use th=
e Media Wiki format on GitHub and just attach it as my proposal?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Best regards, Andrew<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; On Fri, Mar 5, 2021, 10:07 AM Devrandom &lt;<a hre=
f=3D"mailto:c1.devrandom@niftybox.net" rel=3D"noreferrer noreferrer" target=
=3D"_blank">c1.devrandom@niftybox.net</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi Ryan and Andrew,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via =
bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" re=
l=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;=C2=A0 =C2=A0<a href=3D"https://www.truthco=
in.info/blog/pow-cheapest/" rel=3D"noreferrer noreferrer noreferrer" target=
=3D"_blank">https://www.truthcoin.info/blog/pow-cheapest/</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0&quot;Nothing is Cheape=
r than Proof of Work&quot;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0on | 04 Aug 2015<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Just to belabor this a bit, the paper demonstr=
ates that the mining market will tend to expend resources equivalent to min=
er reward.=C2=A0 It does not prove that mining work has to expend *energy* =
as a primary cost.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Some might argue that energy expenditure has n=
egative externalities and that we should move to other resources.=C2=A0 I w=
ould argue that the negative externalities will go away soon because of the=
 move to renewables, so the point is likely moot.<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxf=
oundation.org</a><br>
&gt;&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/l=
istinfo/bitcoin-dev" rel=3D"noreferrer noreferrer noreferrer" target=3D"_bl=
ank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=
=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">htt=
ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lis=
ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--0000000000006764e105bd0ef725--