path: root/42/851a7d965c33eb59f35b03275a4974db3ab790

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 B0C33C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 15:02:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 88D954AC55
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 15:02:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001,
 T_KAM_HTML_FONT_INVALID=0.01] 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 WGxR_08VEYsv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 15:02:18 +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 BD78C4EC18
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 15:02:17 +0000 (UTC)
Received: by mail-yb1-xb35.google.com with SMTP id h82so28491555ybc.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 07:02:17 -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=hcBEiK5BT6uwq787bPfzTCYpHaLxLWoMBfkCR5OTfnk=;
 b=QVpDB9WvdtrG1xSJvR2iPUS5/3DDhpTx4Yrf+CLQ6thaVEdbkPIoM2meWVMfDwB0X7
 yohucjb/CNGyxXtW9qCFawbKSYuQ3E6jW5ZBLn8oBbTAVKNk6iqNW+S+e4MOZ0xmSQM+
 GGMbQxjP5LaetW7u9ZoK5v2CBCE2/ZWLr3e5VBYwE021tKKGfh6c6qCY6Sun/PBBozS/
 yXNeXw5cgx8l4vVHqPIh3MTMoLCkjqHMcW3IAr1I9f21za2nrK8vqaYSLagMsSwjpzHU
 lTYxh/7hN/zX+V8H3bnPV4fN/zl2TyMmuTgXOnot32F2XUiadK7Xhr9xNd02cIqr5E21
 nELw==
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=hcBEiK5BT6uwq787bPfzTCYpHaLxLWoMBfkCR5OTfnk=;
 b=CVRG9ZhmVmc3BzfuVuEXkOpiyxuxALjK+IJNzXGD5K1gjomj2O/bxanMaSG70nxbNU
 Qx+lOj3J9XKpRchH61T+yEo5HOUKSCueQuCNt34rG2E2dr6tLMDaWzAatysywh5oQrns
 YHZq+LNz63HCECbdUttvJ+uW2rBnWc3bW8WimbijEqoEIwo5uq+yP3dMZOeWmNo+NOEX
 1ISluiteMWGnObnauzhHGfiExhGxu6Vpu0rOEA4ghBoNmPPq2xE7sGm43MEMvd660iAJ
 GJria6sBktaH/YgTF0g86ldXfGWZIQgjs6XeNFy+dNsl7+lYLCYljXPsF/CQdLDLWF6l
 m/Rw==
X-Gm-Message-State: AOAM531OoPt1LRB7PSzxD1W2XBvbgCuNXbrODZ6rIEaUfGnniAAWVAPH
 tzVhrZf/Hty8AFYXtYDxMvyHSi22PyelU1srSrM=
X-Google-Smtp-Source: ABdhPJysH1McyVhgBw3OTNoNUwwC5qq7YwyawXdEmuQ5uGjHXwqHjNj8x2HL0r/UngZRenDe2bYUzUdA8XsKJGl7Gqc=
X-Received: by 2002:a5b:591:: with SMTP id l17mr26191754ybp.60.1615647736601; 
 Sat, 13 Mar 2021 07:02:16 -0800 (PST)
MIME-Version: 1.0
References: <CA+YkXXw5uh4yfvqDiBBEXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com>
 <1802-604c7400-4d1-7b635e80@91248813>
In-Reply-To: <1802-604c7400-4d1-7b635e80@91248813>
From: Lonero Foundation <loneroassociation@gmail.com>
Date: Sat, 13 Mar 2021 10:02:05 -0500
Message-ID: <CA+YkXXzPt8vf=bfpW+NBqH_G7sTiyFcGSZa+j31Fx_O5ir93Cw@mail.gmail.com>
To: email@yancy.lol
Content-Type: multipart/alternative; boundary="0000000000006c1e8705bd6c4d79"
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: Sat, 13 Mar 2021 15:02:20 -0000

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

