path: root/25/f00fe515d02ec0f1c003d823ff5305ee3f8bf6

Return-Path: <loneroassociation@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 784C7C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 23:32:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 4523C605A4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 23:32:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ebEhub-1begS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 23:32:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com
 [IPv6:2607:f8b0:4864:20::b2b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id B5E3A6059E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 23:32:03 +0000 (UTC)
Received: by mail-yb1-xb2b.google.com with SMTP id c131so27052234ybf.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Mar 2021 15:32:03 -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=EKDmATKv2MLw1Oeo9eYpfj9wqaKD2Ca5f1jexxvnm80=;
 b=up9DQq/4X7cBApAAtTvi/LHW8OtN1rwyX+qdcDxJQcWDLOJf8hWJvtwhUmU1r/Gz7w
 lQkuGiCRw9XDk/43nx/t1qi2w+635ZLX2EjACVJMSDD3OaSB9Q+1bXOJ03pSmUOIiV3W
 IlW/3YAy3vfUn/47Xmv9LY7gVnBpLL49YjvZ4cOUp80nLAHwCsliAbGDAzEUbE88HC8m
 uXOJ4wVxlpbjlHa4wopkwc7+/q8epPi3gfHXhru6u6mnIZtXeSBFngNGSsUOlR7I+Yzm
 OqlJRSnGZae++W+xMhUS2Q4objbVApM5uFEkIPYfjcDhOT90yHCfq7EQ6WcgcfbeV/sm
 BiWw==
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=EKDmATKv2MLw1Oeo9eYpfj9wqaKD2Ca5f1jexxvnm80=;
 b=UgASsQolvrFVfkacFeLqnuI18LuTyaqYMQfKBmNmcEyDqKYgntntKG62nbIwpYvoIx
 PrmHbPS1nVa7E4wXHRi/TMU7va6uFKIOD36oFls0JrxhIA40kTJubJ7ETNVmct+8k1YJ
 rUpsGAuorCuzDjBVWktTxqiiO4yZdOBJiXiMfwrEngv6DjMuUbMoXcRKx+ZTLqPJ5Izd
 Rt69PJETQTEYtijsNXDyblbMUhXRrwm8dk1Q/3zRUmm19n0K/zJCdXv2ahYc5oUDpV3m
 WANuTUO32Q1ejUFlAMPES42IDqoamMf6RFwZhb0m6MiZo/ER8v0SjUSloNrjrnolNknU
 NSUw==
X-Gm-Message-State: AOAM533oPvYzlpMLmaeD45P87/gcR5L1sWwe/pwLQlhbW+VGCfJ0vLPL
 lnEcpiOqnOdSAANQaOoYY6fDCobIcM0s3F11ue4=
X-Google-Smtp-Source: ABdhPJwPrc2brSY51Jemoc1Ool0peHgtG1w5vJoWpMbIe3gOcn3jDMfE16YdYSq+dD1cuuL54tZhZ2ztVhxI1VG+dCY=
X-Received: by 2002:a25:b206:: with SMTP id i6mr21622638ybj.499.1615591922586; 
 Fri, 12 Mar 2021 15:32:02 -0800 (PST)
MIME-Version: 1.0
References: <CA+YkXXz9aHfZtt-it_8w4ovF=-QaZ4_9vwDS0Kz36qhHwVDC5Q@mail.gmail.com>
 <3d65-604bed00-17d-6093c680@171273340>
 <CA+YkXXzNAWrPPJfDtB-DXaSf9yoojkuEXeCXzkB2_cMtyHfFXA@mail.gmail.com>
In-Reply-To: <CA+YkXXzNAWrPPJfDtB-DXaSf9yoojkuEXeCXzkB2_cMtyHfFXA@mail.gmail.com>
From: Lonero Foundation <loneroassociation@gmail.com>
Date: Fri, 12 Mar 2021 18:31:51 -0500
Message-ID: <CA+YkXXw5uh4yfvqDiBBEXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com>
To: "email@yancy.lol" <email@yancy.lol>
Content-Type: multipart/alternative; boundary="000000000000a5d83c05bd5f4e9f"
X-Mailman-Approved-At: Sat, 13 Mar 2021 22:53:20 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST
 Datastore for Energy Efficient Mining
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 23:32:06 -0000

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

Also, I already stated I was referring to signature validation cryptography
in that aspect:
https://wizardforcel.gitbooks.io/practical-cryptography-for-developers-book=
/content/digital-signatures/ecdsa-sign-verify-examples.html
My BIP has a primary purpose in regards to what I want to develop proofs
for and the different cryptographic elements I want to develop proofs for.
That said to those who disagree with the premise, I do prefer constructive
feedback over insults or making fun of one another. After all this is an
improvement proposal with a specific purpose aiming to develop a specific
thing, not a guy who is just wanting to copy and paste a repository and
call it a day.

Best regards, Andrew

On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation <
loneroassociation@gmail.com> wrote:

> Hi, I also want to emphasize that my main point isn't just to create a BT=
C
> hardfork or become another Bitcoin Cash, Gold, or SV. The main point in
> regards to this BIP actually expands POW rather than replaces or creates =
an
> alternative. Many of the problems faced in regards to security in the
> future as well as sustainability is something I believe lots of the chang=
es
> I am proposing can fix. In regards to technological implementation, once
> this is assigned draft status I am more than willing to create preprints
> explaining the cryptography, hashing algorithm improvements, and consensu=
s
> that I am working on. This is a highly technologically complex idea that =
I
> am willing to "call my bluff on" and expand upon. As for it being a draft=
,
> I think this is a good starting point at least for draft status prior to
> working on technological implementation.
>
> Best regards, Andrew
>
> On Fri, Mar 12, 2021 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote:
>
>> I think Andrew himself is an algo.  The crypto training set must not be
>> very good.
>>
>> Cheers,
>> -Yancy
>>
>> On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>> Hi, I awkwardly phrased that part, I was referring to key validation in
>> relation to that section as well as the hashing related to those keys. I
>> might rephrase it.
>>
>> In regards to technical merit, the main purpose of the BIP is to get a
>> sense of the idea. Once I get assigned a BIP draft #, I am willing to
>> follow it up with many preprints or publications to go in the references
>> implementation section and start dev work before upgrading to final stat=
us.
>>
>> This will take about 400 hours of my time, but is something I am
>> personally looking into developing as a hard fork.
>>
>> Keep in mind this is a draft, so after it is assigned a number to
>> references I do at the very least hope to describe various parts of the
>> cryptographic proofs and algorithmic structure I am hoping for.
>>
>> Best regards, Andrew
>>
>> On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty <erik@q32.com> wrote:
>>
>>> secp236k1 isn't a hashing algo.   your BIP needs about 10 more pages
>>> and some degree of technical merit.
>>>
>>> i suggest you start here:
>>>
>>> https://en.bitcoin.it/wiki/Proof_of_burn
>>> https://bitcointalk.org/index.php?topic=3D225690.0
>>>
>>> proof-of-burn is a nice alternative to proof-of-work.   i always
>>> suspected that, if designed correctly, it could be a proven
>>> equivalent.   you could spin up a fork of bitcoin that allows aged,
>>> burned, coins instead of POW that would probably work just fine.
>>>
>>> - erik
>>>
>>> On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundation via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> >
>>> > Hi, I have submitted the BIP Pull Request here:
>>> https://github.com/bitcoin/bips/pull/1084
>>> >
>>> > Hoping to receive a BIP # for the draft prior to development/referenc=
e
>>> implementation.
>>> >
>>> > Best regards, Andrew
>>> >
>>> > On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation <
>>> loneroassociation@gmail.com> wrote:
>>> >>
>>> >> Hi, here is the list to the BIP proposal on my own repo:
>>> https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.med=
iawiki
>>> >> 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 w=
hat
>>> I want to work on.
>>> >>
>>> >> Best regards, Andrew
>>> >>
>>> >> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <
>>> loneroassociation@gmail.com> 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=A1bad=
o,
>>> >>>> 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. H=
ad
>>> trouble finding the article online so take it with a grain of salt. The
>>> point though is that both servers and ASIC specific hardware would stil=
l be
>>> able to benefit from the cryptography upgrade I am proposing, as this w=
as
>>> in relation to the disinfranchisemet point.
>>> >>>> >
>>> >>>> > That said, I think the best way to move forward is to submit a
>>> BIP pull request for a draft via GitHub using BIP #2's draft format and=
 any
>>> questions people have can be answered in the reqeust's comments. That w=
ay
>>> 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 accidenta=
lly
>>> 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 benefi=
t
>>> from a hybrid proof, and the fact that it is hybrid in that manner woul=
dn'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-de=
v
>>> <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. The=
re
>>> 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 ha=
ve
>>> only against this is the Proof of Memory fallacy, which is only partial=
ly
>>> true. Given how the current hashing algorithm works, hard memory alloca=
tion
>>> 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 Bitco=
in'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 fir=
st
>>> version of my BTC hard fork will be coded in a way where integrating su=
ch
>>> complexity in the future only requires a soft fork or minor upgrade to =
its
>>> chain.
>>> >>>> >>>
>>> >>>> >>> In regards to the argument, "As a separate issue, proposing a
>>> hard fork in the hashing algorithm will invalidate the enormous amount =
of
>>> capital expenditure by mining entities and disincentivize future capita=
l
>>> expenditure into mining hardware that may compute these more "useful"
>>> proofs of work."
>>> >>>> >>>
>>> >>>> >>> A large portion of BTC is already mined through AWS servers an=
d
>>> non-asic specific hardware anyways. A majority of them would benefit fr=
om 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 i=
s
>>> beneficial. Theoretically one can argue BItcoin isn't fully decentraliz=
ed.
>>> It is few unsolved mathematical proofs away from being entirely broken.=
 My
>>> goal outside of efficiency is to build cryptography in a way that preve=
nts
>>> 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 pr=
oof
>>> myself (though would like as many open source contributors as I can get=
 :)
>>> >>>> >>>
>>> >>>> >>> Anyways just something to consider. We are in the same space i=
n
>>> regards to what warrants a shitcoin or the whole argument against staki=
ng.
>>> >>>> >>>
>>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-st=
op-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 wor=
k
>>> to be "useless" in order for the security model to be the same. If the =
work
>>> was useful it provides an avenue for actors to have nothing at stake wh=
en
>>> submitting a proof of work, since the marginal cost of block constructi=
on
>>> will be lessened by the fact that the work was useful in a different
>>> context and therefore would have been done anyway. This actually degrad=
es
>>> 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 mini=
ng
>>> hardware that may compute these more "useful" proofs of work. This is
>>> because any change in the POW algorithm will be considered unstable and
>>> subject to change in the future. This puts the entire network at even m=
ore
>>> risk meaning that no entity is tying their own interests to that of the
>>> bitcoin network at large. It also puts the developers in a position whe=
re
>>> they can be bribed by entities with a vested interest in deciding what =
the
>>> new "useful" proof of work should be.
>>> >>>> >>>>
>>> >>>> >>>> All of these things make the Bitcoin network worse off.
>>> >>>> >>>>
>>> >>>> >>>> Keagan
>>> >>>> >>>>
>>> >>>> >>>> On Fri, Mar 5, 2021 at 1:48 PM Lonero Foundation via
>>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> >>>> >>>>>
>>> >>>> >>>>> Also in regards to my other email, I forgot to iterate that
>>> my cryptography proposal helps behind the efficiency category but also
>>> tackles problems such as NP-Completeness or Halting which is something =
the
>>> BTC network could be vulnerable to in the future. For sake of simplicit=
y, I
>>> do want to do this BIP because it tackles lots of the issues in regards=
 to
>>> this manner and can provide useful insight to the community. If things =
such
>>> as bigger block height have been proposed as hard forks, I feel at the =
very
>>> least an upgrade regarding the hashing algorithm and cryptography does =
at
>>> least warrant some discussion. Anyways I hope I can send you my BIP, ju=
st
>>> let me know on the preferred format?
>>> >>>> >>>>>
>>> >>>> >>>>> Best regards, Andrew
>>> >>>> >>>>>
>>> >>>> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <
>>> loneroassociation@gmail.com> wrote:
>>> >>>> >>>>>>
>>> >>>> >>>>>> Hi, this isn't about the energy efficient argument in
>>> regards to renewables or mining devices but a better cryptography layer=
 to
>>> get the most out of your hashing for validation. I do understand the
>>> arbitrariness of it, but do want to still propose a document. Do I use =
the
>>> Media Wiki format on GitHub and just attach it as my proposal?
>>> >>>> >>>>>>
>>> >>>> >>>>>> Best regards, Andrew
>>> >>>> >>>>>>
>>> >>>> >>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <
>>> c1.devrandom@niftybox.net> wrote:
>>> >>>> >>>>>>>
>>> >>>> >>>>>>> Hi Ryan and Andrew,
>>> >>>> >>>>>>>
>>> >>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev =
<
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> >>>> >>>>>>>>
>>> >>>> >>>>>>>>
>>> >>>> >>>>>>>>   https://www.truthcoin.info/blog/pow-cheapest/
>>> >>>> >>>>>>>>     "Nothing is Cheaper than Proof of Work"
>>> >>>> >>>>>>>>     on | 04 Aug 2015
>>> >>>> >>>>>>>>
>>> >>>> >>>>>>>
>>> >>>> >>>>>>> Just to belabor this a bit, the paper demonstrates that th=
e
>>> 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 cos=
t.
>>> >>>> >>>>>>>
>>> >>>> >>>>>>> Some might argue that energy expenditure has negative
>>> externalities and that we should move to other resources.  I would argu=
e
>>> that the negative externalities will go away soon because of the move t=
o
>>> 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
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>>
>
>

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

<div dir=3D"ltr"><div>Also, I already stated I was referring to signature v=
alidation cryptography in that aspect: <a href=3D"https://wizardforcel.gitb=
ooks.io/practical-cryptography-for-developers-book/content/digital-signatur=
es/ecdsa-sign-verify-examples.html">https://wizardforcel.gitbooks.io/practi=
cal-cryptography-for-developers-book/content/digital-signatures/ecdsa-sign-=
verify-examples.html</a></div><div>My BIP has a primary purpose in regards =
to what I want to develop proofs for and the different cryptographic elemen=
ts I want to develop proofs for.</div><div>That said to those who disagree =
with the premise, I do prefer constructive feedback over insults or making =
fun of one another. After all this is an improvement proposal with a specif=
ic purpose aiming to develop a specific thing, not a guy who is just wantin=
g to copy and paste a repository and call it a day.</div><div><br></div><di=
v>Best regards, Andrew<br></div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 12, 2021 at 6:21 PM Lonero Foun=
dation &lt;<a href=3D"mailto:loneroassociation@gmail.com">loneroassociation=
@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>Hi, I also want to emphasize that my main =
point isn&#39;t just to create a BTC hardfork or become another Bitcoin Cas=
h, Gold, or SV. The main point in regards to this BIP actually expands POW =
rather than replaces or creates an alternative. Many of the problems faced =
in regards to security in the future as well as sustainability is something=
 I believe lots of the changes I am proposing can fix. In regards to techno=
logical implementation, once this is assigned draft status I am more than w=
illing to create preprints explaining the cryptography, hashing algorithm i=
mprovements, and consensus that I am working on. This is a highly technolog=
ically complex idea that I am willing to &quot;call my bluff on&quot; and e=
xpand upon. As for it being a draft, I think this is a good starting point =
at least for draft status prior to working on technological implementation.=
</div><div><br></div><div>Best regards, Andrew<br></div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 12, 202=
1 at 5:37 PM email@yancy.lol &lt;email@yancy.lol&gt; wrote:<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">I think Andrew himself is an al=
go.=C2=A0 The crypto training set must not be very good.<br><br>Cheers,<br>=
-Yancy<br><br>On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bi=
tcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>=C2=
=A0<blockquote type=3D"cite" cite=3D"http://CA+YkXXz9aHfZtt-it_8w4ovF=3D-Qa=
Z4_9vwDS0Kz36qhHwVDC5Q@mail.gmail.com"><div dir=3D"auto">Hi, I awkwardly ph=
rased that part, I was referring to key validation in relation to that sect=
ion as well as the hashing related to those keys. I might rephrase it.=C2=
=A0<div dir=3D"auto">=C2=A0</div><div dir=3D"auto">In regards to technical =
merit, the main purpose of the BIP is to get a sense of the idea. Once I ge=
t assigned a BIP draft #, I am willing to follow it up with many preprints =
or publications to go in the references implementation section and start de=
v work before upgrading to final status.</div><div dir=3D"auto">=C2=A0</div=
><div dir=3D"auto">This will take about 400 hours of my time, but is someth=
ing I am personally looking into developing as a hard fork.</div><div dir=
=3D"auto">=C2=A0</div><div dir=3D"auto">Keep in mind this is a draft, so af=
ter it is assigned a number to references I do at the very least hope to de=
scribe various parts of the cryptographic proofs and algorithmic structure =
I am hoping for.</div><div dir=3D"auto">=C2=A0</div><div dir=3D"auto">Best =
regards, Andrew</div></div>=C2=A0<div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty &lt;<a =
href=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">secp236k1 isn&#39;t =
a hashing algo.=C2=A0 =C2=A0your BIP needs about 10 more pages<br>and some =
degree of technical merit.<br><br>i suggest you start here:<br><br><a rel=
=3D"noreferrer noreferrer" href=3D"https://en.bitcoin.it/wiki/Proof_of_burn=
" target=3D"_blank">https://en.bitcoin.it/wiki/Proof_of_burn</a><br><a rel=
=3D"noreferrer noreferrer" href=3D"https://bitcointalk.org/index.php?topic=
=3D225690.0" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D22=
5690.0</a><br><br>proof-of-burn is a nice alternative to proof-of-work.=C2=
=A0 =C2=A0i always<br>suspected that, if designed correctly, it could be a =
proven<br>equivalent.=C2=A0 =C2=A0you could spin up a fork of bitcoin that =
allows aged,<br>burned, coins instead of POW that would probably work just =
fine.<br><br>- erik<br><br>On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundati=
on via bitcoin-dev<br>&lt;<a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt; wrote:<br>&gt;<br>&gt; Hi, I have submitted the BIP Pull Re=
quest here: <a rel=3D"noreferrer noreferrer" href=3D"https://github.com/bit=
coin/bips/pull/1084" target=3D"_blank">https://github.com/bitcoin/bips/pull=
/1084</a><br>&gt;<br>&gt; Hoping to receive a BIP # for the draft prior to =
development/reference implementation.<br>&gt;<br>&gt; Best regards, Andrew<=
br>&gt;<br>&gt; On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation &lt;<a rel=
=3D"noreferrer" href=3D"mailto:loneroassociation@gmail.com" target=3D"_blan=
k">loneroassociation@gmail.com</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; Hi, h=
ere is the list to the BIP proposal on my own repo: <a rel=3D"noreferrer no=
referrer" href=3D"https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main=
/bip-draft.mediawiki" target=3D"_blank">https://github.com/Mentors4EDU/bip-=
amkn-posthyb/blob/main/bip-draft.mediawiki</a><br>&gt;&gt; Can I submit a p=
ull 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.<br>&gt;=
&gt;<br>&gt;&gt; Best regards, Andrew<br>&gt;&gt;<br>&gt;&gt; On Sat, Mar 6=
, 2021, 10:42 AM Lonero Foundation &lt;<a rel=3D"noreferrer" href=3D"mailto=
:loneroassociation@gmail.com" target=3D"_blank">loneroassociation@gmail.com=
</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; [off-list]<br>&gt;&gt;&gt;<=
br>&gt;&gt;&gt; Okay. I will do so and post the link here for discussion be=
fore doing a pull request on BIP&#39;s repo as the best way to handle it.<b=
r>&gt;&gt;&gt;<br>&gt;&gt;&gt; Best regards, Andrew<br>&gt;&gt;&gt;<br>&gt;=
&gt;&gt; On Sat, Mar 6, 2021, 10:21 AM Ricardo Filipe &lt;<a rel=3D"norefer=
rer" href=3D"mailto:ricardojdfilipe@gmail.com" target=3D"_blank">ricardojdf=
ilipe@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; As s=
aid before, you are free to create the BIP in your own repository<br>&gt;&g=
t;&gt;&gt; and bring it to discussion on the mailing list. then you can do =
a PR<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Lonero Foundation via bitcoin-=
dev<br>&gt;&gt;&gt;&gt; &lt;<a rel=3D"noreferrer" href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a>&gt; escreveu no dia s=C3=A1bado,<br>&gt;&gt;&gt;&gt; 6/03/202=
1 =C3=A0(s) 08:58:<br>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&gt; &gt; I know=
 Ethereum had an outlandishly large percentage of nodes running on AWS, I h=
eard the same thing is for Bitcoin but for mining. Had trouble finding the =
article online so take it with a grain of salt. The point though is that bo=
th servers and ASIC specific hardware would still be able to benefit from t=
he cryptography upgrade I am proposing, as this was in relation to the disi=
nfranchisemet point.<br>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&gt; &gt; That=
 said, I think the best way to move forward is to submit a BIP pull request=
 for a draft via GitHub using BIP #2&#39;s draft format and any questions p=
eople have can be answered in the reqeust&#39;s comments. That way people d=
on&#39;t have to get emails everytime there is a reply, but replies still g=
et seen as opposed to offline discussion. Since the instructions say to ema=
il bitcoin-dev before doing a bip draft, I have done that. Since people wan=
t to see the draft beforehand and it isn&#39;t merged manually anyways, I t=
hink it is the easiest way to handle this.<br>&gt;&gt;&gt;&gt; &gt;<br>&gt;=
&gt;&gt;&gt; &gt; I&#39;m also okay w/ continuing the discussion on bitcoin=
-dev but rather 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 established some interest for at least a draft.<br>&gt;&gt;&gt;&gt=
; &gt;<br>&gt;&gt;&gt;&gt; &gt; Does that seem fine?<br>&gt;&gt;&gt;&gt; &g=
t;<br>&gt;&gt;&gt;&gt; &gt; Best regards, Andrew<br>&gt;&gt;&gt;&gt; &gt;<b=
r>&gt;&gt;&gt;&gt; &gt; On Fri, Mar 5, 2021, 7:41 PM Keagan McClelland &lt;=
<a rel=3D"noreferrer" href=3D"mailto:keagan.mcclelland@gmail.com" target=3D=
"_blank">keagan.mcclelland@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; &gt=
;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt; &gt; A large portion of BTC is already m=
ined 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&#39;t disenfranchise currently optimized mining entit=
ies as well.<br>&gt;&gt;&gt;&gt; &gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt; My i=
nstincts tell me that this is an outlandish claim. Do you have supporting e=
vidence for this?<br>&gt;&gt;&gt;&gt; &gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;=
 Keagan<br>&gt;&gt;&gt;&gt; &gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt; On Fri, M=
ar 5, 2021 at 3:22 PM Lonero Foundation via bitcoin-dev &lt;<a rel=3D"noref=
errer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>&gt;&gt;&gt;&gt=
; &gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; Actually I mentioned a proo=
f of space and time hybrid which is much different than staking. Sorry to d=
raw for the confusion as PoC is more commonly used then PoST.<br>&gt;&gt;&g=
t;&gt; &gt;&gt;&gt; There is a way to make PoC cryptographically compatible=
 w/ Proof of Work as it normally stands: <a rel=3D"noreferrer noreferrer" h=
ref=3D"https://en.wikipedia.org/wiki/Proof_of_space" target=3D"_blank">http=
s://en.wikipedia.org/wiki/Proof_of_space</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&g=
t; It has rarely been done though given the technological complexity of bei=
ng both CPU compatible and memory-hard compatible. There are lots of benefi=
ts outside of the realm of efficiency, and I already looked into numerous f=
ault tolerant designs as well and what others in the cryptography community=
 attempted to propose. The actual argument you have only against this is th=
e Proof of Memory fallacy, which is only partially true. Given how the curr=
ent 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 w=
orking towards a hybrid mechanism that fixes that. BTW: The way Bitcoin cur=
rently stands in its cryptography still needs updating regardless. If someo=
ne figures out NP hardness or the halting problem the traditional rule of m=
illions of years to break all of Bitcoin&#39;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&#39;m a=
iming to provide which includes a polynomial time algorithm in the cryptogr=
aphy. 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 so=
ft fork or minor upgrade to its chain.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>=
&gt;&gt;&gt;&gt; &gt;&gt;&gt; In regards to the argument, &quot;As a separa=
te issue, proposing a hard fork in the hashing algorithm will invalidate th=
e enormous amount of capital expenditure by mining entities and disincentiv=
ize future capital expenditure into mining hardware that may compute these =
more &quot;useful&quot; proofs of work.&quot;<br>&gt;&gt;&gt;&gt; &gt;&gt;&=
gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; A large portion of BTC is already mine=
d 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&#39;t disenfranchise currently optimized mining entities=
 as well.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;=
 There are other reasons why a cryptography upgrade like this is beneficial=
. Theoretically one can argue BItcoin isn&#39;t fully decentralized. It is =
few unsolved mathematical proofs away from being entirely broken. My goal o=
utside of efficiency is to build cryptography in a way that prevents such a=
n event from happening in the future, if it was to ever happen. I have vari=
ous research in regards to this area and work alot with distributed computi=
ng. I believe if the BTC community likes such a proposal, I would single ha=
ndedly be able to build the cryptographic proof myself (though would like a=
s many open source contributors as I can get :)<br>&gt;&gt;&gt;&gt; &gt;&gt=
;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; 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.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"nore=
ferrer noreferrer" href=3D"https://hackernoon.com/ethereum-you-are-a-centra=
lized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl" target=3D"_bl=
ank">https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-s=
top-telling-us-that-you-arent-pi3s3yjl</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;=
<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; Best regards,=C2=A0 Andrew<br>&gt;&gt;&gt=
;&gt; &gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; On Fri, Mar 5, 2021 at =
4:11 PM Keagan McClelland &lt;<a rel=3D"noreferrer" href=3D"mailto:keagan.m=
cclelland@gmail.com" target=3D"_blank">keagan.mcclelland@gmail.com</a>&gt; =
wrote:<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &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 same. If the =
work was useful it provides an avenue for actors to have nothing at stake w=
hen submitting a proof of work, since the marginal cost of block constructi=
on will be lessened by the fact that the work was useful in a different con=
text and therefore would have been done anyway. This actually degrades the =
security of the network in the process.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt=
;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; As a separate issue, proposing a har=
d fork in the hashing algorithm will invalidate the enormous amount of capi=
tal expenditure by mining entities and disincentivize future capital expend=
iture into mining hardware that may compute these more &quot;useful&quot; p=
roofs of work. This is because any change in the POW algorithm will be cons=
idered unstable and subject to change in the future. This puts the entire n=
etwork at even more risk meaning that no entity is tying their own interest=
s to that of the bitcoin network at large. It also puts the developers in a=
 position where they can be bribed by entities with a vested interest in de=
ciding what the new &quot;useful&quot; proof of work should be.<br>&gt;&gt;=
&gt;&gt; &gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; All of these=
 things make the Bitcoin network worse off.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt=
;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; Keagan<br>&gt;&gt;&gt;&gt; &gt;&=
gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; On Fri, Mar 5, 2021 at 1:4=
8 PM Lonero Foundation via bitcoin-dev &lt;<a rel=3D"noreferrer" href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt=
;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Also in regards to my other =
email, I forgot to iterate that my cryptography proposal helps behind the e=
fficiency category but also tackles problems such as NP-Completeness or Hal=
ting which is something the BTC network could be vulnerable to in the futur=
e. For sake of simplicity, I do want to do this BIP because it tackles lots=
 of the issues in regards to this manner and can provide useful insight to =
the community. If things such as bigger block height have been proposed as =
hard forks, I feel at the very least an upgrade regarding the hashing algor=
ithm and cryptography does at least warrant some discussion. Anyways I hope=
 I can send you my BIP, just let me know on the preferred format?<br>&gt;&g=
t;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Be=
st regards, Andrew<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;=
&gt; &gt;&gt;&gt;&gt;&gt; On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation &=
lt;<a rel=3D"noreferrer" href=3D"mailto:loneroassociation@gmail.com" target=
=3D"_blank">loneroassociation@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; =
&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Hi, t=
his 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 yo=
ur hashing for validation. I do understand the arbitrariness of it, but do =
want to still propose a document. Do I use the Media Wiki format on GitHub =
and just attach it as my proposal?<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;=
&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Best regards, Andrew<br>&=
gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&g=
t;&gt;&gt; On Fri, Mar 5, 2021, 10:07 AM Devrandom &lt;<a rel=3D"noreferrer=
" href=3D"mailto:c1.devrandom@niftybox.net" target=3D"_blank">c1.devrandom@=
niftybox.net</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt=
;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi Ryan and Andrew,<br>&=
gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&g=
t;&gt;&gt;&gt;&gt; On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-de=
v &lt;<a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;=
 &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&=
gt;&gt;&gt;=C2=A0 =C2=A0<a rel=3D"noreferrer noreferrer" href=3D"https://ww=
w.truthcoin.info/blog/pow-cheapest/" target=3D"_blank">https://www.truthcoi=
n.info/blog/pow-cheapest/</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&=
gt;&gt;=C2=A0 =C2=A0 =C2=A0&quot;Nothing is Cheaper than Proof of Work&quot=
;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 =C2=A0o=
n | 04 Aug 2015<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt=
;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;=
&gt;&gt;&gt;&gt; Just to belabor this a bit, the paper demonstrates that th=
e mining market will tend to expend resources equivalent to miner reward.=
=C2=A0 It does not prove that mining work has to expend *energy* as a prima=
ry cost.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&g=
t; &gt;&gt;&gt;&gt;&gt;&gt;&gt; Some might argue that energy expenditure ha=
s 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 moot.<br>&gt;&gt;&gt;&gt; &g=
t;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; _______=
________________________________________<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&g=
t;&gt; bitcoin-dev mailing list<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; <a=
 rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>&gt;&gt;&gt;&=
gt; &gt;&gt;&gt;&gt;&gt; <a rel=3D"noreferrer noreferrer" href=3D"https://l=
ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">ht=
tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>&gt;&gt=
;&gt;&gt; &gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; ___________________=
____________________________<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; bitcoin-dev m=
ailing list<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer" href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"n=
oreferrer noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/lis=
tinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>&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 rel=3D"noreferrer" h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a><br>&gt;&gt;&gt;&gt; &gt; <a rel=3D"no=
referrer noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/list=
info/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev</a><br>&gt;<br>&gt; _______________________________=
________________<br>&gt; bitcoin-dev mailing list<br>&gt; <a rel=3D"norefer=
rer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a><br>&gt; <a rel=3D"noreferrer no=
referrer" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo=
/bitcoin-dev</a></blockquote></div></blockquote><br><br><br>=C2=A0
</blockquote></div>
</blockquote></div>

--000000000000a5d83c05bd5f4e9f--