path: root/86/475c181c95689e2bbd946906ca2a52f3265038

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 72527C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 22:03:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 5F00E43008
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 22:03:36 +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 0uiLHYikA89B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 22:03:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com
 [IPv6:2607:f8b0:4864:20::b2a])
 by smtp2.osuosl.org (Postfix) with ESMTPS id A15F64301F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  5 Mar 2021 22:03:34 +0000 (UTC)
Received: by mail-yb1-xb2a.google.com with SMTP id m9so3490023ybk.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 05 Mar 2021 14:03:34 -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=3U+qaZlbftvLQXyhq9FrUjZmUt5QwaRdc/xtJJ2zG9k=;
 b=O5Tsyv8Jr9Eoay0nnFkyZog79vQYXMBwwp5uOFP0wsjkRkWV7+qE2pgh7e4Mf30y/p
 /zL7DQClfIBJiBnrHdvftpZCbNXuv1yzc8dFNK6BX2/kR+hfaOwqDaBbATpsmiR90hri
 FBlJNfWh3d4aOSaBDzOf2bqxroaqqfCM8tF7JgwgxztV0VI06152Xpbh1OOG931KMuuX
 fn8cA3GeJCm3ZiRs8XWCA0k5OKM0y9DfzyluPCOirQehizsper+EmL2wJEW4dqL4Nw2a
 iYtya5wZX6mBPPuWv9P4ymEzPliC7D+XFRZx3kUuuV04d1XrxW2N9l90UNxvl/RbovN0
 IA8w==
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=3U+qaZlbftvLQXyhq9FrUjZmUt5QwaRdc/xtJJ2zG9k=;
 b=BLMSW/2dcSrIlD3TWTEn3aFMvt+7i2YgydBU3R4h9QoPrJ+HwTqBQbxfXLUCrKZeiR
 +mHxrLoiMUL2F5X3m17TYb5cqkz0Za98+nrS7QmPU8qDHVpxWJc6ccAp9zKx3i/+IXDs
 kd2lpByZ6Lu2RDAfK6vpZ/edFc6xCM8zcfuDNuhDlFmSaEqmlExV8r4wM6lLDWGwGeXm
 lxwNaBh9Ba6RKjIp7cXca1H2uljtUTytWaaZqeYOVQhYXgOJ3hrNUoNl9TCmGFQ8eiLg
 1HDKl021GLfEMSJOXsImYEa9dJjnVyTbL1GALUMvmWwE9T03J/Q/6TCFYesmmRvuFLLX
 ef3Q==
X-Gm-Message-State: AOAM5335h3FhXocAeWQpvleSKs1ZR4vcvUHpxdEyZxxdpD3LJ77kgx0/
 j8P7qTcq5sGui6VA/Mx0zCfcN7UJn745W6z1IDk=
X-Google-Smtp-Source: ABdhPJxrIxjeu5Rllo8eMi/s+WJw4PHFYuNY5gyOn092j+4lgwQCjVPIRbatMDqyO9VKMjcIF24+CSZLOYaQxSjSBiw=
X-Received: by 2002:a25:9d0d:: with SMTP id i13mr16354460ybp.236.1614981813445; 
 Fri, 05 Mar 2021 14:03:33 -0800 (PST)
MIME-Version: 1.0
References: <CA+YkXXzfEyeXYMyPKL20S+2VVRZVuHRT6eRgX56FBgG_A+uVSw@mail.gmail.com>
 <12480994-451A-4256-8EFA-4741B3EC2006@voskuil.org>
In-Reply-To: <12480994-451A-4256-8EFA-4741B3EC2006@voskuil.org>
From: Lonero Foundation <loneroassociation@gmail.com>
Date: Fri, 5 Mar 2021 17:03:21 -0500
Message-ID: <CA+YkXXxzURKiD5r9ATG8CefRzyh9CKzF4Cwzd3-Mr5v5XrzinA@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative; boundary="0000000000004f273705bcd14192"
X-Mailman-Approved-At: Fri, 05 Mar 2021 22:21:51 +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 22:03:36 -0000

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

Hi, Eric. Chia's network is a bad example. They go after energy consumption
in the wrong way entirely. True, it requires a comparable cost of hardware.
I am trying to tackle cryptography in a way that goes much beyond that.
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 on GitHub.

Best regards, Andrew

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