Hi, I know the differences between the cryptographic hashing algorithm and
key validation. I know hashing is for SHA, but was referring to asymmetric
cryptography in regards to the key validation. I should have used a
different term though instead of, "In regards to cryptographic hashing,", I
should have stated in regards to cryptographic key validation. There are a
few other dubious clarifications or minor edits I should make in order to
not draw confusion. I will do a repo update today. Honest mistake, but
enough with the sarcasm.

Best regards, Andrew

On Sat, Mar 13, 2021, 3:13 AM email@yancy.lol <email@yancy.lol> wrote:

> My email was not intended as an insult.  Your proposal seemed a bit like
> gibberish and made some obvious mistakes as pointed out before (such as
> conflating secp256k1 with sha256), and so I was genuinely curious if you
> were a bot spamming the list.
>
>
> Maybe a more interesting topic is, can GPT3 be used to generate a BIP?
> How long before our AI overlord produces improvements to Bitcoin?  At wha=
t
> point will the AI have more than 51% of commit frequency?  Will we have
> lost the war to our new centralized overlord?
>
> Cheers,
> -Yancy
>
>
> On Saturday, March 13, 2021 00:31 CET, Lonero Foundation <
> loneroassociation@gmail.com> wrote:
>
>
> Also, I already stated I was referring to signature validation
> cryptography in that aspect:
> https://wizardforcel.gitbooks.io/practical-cryptography-for-developers-bo=
ok/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 constructiv=
e
> 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
>> BTC 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 chan=
ges
>> 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 consens=
us
>> 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 draf=
t,
>> 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 reference=
s
>>> implementation section and start dev work before upgrading to final sta=
tus.
>>>
>>> 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/reference 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.me=
diawiki
>>>> >> Can I submit a pull request on the BIPs repo for this to go into
>>>> draft mode? Also, I think this provides at least some more insight on =
what
>>>> I want to work on.
>>>> >>
>>>> >> Best regards, Andrew
>>>> >>
>>>> >> On Sat, Mar 6, 2021, 10:42 AM Lonero Foundation <
>>>> loneroassociation@gmail.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=A1ba=
do,
>>>> >>>> 6/03/2021 =C3=A0(s) 08:58:
>>>> >>>> >
>>>> >>>> > I know Ethereum had an outlandishly large percentage of nodes
>>>> running on AWS, I heard the same thing is for Bitcoin but for mining. =
Had
>>>> trouble finding the article online so take it with a grain of salt. Th=
e
>>>> point though is that both servers and ASIC specific hardware would sti=
ll be
>>>> able to benefit from the cryptography upgrade I am proposing, as this =
was
>>>> in relation to the disinfranchisemet point.
>>>> >>>> >
>>>> >>>> > That said, I think the best way to move forward is to submit a
>>>> BIP pull request for a draft via GitHub using BIP #2's draft format an=
d any
>>>> questions people have can be answered in the reqeust's comments. That =
way
>>>> people don't have to get emails everytime there is a reply, but replie=
s
>>>> still get seen as opposed to offline discussion. Since the instruction=
s 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 accident=
ally
>>>> 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 benef=
it
>>>> from a hybrid proof, and the fact that it is hybrid in that manner wou=
ldn't
>>>> disenfranchise currently optimized mining entities as well.
>>>> >>>> >>
>>>> >>>> >> My instincts tell me that this is an outlandish claim. Do you
>>>> have supporting evidence for this?
>>>> >>>> >>
>>>> >>>> >> Keagan
>>>> >>>> >>
>>>> >>>> >> On Fri, Mar 5, 2021 at 3:22 PM Lonero Foundation via
>>>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> >>>> >>>
>>>> >>>> >>> Actually I mentioned a proof of space and time hybrid which i=
s
>>>> 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. 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 h=
ave
>>>> only against this is the Proof of Memory fallacy, which is only partia=
lly
>>>> true. Given how the current hashing algorithm works, hard memory alloc=
ation
>>>> 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 tha=
t.
>>>> 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 Bitc=
oin's
>>>> cryptography now comes down to minutes. Bitcoin is going to have to
>>>> eventually radically upgrade their cryptography and hashing algo in th=
e
>>>> future regardless. I want to integrate some form of NP complexity in
>>>> regards to the hybrid cryptography I'm aiming to provide which include=
s a
>>>> polynomial time algorithm in the cryptography. More than likely the fi=
rst
>>>> version of my BTC hard fork will be coded in a way where integrating s=
uch
>>>> 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 capit=
al
>>>> 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 benef=
it
>>>> from a hybrid proof, and the fact that it is hybrid in that manner wou=
ldn't
>>>> disenfranchise currently optimized mining entities as well.
>>>> >>>> >>>
>>>> >>>> >>> There are other reasons why a cryptography upgrade like this
>>>> is beneficial. Theoretically one can argue BItcoin isn't fully
>>>> decentralized. It is few unsolved mathematical proofs away from being
>>>> entirely broken. My goal outside of efficiency is to build cryptograph=
y in
>>>> a way that prevents such an event from happening in the future, if it =
was
>>>> to ever happen. I have various research in regards to this area and wo=
rk
>>>> alot with distributed computing. I believe if the BTC community likes =
such
>>>> a proposal, I would single handedly be able to build the cryptographic
>>>> proof myself (though would like as many open source contributors as I =
can
>>>> get :)
>>>> >>>> >>>
>>>> >>>> >>> Anyways just something to consider. We are in the same space
>>>> in regards to what warrants a shitcoin or the whole argument against
>>>> staking.
>>>> >>>> >>>
>>>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-s=
top-telling-us-that-you-arent-pi3s3yjl
>>>> >>>> >>>
>>>> >>>> >>> Best regards,  Andrew
>>>> >>>> >>>
>>>> >>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <
>>>> keagan.mcclelland@gmail.com> wrote:
>>>> >>>> >>>>
>>>> >>>> >>>> It is important to understand that it is critical for the
>>>> work to be "useless" in order for the security model to be the same. I=
f the
>>>> work was useful it provides an avenue for actors to have nothing at st=
ake
>>>> when submitting a proof of work, since the marginal cost of block
>>>> construction will be lessened by the fact that the work was useful in =
a
>>>> different context and therefore would have been done anyway. This actu=
ally
>>>> degrades the security of the network in the process.
>>>> >>>> >>>>
>>>> >>>> >>>> As a separate issue, proposing a hard fork in the hashing
>>>> algorithm will invalidate the enormous amount of capital expenditure b=
y
>>>> mining entities and disincentivize future capital expenditure into min=
ing
>>>> hardware that may compute these more "useful" proofs of work. This is
>>>> because any change in the POW algorithm will be considered unstable an=
d
>>>> subject to change in the future. This puts the entire network at even =
more
>>>> risk meaning that no entity is tying their own interests to that of th=
e
>>>> bitcoin network at large. It also puts the developers in a position wh=
ere
>>>> 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 simplici=
ty, I
>>>> do want to do this BIP because it tackles lots of the issues in regard=
s to
>>>> this manner and can provide useful insight to the community. If things=
 such
