path: root/04/9f53622a7bbb81497029eab207188a0d18ccb4

Return-Path: <loneroassociation@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A1937C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 23:10:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8DD154ED86
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 23:10:59 +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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id RdadQpYAvDIf
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 23:10:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com
 [IPv6:2607:f8b0:4864:20::b35])
 by smtp4.osuosl.org (Postfix) with ESMTPS id D9E6F4ED82
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 23:10:56 +0000 (UTC)
Received: by mail-yb1-xb35.google.com with SMTP id l8so3615790ybe.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 05 Mar 2021 15:10:56 -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=kV5iWD/VL4rn522X9QTsTLQo6F7groy/A1YcBdc3TII=;
 b=mi50yYlorBc9oyxNd5kSPaE9D5iAslf9I0aL6RnpRb0FK7uzBDA1+88vaL2DhD03xj
 6OQHDNrLNTSgCDjcCoFW0ThoozS4ktA6kYxMzK+kWy+lBZI6wJ3vwGnYORPm2n3ZAV49
 sU8slRhYPBH7+doVbtuqQ/hlRtx75S96FM2hoDCA5VsELqHAiJP3cwlQbRF7rbGh/AZU
 68asD1QMxyvguZiYetjyVVgZYgv+a611XtgYGuGix1uYkglTjZc/0R9+JXchTx4+V9qx
 lgt+7yxPzz58n9h+6k3JrgYY7YDYALqPaGGXgDocLrw3WMc+rOJdj7RdJAUhb7IixnSx
 nJqA==
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=kV5iWD/VL4rn522X9QTsTLQo6F7groy/A1YcBdc3TII=;
 b=cmotOP0TZ49zBmA3xSeraFDBfqHlr0CTEK2xK7zFe5/sR58YQ73H2qR+LcwBTmGjPS
 q9/GfqFqfw19Vc/GkXfkgwvnqzKcwepNIKReMjLdUZeFLjaYUKjHRxsqW4GBRnjofkxh
 hJ5hnTIMp6T4EO0vQTc3ak1fyaON0e1L/P43uw2wCztcvMRAWheSl0ysrdoUELGeo1ZE
 c6H20EWq9nX/iRLtmZ6kwfx4UAYMryuQZ0+OeJHOCCe/jKAPxReRBV3zB3Gn8N+L0PrB
 5ackHy9h/kf01b2ip/zPr8RDRSIsy2FQPmPLm/huBdVW0zwWjTA1mpsHzAqRdzlas8Ns
 BYow==
X-Gm-Message-State: AOAM533TMG9aLhJV0CiIKHvpH6nPVokMfhb27DNtGOYQMIb7cK6ZSgsf
 1OZjhDJ50OUoSivIfAvRbP5QS07PXntiue2m5OY=
X-Google-Smtp-Source: ABdhPJy9cuJ7pm+Ax3PToWi+QzLqm7ECCwbw+XlNpMzNaSPOGVDGpz300bmoB0mGxNs2EjpZTcBEM+J/3tdmYEAd1hE=
X-Received: by 2002:a25:bd85:: with SMTP id f5mr17228037ybh.183.1614985855855; 
 Fri, 05 Mar 2021 15:10:55 -0800 (PST)
MIME-Version: 1.0
References: <CA+YkXXxzURKiD5r9ATG8CefRzyh9CKzF4Cwzd3-Mr5v5XrzinA@mail.gmail.com>
 <974C7CF0-5087-4120-B860-35FAEF39EA95@voskuil.org>
In-Reply-To: <974C7CF0-5087-4120-B860-35FAEF39EA95@voskuil.org>
From: Lonero Foundation <loneroassociation@gmail.com>
Date: Fri, 5 Mar 2021 18:10:43 -0500
Message-ID: <CA+YkXXyFr3JKdONXdqbQwJd=z0KQHy9MAVn2wZDfdLufZRNDag@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="000000000000416d4d05bcd232a7"
X-Mailman-Approved-At: Sat, 06 Mar 2021 08:58:05 +0000
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 23:10:59 -0000

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

Hi, in regards to my research this is just one of my patents:
https://patents.google.com/patent/CN110825707A
This isn't related to this proposal but gives you a general depth of
understanding in regards to the technology and field I'm working on in
reducing redundancy and efficiency. You aren't a cryptographer, but there
are easy ways to validate my proposal if it was to be made. In regards to
popularity, many people have wanted to upgrade BTC's cryptography in a
similar manner. I believe it is at the very least a topic of interest to
you and others in the community. I would like to draft it out. Lastly, I
wasn't sure if you wanted to create a private thread or meant reply all so
that is my fault. The recent reply is to the BTC Dev list so I wanted to
provide my insight in regards to your inquiry.

Best regards, Andrew