> How is the argument against PoM only partially true?
>
> I wrote this as soon as I saw Chia. Had two debates on Twitter with Brahm=
,
> before he blocked me. Two years later, after they finally realized I was
> 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 bein=
g
> both CPU compatible and memory-hard compatible. There are lots of benefit=
s
> outside of the realm of efficiency, and I already looked into numerous
> 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 it=
s
> chain.
>
> In regards to the argument, "As a separate issue, proposing a hard fork i=
n
> the hashing algorithm will invalidate the enormous amount of capital
> 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. M=
y
> goal outside of efficiency is to build cryptography in a way that prevent=
s
> 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 proo=
f
> 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 t=
o
> 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 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 a=
t
>> 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-Falla=
cy
>>
>> This would be a change to dynamics - the economic forces at work. Stakin=
g
>> is not censorship resistant
>>
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fall=
acy
>>
>> and is therefore what I refer to as cryptodynamically insecure.
>>
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Princ=
iples
>>
>> As such it wouldn=E2=80=99t likely be considered as a contribution to Bi=
tcoin. It
>> might of course be useful in some other context.
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definition
>>
>> 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-Fal=
lacy
>>
>> or attempts to repurpose =E2=80=9Cwasteful=E2=80=9D computing, such as b=
y finding prime
>> numbers, which does not imply a reduction in dedicated energy
>> consumption.
>>
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Dedicated-Cost-Prin=
ciple
>>
>> 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 consume=
s.
>> If the hashing energy was free all reward consumption would shift to
>> operations.
>>
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fa=
llacy
>>
>> The motivation behind these attempts is naively understandable, but base=
d
>> on a false premise.
>>
>> https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallac=
y
>>
>> 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-F=
allacy
>>
>> 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 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.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 do=
es
>>> 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 negativ=
e
>>> externalities will go away soon because of the move to renewables, so t=
he
>>> point is likely moot.
>>>
>>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>

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

<div dir=3D"auto">Hi, Eric. Chia&#39;s network is a bad example. They go af=
ter energy consumption in the wrong way entirely. True, it requires a compa=
rable cost of hardware. I am trying to tackle cryptography in a way that go=
es much beyond that. Part of what I am doing includes lowering invalided pr=
oofs 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 a=
m hoping the BIP team would be so gracious as to allow me to draft it out o=
n GitHub.<div dir=3D"auto"><br></div><div dir=3D"auto">Best regards, Andrew=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Fri, Mar 5, 2021, 4:42 PM Eric Voskuil &lt;<a href=3D"mailto:eric@=
voskuil.org">eric@voskuil.org</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"auto"><div dir=3D"ltr">How is the argument against Po=
M only partially true?</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">I w=
rote this as soon as I saw Chia. Had two debates on Twitter with Brahm, bef=
ore he blocked me. Two years later, after they finally realized I was corre=
ct, one of their PhDs contacted me and told me. Better to flesh this out ea=
rly. They had already raised $20 and done their research, so he wasn=E2=80=
=99t exactly 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, 20=
21, at 13:20, Lonero Foundation &lt;<a href=3D"mailto:loneroassociation@gma=
il.com" target=3D"_blank" rel=3D"noreferrer">loneroassociation@gmail.com</a=
>&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=
=3D"ltr">=EF=BB=BF<div dir=3D"ltr"><div>Actually I mentioned a proof of spa=
ce 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 normall=
y 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 compl=
exity of being both CPU compatible and memory-hard compatible. There are lo=
ts of benefits outside of the realm of efficiency, and I already looked int=
o numerous fault tolerant designs as well and what others in the cryptograp=
hy 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&#39;=
t be of much benefit given it is more optimized for CPU/ASIC specific minin=
g. I&#39;m working towards a hybrid mechanism that fixes that. BTW: The way=
 Bitcoin currently stands in its cryptography still needs updating regardle=
ss. If someone figures out NP hardness or the halting problem the tradition=
al rule of millions of years to break all of Bitcoin&#39;s cryptography now=
 comes down to minutes. Bitcoin is going to have to eventually radically up=
grade their cryptography and hashing algo in the future regardless. I want =
to integrate some form of NP complexity in regards to the hybrid cryptograp=
hy I&#39;m aiming to provide which includes a polynomial time algorithm in =
the cryptography. More than likely the first version of my BTC hard fork wi=
ll be coded in a way where integrating such complexity in the future only r=
equires 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 fo=
rk 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" target=3D"_blank" rel=3D"noreferrer">https://hackernoon.com/ethere=
um-you-are-a-centralized-cryptocurrency-stop-telling-us-that-you-arent-pi3s=
3yjl</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 Fr=
i, Mar 5, 2021 at 3:53 PM Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.o=
rg" target=3D"_blank" rel=3D"noreferrer">eric@voskuil.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">=
<div dir=3D"ltr">=EF=BB=BFHi Andrew,<div dir=3D"ltr"><div dir=3D"ltr"><br><=
/div><div dir=3D"ltr">Do you mean that you can reduce the cost of executing=
 the cryptography at a comparable level of security? If so this will only h=