>>>> as bigger block height have been proposed as hard forks, I feel at 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, j=
ust
>>>> 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 laye=
r to
>>>> get the most out of your hashing for validation. I do understand the
>>>> arbitrariness of it, but do want to still propose a document. Do I use=
 the
>>>> Media Wiki format on GitHub and just attach it as my proposal?
>>>> >>>> >>>>>>
>>>> >>>> >>>>>> Best regards, Andrew
>>>> >>>> >>>>>>
>>>> >>>> >>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <
>>>> c1.devrandom@niftybox.net> wrote:
>>>> >>>> >>>>>>>
>>>> >>>> >>>>>>> Hi Ryan and Andrew,
>>>> >>>> >>>>>>>
>>>> >>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev=
 <
>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> >>>> >>>>>>>>
>>>> >>>> >>>>>>>>
>>>> >>>> >>>>>>>>   https://www.truthcoin.info/blog/pow-cheapest/
>>>> >>>> >>>>>>>>     "Nothing is Cheaper than Proof of Work"
>>>> >>>> >>>>>>>>     on | 04 Aug 2015
>>>> >>>> >>>>>>>>
>>>> >>>> >>>>>>>
>>>> >>>> >>>>>>> Just to belabor this a bit, the paper demonstrates that
>>>> the mining market will tend to expend resources equivalent to miner
>>>> reward.  It does not prove that mining work has to expend *energy* as =
a
>>>> primary cost.
>>>> >>>> >>>>>>>
>>>> >>>> >>>>>>> Some might argue that energy expenditure has negative
>>>> externalities and that we should move to other resources.  I would arg=
ue
>>>> that the negative externalities will go away soon because of the move =
to
>>>> renewables, so the point is likely moot.
>>>> >>>> >>>>>>>
>>>> >>>> >>>>> _______________________________________________
>>>> >>>> >>>>> bitcoin-dev mailing list
>>>> >>>> >>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> >>>> >>>>>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> >>>> >>>
>>>> >>>> >>> _______________________________________________
>>>> >>>> >>> bitcoin-dev mailing list
>>>> >>>> >>> bitcoin-dev@lists.linuxfoundation.org
>>>> >>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de=
v
>>>> >>>> >
>>>> >>>> > _______________________________________________
>>>> >>>> > 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>

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