On Fri, Mar 5, 2021, 5:50 PM Eric Voskuil <eric@voskuil.org> wrote:

> FYI it=E2=80=99s generally considered bad form repost a private thread, e=
specially
> one you initiate.
>
> ...
>
> It=E2=80=99s typically more effective to generate some community support =
before
> 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 t=
he 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 happ=
y to look
> at an overview of the central principles. I=E2=80=99m not a cryptographer=
. I write
> code, but I look at these things 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.
>
> e
>
> On Mar 5, 2021, at 14:03, Lonero Foundation <loneroassociation@gmail.com>
> wrote:
>
> =EF=BB=BF
> Hi, Eric. Chia's network is a bad example. They go after energy
> consumption in the wrong way entirely. True, it requires a comparable cos=
t
> of hardware. I am trying to tackle cryptography in a way that goes much
> beyond 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 efficiency issue 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 o=
n
> 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?
>>
>> 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 realize=
d I
>> was correct, 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.
>>
>> e
>>
>> On Mar 5, 2021, at 13:20, Lonero Foundation <loneroassociation@gmail.com=
>
>> wrote:
>>
>> =EF=BB=BF
>> 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 from a hybri=
d
>> 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 staking.
>>
>> 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 3:53 PM Eric Voskuil <eric@voskuil.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? If so this will only have the effect=
 of
>>> increasing the amount of it that is required to consume the same cost.
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
>>>
>>> You mentioned a staking hybrid in your original post.
>>>
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fall=
acy
>>>
>>> This would be a change to dynamics - the economic forces at work.
>>> Staking is not censorship resistant
>>>
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fal=
lacy
>>>
>>> and is therefore what I refer to as cryptodynamically insecure.
>>>
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Prin=
ciples
>>>
>>> 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.
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definitio=
n
>>>
>>> But BIPs are proposals aimed at Bitcoin improvement.
>>>
>>>
>>> https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_=
a_BIP
>>>
>>> Non-staking attempts to improve energy efficiency are either proof of
>>> work in disguise, such as proof of memory:
>>>
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fa=
llacy
>>>
>>> or attempts to repurpose =E2=80=9Cwasteful=E2=80=9D computing, such as =
by finding prime
>>> numbers, which does not imply a reduction in dedicated energy
>>> consumption.
>>>
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Pri=
nciple
>>>
>>> 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, with
>>> advantage to first movers. The market will still consume what it consum=
es.
>>> If the hashing energy was free all reward consumption would shift to
>>> operations.
>>>
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-F=
allacy
>>>
>>> The motivation behind these attempts is naively understandable, but
>>> based on a false premise.
>>>
>>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Falla=
cy
>>>
>>> The one thing that reduces Bitcoin energy consumption is an increase in
>>> energy cost relative to block reward.
>>>
>>>
>>> https://github.com/libbitcoin/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
>>> renewables or mining devices but a better cryptography layer to get the
>>> most out of your hashing for validation. I do understand the arbitrarin=
ess
>>> 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 d=
oes
>>>> not prove that mining work has to expend *energy* as a primary cost.
>>>>
>>>> Some might argue that energy expenditure has negative externalities an=
d
>>>> that we should move to other resources.  I would argue that the negati=
ve
>>>> externalities will go away soon because of the move to renewables, so =
the
>>>> point is likely moot.
>>>>
>>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>

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

<div dir=3D"auto">Hi, in regards to my research this is just one of my pate=
nts:<div dir=3D"auto"><a href=3D"https://patents.google.com/patent/CN110825=
707A">https://patents.google.com/patent/CN110825707A</a><br></div><div dir=
=3D"auto">This isn&#39;t related to this proposal but gives you a general d=
epth of understanding in regards to the technology and field I&#39;m workin=
g on in reducing redundancy and efficiency. You aren&#39;t a cryptographer,=
 but there are easy ways to validate my proposal if it was to be made. In r=