ave the effect of increasing the amount of it that is required to consume t=
he same cost.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"h=
ttps://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox" tar=
get=3D"_blank" rel=3D"noreferrer">https://github.com/libbitcoin/libbitcoin-=
system/wiki/Efficiency-Paradox</a></div><div dir=3D"ltr"><br></div><div dir=
=3D"ltr">You mentioned a staking hybrid in your original post.</div><div di=
r=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitco=
in/libbitcoin-system/wiki/Hybrid-Mining-Fallacy" target=3D"_blank" rel=3D"n=
oreferrer">https://github.com/libbitcoin/libbitcoin-system/wiki/Hybrid-Mini=
ng-Fallacy</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><span style=
=3D"color:rgb(0,0,0)">This would be a change to dynamics - the economic for=
ces at work. Staking is not censorship resistant</span></div><div dir=3D"lt=
r"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/libbitcoin/libb=
itcoin-system/wiki/Proof-of-Stake-Fallacy" target=3D"_blank" rel=3D"norefer=
rer">https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fa=
llacy</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-s=
ystem/wiki/Cryptodynamic-Principles" target=3D"_blank" rel=3D"noreferrer">h=
ttps://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principle=
s</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"></div><div dir=3D"lt=
r">As such it wouldn=E2=80=99t likely be considered as a contribution to Bi=
tcoin. 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/l=
ibbitcoin-system/wiki/Shitcoin-Definition" target=3D"_blank" rel=3D"norefer=
rer">https://github.com/libbitcoin/libbitcoin-system/wiki/Shitcoin-Definiti=
on</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">But BIPs are propos=
als aimed at Bitcoin improvement.</div><div dir=3D"ltr"><br></div><div dir=
=3D"ltr"><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0001.me=
diawiki#What_is_a_BIP" target=3D"_blank" rel=3D"noreferrer">https://github.=
com/bitcoin/bips/blob/master/bip-0001.mediawiki#What_is_a_BIP</a></div><div=
 dir=3D"ltr"><br></div><div dir=3D"ltr">Non-staking attempts to improve ene=
rgy efficiency are either proof of work in disguise, such as proof of memor=
y:</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://gith=
ub.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy" target=3D=
"_blank" rel=3D"noreferrer">https://github.com/libbitcoin/libbitcoin-system=
/wiki/Proof-of-Memory-Fallacy</a></div><div dir=3D"ltr"><br></div><div dir=
=3D"ltr">or attempts to repurpose =E2=80=9Cwasteful=E2=80=9D computing, suc=
h as by finding prime numbers, which<span style=3D"color:rgb(0,0,0)">=C2=A0=
does not imply a reduction in dedicated energy consumption.</span></div><di=
v dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/libb=
itcoin/libbitcoin-system/wiki/Dedicated-Cost-Principle" target=3D"_blank" r=
el=3D"noreferrer">https://github.com/libbitcoin/libbitcoin-system/wiki/Dedi=
cated-Cost-Principle</a></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">F=
inally, 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 consumes.=
 If the hashing energy was free all reward consumption would shift to opera=
tions.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://=
github.com/libbitcoin/libbitcoin-system/wiki/Byproduct-Mining-Fallacy" targ=
et=3D"_blank" rel=3D"noreferrer">https://github.com/libbitcoin/libbitcoin-s=
ystem/wiki/Byproduct-Mining-Fallacy</a></div><div dir=3D"ltr"><br></div><di=
v dir=3D"ltr">The motivation behind these attempts is naively understandabl=
e, but based on a false premise.</div><div dir=3D"ltr"><br></div><div dir=
=3D"ltr"><a href=3D"https://github.com/libbitcoin/libbitcoin-system/wiki/En=
ergy-Waste-Fallacy" target=3D"_blank" rel=3D"noreferrer">https://github.com=
/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy</a></div><div dir=
=3D"ltr"><br></div><div dir=3D"ltr">The one thing that reduces Bitcoin ener=
gy consumption is an increase in energy cost relative to block reward.</div=
><div dir=3D"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://github.com/=
libbitcoin/libbitcoin-system/wiki/Energy-Exhaustion-Fallacy" target=3D"_bla=
nk" rel=3D"noreferrer">https://github.com/libbitcoin/libbitcoin-system/wiki=
/Energy-Exhaustion-Fallacy</a></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 07:30, Lonero Foundation via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></blockquote></div><blo=
ckquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div dir=3D"auto">Hi, this =
isn&#39;t about the energy efficient argument in regards to renewables or m=
ining devices but a better cryptography layer to get the most out of your h=
ashing 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?<div dir=3D"auto"><br></div><div dir=3D"auto"=
>Best regards, Andrew</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Fri, Mar 5, 2021, 10:07 AM Devrandom &lt;<a h=
ref=3D"mailto:c1.devrandom@niftybox.net" target=3D"_blank" rel=3D"noreferre=
r">c1.devrandom@niftybox.net</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_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" rel=3D"noreferr=
er noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(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" target=3D"_blank">https://www.tru=
thcoin.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" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.li=
nuxfoundation.org</a></span><br><span><a href=3D"https://lists.linuxfoundat=
ion.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noreferrer">=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><b=
r></div></blockquote></div></div></div></blockquote></div>
</div></blockquote></div></blockquote></div>

--0000000000004f273705bcd14192--