<div dir=3D"auto">Hi, I know the differences between the cryptographic hash=
ing algorithm and key validation. I know hashing is for SHA, but was referr=
ing to=C2=A0<span>asymmetric cryptography in regards to the key validation.=
 I should have used a different term though instead of, &quot;In regards to=
 cryptographic hashing,&quot;, I should have stated in regards to cryptogra=
phic key validation. There are a few other dubious clarifications or minor =
edits I should make in order to not draw confusion. I will do a repo update=
 today. Honest mistake, but enough with the sarcasm.</span><div dir=3D"auto=
"><span><br></span></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 Sat=
, Mar 13, 2021, 3:13 AM email@yancy.lol &lt;email@yancy.lol&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr" style=3D"line-height:1.3=
8;margin-top:0pt;margin-bottom:0pt" id=3D"m_-7605373105595509035m_815842019=
9876589271m_-1581779554600417290m_-1741129009180998294m_3490105251412115872=
m_-7757793637796267019m_-5697419812760722977docs-internal-guid-4056a8b1-7ff=
f-9296-3427-4d2e04c785c7"><span style=3D"font-size:11pt;font-family:Arial;b=
ackground-color:transparent;font-weight:400;font-style:normal;font-variant:=
normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">M=
y email was not intended as an insult.=C2=A0 Your proposal seemed a bit lik=
e gibberish and made some obvious mistakes as pointed out before (such as c=
onflating secp256k1 with sha256), and so I was genuinely curious if you wer=
e a bot spamming the list.</span></p>=C2=A0<p dir=3D"ltr" style=3D"line-hei=
ght:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;fo=
nt-family:Arial;background-color:transparent;font-weight:400;font-style:nor=
mal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-=
space:pre-wrap">Maybe a more interesting topic is, can GPT3 be used to gene=
rate a BIP?=C2=A0 How long before our AI overlord produces improvements to =
Bitcoin?=C2=A0 At what point will the AI have more than 51% of commit frequ=
ency?=C2=A0 Will we have lost the war to our new centralized overlord?</spa=
n></p><br>Cheers,<br>-Yancy<br><br><br>On Saturday, March 13, 2021 00:31 CE=
T, Lonero Foundation &lt;<a href=3D"mailto:loneroassociation@gmail.com" rel=
=3D"noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noref=
errer" target=3D"_blank">loneroassociation@gmail.com</a>&gt; wrote:<br>=C2=
=A0<blockquote type=3D"cite" cite=3D"http://CA+YkXXw5uh4yfvqDiBBEXcq188PEGk=
u-NFFAq7uNuAFTG3ooTQ@mail.gmail.com"><div dir=3D"ltr"><div>Also, I already =
stated I was referring to signature validation cryptography in that aspect:=
 <a href=3D"https://wizardforcel.gitbooks.io/practical-cryptography-for-dev=