egards to popularity, many people have wanted to upgrade BTC&#39;s cryptogr=
aphy in a similar manner. I believe it is at the very least a topic of inte=
rest to you and others in the community. I would like to draft it out. Last=
ly, I wasn&#39;t sure if you wanted to create a private thread or meant rep=
ly all so that is my fault. The recent reply is to the BTC Dev list so I wa=
nted to provide my insight in regards to your inquiry.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">Best regards, Andrew</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 5, 202=
1, 5:50 PM Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.org">eric@voskui=
l.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"au=
to"><div dir=3D"ltr"><div dir=3D"ltr" style=3D"color:rgb(0,0,0)">FYI it=E2=
=80=99s generally considered bad form repost a private thread, especially o=
ne you initiate.</div><div dir=3D"ltr" style=3D"color:rgb(0,0,0)"><br></div=
><div dir=3D"ltr" style=3D"color:rgb(0,0,0)">...</div><div dir=3D"ltr" styl=
e=3D"color:rgb(0,0,0)"><br></div><div dir=3D"ltr" style=3D"color:rgb(0,0,0)=
">It=E2=80=99s typically more effective to generate some community support =
before actually submitting a BIP. Otherwise the process gets easily overwhe=
lmed. This is likely why you aren=E2=80=99t getting a response. You can dra=
ft the BIP in your own repo and collect feedback from interested parties.</=
div><div dir=3D"ltr" style=3D"color:rgb(0,0,0)"><br></div><div dir=3D"ltr" =
style=3D"color:rgb(0,0,0)">Posting a link to your research/code is a good s=
tart. I=E2=80=99d be happy to look at an overview of the central principles=
. I=E2=80=99m not a cryptographer. I write code, but I look at these things=
 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=
 dir=3D"ltr" style=3D"color:rgb(0,0,0)"><br></div><div dir=3D"ltr" style=3D=
"color:rgb(0,0,0)">e</div></div><div dir=3D"ltr"><br><blockquote type=3D"ci=
te">On Mar 5, 2021, at 14:03, Lonero Foundation &lt;<a href=3D"mailto:loner=
oassociation@gmail.com" target=3D"_blank" rel=3D"noreferrer">loneroassociat=
ion@gmail.com</a>&gt; wrote:<br><br></blockquote></div><blockquote type=3D"=
cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"auto">Hi, Eric. Chia&#39;s netw=
ork is a bad example. They go after energy consumption in the wrong way ent=
irely. True, it requires a comparable cost of hardware. I am trying to tack=
le cryptography in a way that goes much beyond that. Part of what I am doin=
g includes lowering invalided proofs while trying to get the best of both w=
orlds in regards to PoW and PoC. It is an efficiency issue 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.<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, 4:42 PM Eric Vos=
kuil &lt;<a href=3D"mailto:eric@voskuil.org" target=3D"_blank" rel=3D"noref=
errer">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:1=
ex"><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 t=
his 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 correct, on=
e of their PhDs contacted me and told me. Better to flesh this out early. T=
hey had already raised $20 and done their research, so he wasn=E2=80=99t ex=
actly in a listening mode.</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 1=
3:20, Lonero Foundation &lt;<a href=3D"mailto:loneroassociation@gmail.com" =
rel=3D"noreferrer noreferrer" target=3D"_blank">loneroassociation@gmail.com=
</a>&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div di=
r=3D"ltr">=EF=BB=BF<div dir=3D"ltr"><div>Actually I mentioned a proof of sp=
ace and time hybrid which is much different than staking. Sorry to draw for=
 the confusion as PoC is more commonly used then PoST.</div><div>There is a=
 way to make PoC cryptographically compatible w/ Proof of Work as it normal=