elopers-book/content/digital-signatures/ecdsa-sign-verify-examples.html" re=
l=3D"noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer nore=
ferrer" target=3D"_blank">https://wizardforcel.gitbooks.io/practical-crypto=
graphy-for-developers-book/content/digital-signatures/ecdsa-sign-verify-exa=
mples.html</a></div><div>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.</div><div>That said to those who disagree with the p=
remise, 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.</div><div>=C2=A0</div><div>Best r=
egards, Andrew</div></div>=C2=A0<div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation &lt=
;<a href=3D"mailto:loneroassociation@gmail.com" rel=3D"noreferrer noreferre=
r noreferrer noreferrer noreferrer noreferrer noreferrer" target=3D"_blank"=
>loneroassociation@gmail.com</a>&gt; wrote:</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 anothe=
r 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 pr=
oblems 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 rega=
rds to technological implementation, once this is assigned draft status I a=
m more than willing to create preprints explaining the cryptography, hashin=
g algorithm improvements, and consensus that I am working on. This is a hig=
hly technologically complex idea that I am willing to &quot;call my bluff o=
n&quot; and expand upon. As for it being a draft, I think this is a good st=
arting point at least for draft status prior to working on technological im=
plementation.</div><div>=C2=A0</div><div>Best regards, Andrew</div></div>=
=C2=A0<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On F=
ri, Mar 12, 2021 at 5:37 PM email@yancy.lol &lt;email@yancy.lol&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">I think Andrew himse=
lf is an algo.=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 Founda=
tion via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer norefe=
rrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt; wrote:<br>=C2=A0<blockquote type=3D"cite" cite=3D"http://CA+YkXXz9aHf=
Ztt-it_8w4ovF=3D-QaZ4_9vwDS0Kz36qhHwVDC5Q@mail.gmail.com"><div dir=3D"auto"=
>Hi, I awkwardly phrased that part, I was referring to key validation in re=
lation to that section as well as the hashing related to those keys. I migh=
t rephrase it.=C2=A0<div dir=3D"auto">=C2=A0</div><div dir=3D"auto">In rega=
rds to technical merit, the main purpose of the BIP is to get a sense of th=
e idea. Once I get assigned a BIP draft #, I am willing to follow it up wit=
h many preprints or publications to go in the references implementation sec=
tion and start dev 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 ti=
me, but is something 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 after it is assigned a number to references I do at the very l=
east hope to describe various parts of the cryptographic proofs and algorit=
hmic 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 A=
ronesty &lt;<a href=3D"mailto:erik@q32.com" rel=3D"noreferrer noreferrer no=
referrer noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">eri=
k@q32.com</a>&gt; wrote:</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">secp236k1 isn&#39;t a hashing algo.=C2=A0 =C2=A0your BIP needs about 1=
0 more pages<br>and some degree of technical merit.<br><br>i suggest you st=
art here:<br><br><a rel=3D"noreferrer noreferrer noreferrer noreferrer nore=
ferrer noreferrer noreferrer noreferrer noreferrer" href=3D"https://en.bitc=
oin.it/wiki/Proof_of_burn" target=3D"_blank">https://en.bitcoin.it/wiki/Pro=
of_of_burn</a><br><a rel=3D"noreferrer noreferrer noreferrer noreferrer nor=
eferrer noreferrer noreferrer noreferrer noreferrer" href=3D"https://bitcoi=
ntalk.org/index.php?topic=3D225690.0" target=3D"_blank">https://bitcointalk=
.org/index.php?topic=3D225690.0</a><br><br>proof-of-burn is a nice alternat=
ive to proof-of-work.=C2=A0 =C2=A0i always<br>suspected that, if designed c=
orrectly, 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 w=
ould probably work just fine.<br><br>- erik<br><br>On Thu, Mar 11, 2021 at =
11:56 AM Lonero Foundation via bitcoin-dev<br>&lt;<a rel=3D"noreferrer nore=
ferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>&gt;<br>&gt; Hi, I have=
 submitted the BIP Pull Request here: <a rel=3D"noreferrer noreferrer noref=
errer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" hr=
ef=3D"https://github.com/bitcoin/bips/pull/1084" target=3D"_blank">https://=
github.com/bitcoin/bips/pull/1084</a><br>&gt;<br>&gt; Hoping to receive a B=
IP # for the draft prior to development/reference implementation.<br>&gt;<b=
r>&gt; Best regards, Andrew<br>&gt;<br>&gt; On Mon, Mar 8, 2021, 6:40 PM Lo=
nero Foundation &lt;<a rel=3D"noreferrer noreferrer noreferrer noreferrer n=
oreferrer noreferrer noreferrer noreferrer" href=3D"mailto:loneroassociatio=
n@gmail.com" target=3D"_blank">loneroassociation@gmail.com</a>&gt; wrote:<b=
r>&gt;&gt;<br>&gt;&gt; Hi, here is the list to the BIP proposal on my own r=
epo: <a rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer noref=
errer noreferrer noreferrer noreferrer" href=3D"https://github.com/Mentors4=
EDU/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 pull request on the BIPs repo for this to go i=
nto draft mode? Also, I think this provides at least some more insight on w=
hat 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 noreferrer noreferrer noreferrer noreferrer noreferrer noref=
errer noreferrer" href=3D"mailto:loneroassociation@gmail.com" target=3D"_bl=
ank">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 before doing a pull request on BIP&#39;s repo=
 as the best way to handle it.<br>&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 Rica=
rdo Filipe &lt;<a rel=3D"noreferrer noreferrer noreferrer noreferrer norefe=
rrer noreferrer noreferrer noreferrer" href=3D"mailto:ricardojdfilipe@gmail=
.com" target=3D"_blank">ricardojdfilipe@gmail.com</a>&gt; wrote:<br>&gt;&gt=
;&gt;&gt;<br>&gt;&gt;&gt;&gt; As said before, you are free to create the BI=
P in your own repository<br>&gt;&gt;&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"nor=
eferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer n=
oreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; escreveu no dia s=C3=
=A1bado,<br>&gt;&gt;&gt;&gt; 6/03/2021 =C3=A0(s) 08:58:<br>&gt;&gt;&gt;&gt;=
 &gt;<br>&gt;&gt;&gt;&gt; &gt; I know Ethereum had an outlandishly large pe=
rcentage of nodes running on AWS, I heard the same thing is for Bitcoin but=
 for mining. Had trouble finding the article online so take it with a grain=
 of salt. The point though is that both servers and ASIC specific hardware =
would still be able to benefit from the cryptography upgrade I am proposing=
, as this was in relation to the disinfranchisemet point.<br>&gt;&gt;&gt;&g=
t; &gt;<br>&gt;&gt;&gt;&gt; &gt; That said, I think the best way to move fo=
rward is to submit a BIP pull request for a draft via GitHub using BIP #2&#=
39;s draft format and any questions people have can be answered in the reqe=
ust&#39;s comments. That way people don&#39;t have to get emails everytime =
there is a reply, but replies still get seen as opposed to offline discussi=
on. Since the instructions say to email bitcoin-dev before doing a bip draf=
t, I have done that. Since people want to see the draft beforehand and it i=
sn&#39;t merged manually anyways, I think it is the easiest way to handle t=
his.<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 g=
it 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 t=
hat seem fine?<br>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&gt; &gt; Best regar=
ds, Andrew<br>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&gt; &gt; On Fri, Mar 5,=
 2021, 7:41 PM Keagan McClelland &lt;<a rel=3D"noreferrer noreferrer norefe=