ly stands: <a href=3D"https://en.wikipedia.org/wiki/Proof_of_space" rel=3D"=
noreferrer noreferrer" target=3D"_blank">https://en.wikipedia.org/wiki/Proo=
f_of_space</a></div><div>It has rarely been done though given the technolog=
ical complexity of being both CPU compatible and memory-hard compatible. Th=
ere 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 o=
nly against this is the Proof of Memory fallacy, which is only partially tr=
ue. Given how the current hashing algorithm works, hard memory allocation w=
ouldn&#39;t be of much benefit given it is more optimized for CPU/ASIC spec=
ific mining. I&#39;m working towards a hybrid mechanism that fixes that. BT=
W: The way Bitcoin currently stands in its cryptography still needs updatin=
g 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 crypto=
graphy now comes down to minutes. Bitcoin is going to have to eventually ra=
dically upgrade their cryptography and hashing algo in the future regardles=
s. 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 alg=
orithm in the cryptography. More than likely the first version of my BTC ha=
rd fork will be coded in a way where integrating such complexity in the fut=
ure 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 specific hardware anyways. A majority of them wou=
ld benefit from a hybrid proof, and the fact that it is hybrid in that mann=
er wouldn&#39;t disenfranchise currently optimized mining entities as well.=
<br></div><div></div><div><br></div><div> There are other reasons why a cry=
ptography upgrade like this is beneficial. Theoretically one can argue BItc=
oin isn&#39;t fully decentralized. It is few unsolved mathematical proofs a=
way from being entirely broken. My goal outside of efficiency is to build c=
ryptography in a way that prevents such an event from happening in the futu=
re, if it was to ever happen. I have various research in regards to this ar=
ea 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 crypto=
graphic proof myself (though would like 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 what warrants a shitcoin or the whol=
e argument against staking.</div><div><a href=3D"https://hackernoon.com/eth=
ereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-p=
i3s3yjl" rel=3D"noreferrer noreferrer" target=3D"_blank">https://hackernoon=
.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you=
-arent-pi3s3yjl</a></div><div><br></div><div>Best regards,=C2=A0 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 href=3D"mailto:eri=
c@voskuil.org" rel=3D"noreferrer noreferrer" target=3D"_blank">eric@voskuil=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><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? =
If so this will only have the effect of increasing the amount of it that is=
 required to consume the same cost.</div><div dir=3D"ltr"><br></div><div di=
r=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/E=
fficiency-Paradox" rel=3D"noreferrer noreferrer" target=3D"_blank">https://=
github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox</a></div><d=
iv 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 hr=
ef=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mining-Fa=
llacy" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/l=
ibbitcoin/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 woul=
d be a change to dynamics - the economic forces at work. Staking is not cen=
sorship resistant</span></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><=
a href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Sta=
ke-Fallacy" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.=
com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy</a></div><div =
dir=3D"ltr"><br></div><div dir=3D"ltr">and is therefore what I refer to as =
cryptodynamically insecure.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr=
"><a href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodyn=
amic-Principles" rel=3D"noreferrer noreferrer" target=3D"_blank">https://gi=
thub.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles</a></di=
v><div dir=3D"ltr"><br></div><div dir=3D"ltr"></div><div dir=3D"ltr">As suc=
h it wouldn=E2=80=99t likely be considered as a contribution to Bitcoin. It=
 might of course be useful in some other context.</div><div dir=3D"ltr"><br=
></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoin=
-system/wiki/Shitcoin-Definition" rel=3D"noreferrer noreferrer" target=3D"_=
blank">https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Defini=
tion</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">But BIPs are prop=
osals aimed at Bitcoin improvement.</div><div dir=3D"ltr"><br></div><div di=
r=3D"ltr"><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0001.m=
ediawiki#What_is_a_BIP" rel=3D"noreferrer noreferrer" target=3D"_blank">htt=
ps://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 efficiency are either proof of work in disguise, such as pr=
oof of memory:</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"=
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallac=
y" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/libbi=
tcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy</a></div><div dir=3D"l=
tr"><br></div><div dir=3D"ltr">or attempts to repurpose =E2=80=9Cwasteful=
=E2=80=9D computing, such as by finding prime numbers, which<span style=3D"=
color:rgb(0,0,0)">=C2=A0does not imply a reduction in dedicated energy cons=
umption.</span></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D=
"https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Princi=
ple" rel=3D"noreferrer noreferrer" target=3D"_blank">https://github.com/lib=
bitcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle</a></div><div dir=
=3D"ltr"><br></div><div dir=3D"ltr">Finally, waste and renewable energy app=
roaches at =E2=80=9Ccarbon=E2=80=9D (vs energy) reduction must still consum=
e the same in cost as the reward. In other words, the apparent benefit repr=
esents a temporary market shift, with advantage to first movers. The market=
 will still consume what it consumes. If the hashing energy was free all re=
ward consumption would shift to operations.</div><div dir=3D"ltr"><br></div=
><div dir=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoin-syste=
m/wiki/Byproduct-Mining-Fallacy" rel=3D"noreferrer noreferrer" target=3D"_b=
lank">https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining=
-Fallacy</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">The motivatio=
n behind these attempts is naively understandable, but based on a false pre=
mise.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://g=
ithub.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy" rel=3D"no=
referrer noreferrer" target=3D"_blank">https://github.com/libbitcoin/libbit=
coin-system/wiki/Energy-Waste-Fallacy</a></div><div dir=3D"ltr"><br></div><=
div dir=3D"ltr">The one thing that reduces Bitcoin energy consumption is an=
 increase in energy cost relative to block reward.</div><div dir=3D"ltr"><b=
r></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoi=
n-system/wiki/Energy-Exhaustion-Fallacy" rel=3D"noreferrer noreferrer" targ=
et=3D"_blank">https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-E=
xhaustion-Fallacy</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</d=
iv><div dir=3D"ltr"><br><blockquote type=3D"cite">On Mar 5, 2021, at 07:30,=
 Lonero Foundation via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></blockquote></div><b=
lockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"auto">Hi, thi=
s isn&#39;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 wa=
nt to still propose a document. Do I use the Media Wiki format on GitHub an=
d just attach it as my proposal?<div dir=3D"auto"><br></div><div dir=3D"aut=
o">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>
<span>_______________________________________________</span><br><span>bitco=
in-dev mailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-d=
ev@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.l=
inuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer noreferr=
er" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev</a></span><br></div></blockquote></div></div></div></blockquote><=
/div>
</div></blockquote></div></blockquote></div>
</div></blockquote></div></blockquote></div>

--000000000000416d4d05bcd232a7--