rrer noreferrer noreferrer noreferrer noreferrer 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 mined through AWS servers and non-asi=
c 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 disenfra=
nchise currently optimized mining entities as well.<br>&gt;&gt;&gt;&gt; &gt=
;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt; My instincts tell me that this is an out=
landish claim. Do you have supporting evidence 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, Mar 5, 2021 at 3:22 PM Lonero Foundat=
ion via bitcoin-dev &lt;<a rel=3D"noreferrer noreferrer noreferrer noreferr=
er noreferrer noreferrer noreferrer noreferrer" href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;=
 &gt;&gt;&gt; Actually I mentioned a proof of space and time hybrid which i=
s much different than staking. Sorry to draw for the confusion as PoC is mo=
re commonly used then PoST.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; There is a way=
 to make PoC cryptographically compatible w/ Proof of Work as it normally s=
tands: <a rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer nor=
eferrer noreferrer noreferrer noreferrer" href=3D"https://en.wikipedia.org/=
wiki/Proof_of_space" target=3D"_blank">https://en.wikipedia.org/wiki/Proof_=
of_space</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; It has rarely been done thoug=
h given the technological complexity of being both CPU compatible and memor=
y-hard compatible. There are lots of benefits outside of the realm of effic=
iency, and I already looked into numerous fault tolerant designs as well an=
d what others in the cryptography community attempted to propose. The actua=
l argument you have only against this is the Proof of Memory fallacy, which=
 is only partially true. Given how the current hashing algorithm works, har=
d memory allocation wouldn&#39;t be of much benefit given it is more optimi=
zed for CPU/ASIC specific mining. I&#39;m working towards a hybrid mechanis=
m that fixes that. BTW: The way Bitcoin currently stands in its cryptograph=
y still needs updating regardless. If someone figures out NP hardness or th=
e halting problem the traditional 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 upgrade their cryptography and hashing algo in=
 the future regardless. I want to integrate some form of NP complexity in r=
egards to the hybrid cryptography 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 will be coded in a way where integrating such =
complexity in the future only requires a soft 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 separate issue, proposing a hard fork =
in the hashing algorithm will invalidate the enormous amount of capital exp=
enditure by mining entities and disincentivize future capital expenditure i=
nto mining hardware that may compute these more &quot;useful&quot; proofs o=
f 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 mined through AWS servers and non-as=
ic 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&#39;t disenfr=
anchise currently optimized mining entities as well.<br>&gt;&gt;&gt;&gt; &g=
t;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; There are other reasons why a c=
ryptography upgrade like this is beneficial. Theoretically one can argue BI=
tcoin isn&#39;t fully decentralized. It is few unsolved mathematical proofs=
 away from being entirely broken. My goal outside of efficiency is to build=
 cryptography in a way that prevents such an event from happening in the fu=
ture, 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 communi=
ty likes such a proposal, I would single handedly be able to build the cryp=
tographic proof myself (though would like as many open source contributors =
as I can get :)<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&g=
t;&gt; Anyways just something to consider. We are in the same space in rega=
rds to what warrants a shitcoin or the whole argument against staking.<br>&=
gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer noreferrer noreferrer nor=
eferrer noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D"htt=
ps://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-tell=
ing-us-that-you-arent-pi3s3yjl" target=3D"_blank">https://hackernoon.com/et=
hereum-you-are-a-centralized-cryptocurrency-stop-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 noreferrer noreferrer noreferrer noreferrer noreferrer=
 noreferrer 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;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; It is important to un=
derstand that it is critical for the work to be &quot;useless&quot; in orde=
r for the security model to be the same. If the work was useful it provides=
 an avenue for actors to have nothing at stake when submitting a proof of w=
ork, since the marginal cost of block construction will be lessened by the =
fact that the work was useful in a different context and therefore would ha=
ve 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 hard fork in the hashing algor=
ithm will invalidate the enormous amount of capital expenditure by mining e=
ntities and disincentivize future capital expenditure into mining hardware =
that may compute these more &quot;useful&quot; proofs of work. This is beca=
use any change in the POW algorithm will be considered unstable and subject=
 to change in the future. This puts the entire network at even more risk me=
aning that no entity is tying their own interests to that of the bitcoin ne=
twork at large. It also puts the developers in a position where they can be=
 bribed by entities with a vested interest in deciding what the new &quot;u=
seful&quot; proof of work should be.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;<b=
r>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; All of these things make the Bitcoin ne=
twork 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:48 PM Lonero Foundation via =
bitcoin-dev &lt;<a rel=3D"noreferrer noreferrer noreferrer noreferrer noref=
errer noreferrer noreferrer noreferrer" href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.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 iterat=
e that my cryptography proposal helps behind the efficiency category but al=
so tackles problems such as NP-Completeness or Halting which is something t=
he BTC network could be vulnerable to in the future. For sake of simplicity=
, I do want to do this BIP because it tackles lots of the issues in regards=
 to this manner and can provide useful insight to the community. If things =
such as bigger block height have been proposed as hard forks, I feel at the=
 very least an upgrade regarding the hashing algorithm and cryptography doe=
s at least warrant some discussion. Anyways I hope I can send you my BIP, j=
ust let me know on the preferred format?<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&g=
t;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Best 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 n=
oreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer=
" href=3D"mailto:loneroassociation@gmail.com" target=3D"_blank">loneroassoc=
iation@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, this 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 validati=
on. 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 m=
y 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;&gt;&gt;&gt; On Fri, Mar =
5, 2021, 10:07 AM Devrandom &lt;<a rel=3D"noreferrer noreferrer noreferrer =
noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D"mailto:c1.d=
evrandom@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;&gt;&gt;&gt;&gt;&gt; On=
 Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev &lt;<a rel=3D"noref=
errer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer nor=
eferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>&gt;&gt;&gt;&=
gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&g=
t;&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 noreferrer noreferrer noreferrer nore=
ferrer noreferrer noreferrer noreferrer" href=3D"https://www.truthcoin.info=
/blog/pow-cheapest/" target=3D"_blank">https://www.truthcoin.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=A0on | 04 Aug 201=
5<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;&g=
t; Just to belabor this a bit, the paper demonstrates that the mining marke=
t will tend to expend resources equivalent to miner reward.=C2=A0 It does n=
ot prove that mining work has to expend *energy* as a primary cost.<br>&gt;=
&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&=
gt;&gt;&gt;&gt; Some might argue that energy expenditure has negative exter=
nalities and that we should move to other resources.=C2=A0 I would argue th=
at the negative externalities will go away soon because of the move to rene=
wables, so the point is likely moot.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&g=
t;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; _______________________=
________________________<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; bitcoin-d=
ev mailing list<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; <a rel=3D"noreferr=
er noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer norefe=
rrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&g=
t;&gt;&gt; <a rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer=
 noreferrer noreferrer noreferrer noreferrer" href=3D"https://lists.linuxfo=
undation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>&gt;&gt;&gt;&gt; &g=
t;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; _______________________________=
________________<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; bitcoin-dev mailing list<=
br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer noreferrer noreferrer=
 noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer =
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferre=
r noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/list=
info/bitcoin-dev</a><br>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&gt; &gt; ____=
___________________________________________<br>&gt;&gt;&gt;&gt; &gt; bitcoi=
n-dev mailing list<br>&gt;&gt;&gt;&gt; &gt; <a rel=3D"noreferrer noreferrer=
 noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a><br>&gt;&gt;&gt;&gt; &gt; <a rel=3D"noreferr=
er noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer norefe=
rrer noreferrer" href=3D"https://lists.linuxfoundation.org/mailman/listinfo=
/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/l=
istinfo/bitcoin-dev</a><br>&gt;<br>&gt; ___________________________________=
____________<br>&gt; bitcoin-dev mailing list<br>&gt; <a rel=3D"noreferrer =
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferre=
r" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>&gt; <a rel=3D"noreferrer nore=
ferrer noreferrer noreferrer noreferrer noreferrer noreferrer 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</blockqu=
ote></div></blockquote></div></blockquote><br><br><br>=C2=A0
</blockquote></div>

--0000000000006c1e8705bd6c4d79--