path: root/2c/db4a503688dac306d5e0c8c9800384983969b4

Return-Path: <email@yancy.lol>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1D7D5C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 08:13:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id F34334EC3B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 08:13:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001,
 T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 o9OpforMjilM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 08:13:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 26C7A4EC3A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 13 Mar 2021 08:13:28 +0000 (UTC)
Received: from sogo1.sd4.0x35.net (sogo1.sd4.0x35.net [10.200.201.51])
 (Authenticated sender: email@yancy.lol)
 by relay12.mail.gandi.net (Postfix) with ESMTPA id 9B5A4200004;
 Sat, 13 Mar 2021 08:13:25 +0000 (UTC)
From: "email@yancy.lol" <email@yancy.lol>
In-Reply-To: <CA+YkXXw5uh4yfvqDiBBEXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="----=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------"
X-Forward: 127.0.0.1
Date: Sat, 13 Mar 2021 09:13:25 +0100
To: "Lonero Foundation" <loneroassociation@gmail.com>
MIME-Version: 1.0
Message-ID: <1802-604c7400-4d1-7b635e80@91248813>
User-Agent: SOGoMail 5.0.1
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]
 =?utf-8?q?BIP_Proposal=3A_Consensus_=28hard_fork=29?=
 =?utf-8?q?_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 08:13:33 -0000

------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 16332


My email was not intended as an insult.=C2=A0 Your proposal seemed a bi=
t like gibberish and made some obvious mistakes as pointed out before (=
such as conflating secp256k1 with sha256), and so I was genuinely curio=
us if you were a bot spamming the list.=C2=A0
Maybe a more interesting topic is, can GPT3 be used to generate 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 frequency?=C2=
=A0 Will we have lost the war to our new centralized overlord?
Cheers,
-Yancy


On Saturday, March 13, 2021 00:31 CET, Lonero Foundation <loneroassocia=
tion@gmail.com> wrote:
=C2=A0Also, I already stated I was referring to signature validation cr=
yptography in that aspect: https://wizardforcel.gitbooks.io/practical-c=
ryptography-for-developers-book/content/digital-signatures/ecdsa-sign-v=
erify-examples.htmlMy BIP has a primary purpose in regards to what I wa=
nt to develop proofs for and the different cryptographic elements I wan=
t to develop proofs for.That said to those who disagree with the premis=
e, I do prefer constructive feedback over insults or making fun of one =
another. After all this is an improvement proposal with a specific purp=
ose aiming to develop a specific thing, not a guy who is just wanting t=
o copy and paste a repository and call it a day.=C2=A0Best regards, And=
rew=C2=A0On Fri, Mar 12, 2021 at 6:21 PM Lonero Foundation <loneroassoc=
iation@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, Go=
ld, or SV. The main point in regards to this BIP actually expands POW r=
ather than replaces or creates an alternative. Many of the problems fac=
ed in regards to security in the future as well as sustainability is so=
mething I believe lots of the changes I am proposing can fix. In regard=
s to technological implementation, once this is assigned draft status I=
 am more than willing to create preprints explaining the cryptography, =
hashing algorithm improvements, and consensus that I am working on. Thi=
s is a highly technologically complex idea that I am willing to "call m=
y 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 tech=
nological implementation.=C2=A0Best regards, Andrew=C2=A0On Fri, Mar 12=
, 2021 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote:I think Andre=
w himself is an algo.=C2=A0 The crypto training set must not be very go=
od.

Cheers,
-Yancy

On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
=C2=A0Hi, I awkwardly phrased that part, I was referring to key validat=
ion in relation to that section as well as the hashing related to those=
 keys. I might rephrase it.=C2=A0=C2=A0In regards to technical merit, t=
he main purpose of the BIP is to get a sense of the idea. Once I get as=
signed a BIP draft #, I am willing to follow it up with many preprints =
or publications to go in the references implementation section and star=
t dev work before upgrading to final status.=C2=A0This will take about =
400 hours of my time, but is something I am personally looking into dev=
eloping as a hard fork.=C2=A0Keep in mind this is a draft, so after it =
is assigned a number to references I do at the very least hope to descr=
ibe various parts of the cryptographic proofs and algorithmic structure=
 I am hoping for.=C2=A0Best regards, Andrew=C2=A0On Fri, Mar 12, 2021, =
10:03 AM Erik Aronesty <erik@q32.com> wrote:secp236k1 isn't a hashing a=
lgo.=C2=A0 =C2=A0your BIP needs about 10 more pages
and some degree of technical merit.

i suggest you start here:

https://en.bitcoin.it/wiki/Proof=5Fof=5Fburn
https://bitcointalk.org/index.php?topic=3D225690.0

proof-of-burn is a nice alternative to proof-of-work.=C2=A0 =C2=A0i alw=
ays
suspected that, if designed correctly, it could be a proven
equivalent.=C2=A0 =C2=A0you 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/bi=
tcoin/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@gma=
il.com> wrote:
>>
>> Hi, here is the list to the BIP proposal on my own repo: https://git=
hub.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki
>> Can I submit a pull request on the BIPs repo for this to go into dra=
ft 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@g=
mail.com> wrote:
>>>
>>> [off-list]
>>>
>>> Okay. I will do so and post the link here for discussion before doi=
ng 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 reposit=
ory
>>>> 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 ru=
nning 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 st=
ill 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 B=
IP 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. Th=
at way people don't have to get emails everytime there is a reply, but =
replies still get seen as opposed to offline discussion. Since the inst=
ructions 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 merge=
d manually anyways, I think it is the easiest way to handle this.
>>>> >
>>>> > I'm also okay w/ continuing the discussion on bitcoin-dev but ra=
ther form a discussion on git instead given I don't want to accidentall=
y impolitely bother people given this is a moderated list and we alread=
y 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.mcclellan=
d@gmail.com> wrote:
>>>> >>
>>>> >> > A large portion of BTC is already mined through AWS servers a=
nd 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 wou=
ldn't disenfranchise currently optimized mining entities as well.
>>>> >>
>>>> >> My instincts tell me that this is an outlandish claim. Do you h=
ave 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/ Pro=
of of Work as it normally stands: https://en.wikipedia.org/wiki/Proof=5F=
of=5Fspace
>>>> >>> It has rarely been done though given the technological complex=
ity of being both CPU compatible and memory-hard compatible. There are =
lots of benefits outside of the realm of efficiency, and I already look=
ed 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 part=
ially true. Given how the current hashing algorithm works, hard memory =
allocation wouldn't be of much benefit given it is more optimized for C=
PU/ASIC specific mining. I'm working towards a hybrid mechanism that fi=
xes that. BTW: The way Bitcoin currently stands in its cryptography sti=
ll needs updating regardless. If someone figures out NP hardness or the=
 halting problem the traditional rule of millions of years to break all=
 of Bitcoin's cryptography now comes down to minutes. Bitcoin is going =
to have to eventually radically upgrade their cryptography and hashing =
algo in the future regardless. I want to integrate some form of NP comp=
lexity in regards to the hybrid cryptography I'm aiming to provide whic=
h includes a polynomial time algorithm in the cryptography. More than l=
ikely the first version of my BTC hard fork will be coded in a way wher=
e integrating such complexity in the future only requires a soft fork o=
r 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 cap=
ital expenditure into mining hardware that may compute these more "usef=
ul" 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 =
from a hybrid proof, and the fact that it is hybrid in that manner woul=
dn'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 decentral=
ized. It is few unsolved mathematical proofs away from being entirely b=
roken. My goal outside of efficiency is to build cryptography 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 work a=
lot with distributed computing. I believe if the BTC community likes su=
ch a proposal, I would single handedly be able to build the cryptograph=
ic 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 i=
n regards to what warrants a shitcoin or the whole argument against sta=
king.
>>>> >>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocu=
rrency-stop-telling-us-that-you-arent-pi3s3yjl
>>>> >>>
>>>> >>> Best regards,=C2=A0 Andrew
>>>> >>>
>>>> >>> On Fri, Mar 5, 2021 at 4:11 PM Keagan McClelland <keagan.mccle=
lland@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 th=
e work was useful it provides an avenue for actors to have nothing at s=
take 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 alg=
orithm will invalidate the enormous amount of capital expenditure by mi=
ning entities and disincentivize future capital expenditure into mining=
 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 =
more risk meaning that no entity is tying their own interests to that o=
f the bitcoin network at large. It also puts the developers in a positi=
on where they can be bribed by entities with a vested interest in decid=
ing 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 simpl=
icity, I do want to do this BIP because it tackles lots of the issues i=
n regards to this manner and can provide useful insight to the communit=
y. If things such as bigger block height have been proposed as hard for=
ks, 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, just let me know on the preferred format?
>>>> >>>>>
>>>> >>>>> Best regards, Andrew
>>>> >>>>>
>>>> >>>>> On Fri, Mar 5, 2021, 10:12 AM Lonero Foundation <loneroassoc=
iation@gmail.com> wrote:
>>>> >>>>>>
>>>> >>>>>> Hi, this isn't about the energy efficient argument in regar=
ds to renewables or mining devices but a better cryptography layer to g=
et the most out of your hashing for validation. I do understand the arb=
itrariness 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@nifty=
box.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:
>>>> >>>>>>>>
>>>> >>>>>>>>
>>>> >>>>>>>>=C2=A0 =C2=A0https://www.truthcoin.info/blog/pow-cheapest/=

>>>> >>>>>>>>=C2=A0 =C2=A0 =C2=A0"Nothing is Cheaper than Proof of Work=
"
>>>> >>>>>>>>=C2=A0 =C2=A0 =C2=A0on | 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 rewar=
d.=C2=A0 It does not prove that mining work has to expend *energy* as a=
 primary cost.
>>>> >>>>>>>
>>>> >>>>>>> Some might argue that energy expenditure has negative exte=
rnalities and that we should move to other resources.=C2=A0 I would arg=
ue that the negative externalities will go away soon because of the mov=
e to renewables, so the point is likely moot.
>>>> >>>>>>>
>>>> >>>>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F
>>>> >>>>> bitcoin-dev mailing list
>>>> >>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev
>>>> >>>
>>>> >>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F
>>>> >>> bitcoin-dev mailing list
>>>> >>> bitcoin-dev@lists.linuxfoundation.org
>>>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=

>>>> >
>>>> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F
>>>> > bitcoin-dev mailing list
>>>> > bitcoin-dev@lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=

> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


=C2=A0


=C2=A0

------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539------
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Length: 25217

<html><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bo=
ttom:0pt;" id=3D"docs-internal-guid-4056a8b1-7fff-9296-3427-4d2e04c785c=
7"><span style=3D"font-size: 11pt; font-family: Arial; background-color=
: transparent; font-weight: 400; font-style: normal; font-variant: norm=
al; text-decoration: none; vertical-align: baseline; white-space: pre-w=
rap;">My email was not intended as an insult.&nbsp; Your proposal seeme=
d a bit like gibberish and made some obvious mistakes as pointed out be=
fore (such as conflating secp256k1 with sha256), and so I was genuinely=
 curious if you were a bot spamming the list.</span></p>&nbsp;<p dir=3D=
"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt;"><spa=
n style=3D"font-size: 11pt; font-family: Arial; background-color: trans=
parent; font-weight: 400; font-style: normal; font-variant: normal; tex=
t-decoration: none; vertical-align: baseline; white-space: pre-wrap;">M=
aybe a more interesting topic is, can GPT3 be used to generate a BIP?&n=
bsp; How long before our AI overlord produces improvements to Bitcoin?&=
nbsp; At what point will the AI have more than 51% of commit frequency?=
&nbsp; Will we have lost the war to our new centralized overlord?</span=
></p><br />Cheers,<br />-Yancy<br /><br /><br />On Saturday, March 13, =
2021 00:31 CET, Lonero Foundation &lt;loneroassociation@gmail.com&gt; w=
rote:<br />&nbsp;<blockquote type=3D"cite" cite=3D"CA+YkXXw5uh4yfvqDiBB=
EXcq188PEGku-NFFAq7uNuAFTG3ooTQ@mail.gmail.com"><div dir=3D"ltr"><div>A=
lso, I already stated I was referring to signature validation cryptogra=
phy in that aspect: <a href=3D"https://wizardforcel.gitbooks.io/practic=
al-cryptography-for-developers-book/content/digital-signatures/ecdsa-si=
gn-verify-examples.html">https://wizardforcel.gitbooks.io/practical-cry=
ptography-for-developers-book/content/digital-signatures/ecdsa-sign-ver=
ify-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 e=
lements I want to develop proofs for.</div><div>That said to those who =
disagree with the premise, I do prefer constructive feedback over insul=
ts or making fun of one another. After all this is an improvement propo=
sal with a specific purpose aiming to develop a specific thing, not a g=
uy who is just wanting to copy and paste a repository and call it a day=
.</div><div>&nbsp;</div><div>Best regards, Andrew</div></div>&nbsp;<div=
 class=3D"gmail=5Fquote"><div dir=3D"ltr" class=3D"gmail=5Fattr">On Fri=
, Mar 12, 2021 at 6:21 PM Lonero Foundation &lt;<a href=3D"mailto:loner=
oassociation@gmail.com">loneroassociation@gmail.com</a>&gt; wrote:</div=
><blockquote class=3D"gmail=5Fquote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r"><div>Hi, I also want to emphasize that my main point isn't just to c=
reate a BTC hardfork or become another Bitcoin Cash, Gold, or SV. The m=
ain point in regards to this BIP actually expands POW rather than repla=
ces or creates an alternative. Many of the problems faced in regards to=
 security in the future as well as sustainability is something I believ=
e lots of the changes I am proposing can fix. In regards to technologic=
al implementation, once this is assigned draft status I am more than wi=
lling to create preprints explaining the cryptography, hashing algorith=
m improvements, and consensus that I am working on. This is a highly te=
chnologically 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 p=
oint at least for draft status prior to working on technological implem=
entation.</div><div>&nbsp;</div><div>Best regards, Andrew</div></div>&n=
bsp;<div class=3D"gmail=5Fquote"><div dir=3D"ltr" class=3D"gmail=5Fattr=
">On Fri, Mar 12, 2021 at 5:37 PM email@yancy.lol &lt;email@yancy.lol&g=
t; wrote:</div><blockquote class=3D"gmail=5Fquote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
I think Andrew himself is an algo.&nbsp; The crypto training set must n=
ot be very good.<br /><br />Cheers,<br />-Yancy<br /><br />On Friday, M=
arch 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev &lt;<a targe=
t=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br />&nbsp;<blockquo=
te type=3D"cite" cite=3D"http://CA+YkXXz9aHfZtt-it=5F8w4ovF=3D-QaZ4=5F9=
vwDS0Kz36qhHwVDC5Q@mail.gmail.com"><div dir=3D"auto">Hi, I awkwardly ph=
rased 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.&nbsp;<div dir=3D"auto">&nbsp;</div><div dir=3D"auto">In regards to =
technical merit, the main purpose of the BIP is to get a sense of the i=
dea. Once I get assigned a BIP draft #, I am willing to follow it up wi=
th many preprints or publications to go in the references implementatio=
n section and start dev work before upgrading to final status.</div><di=
v dir=3D"auto">&nbsp;</div><div dir=3D"auto">This will take about 400 h=
ours of my time, but is something I am personally looking into developi=
ng as a hard fork.</div><div dir=3D"auto">&nbsp;</div><div dir=3D"auto"=
>Keep in mind this is a draft, so after it is assigned a number to refe=
rences I do at the very least hope to describe various parts of the cry=
ptographic proofs and algorithmic structure I am hoping for.</div><div =
dir=3D"auto">&nbsp;</div><div dir=3D"auto">Best regards, Andrew</div></=
div>&nbsp;<div class=3D"gmail=5Fquote"><div dir=3D"ltr" class=3D"gmail=5F=
attr">On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty &lt;<a target=3D"=5F=
blank" href=3D"mailto:erik@q32.com">erik@q32.com</a>&gt; wrote:</div><b=
lockquote class=3D"gmail=5Fquote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">secp236k1 isn't a=
 hashing algo.&nbsp; &nbsp;your 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" target=3D"=5Fblank" href=3D"h=
ttps://en.bitcoin.it/wiki/Proof=5Fof=5Fburn">https://en.bitcoin.it/wiki=
/Proof=5Fof=5Fburn</a><br /><a rel=3D"noreferrer noreferrer" target=3D"=
=5Fblank" href=3D"https://bitcointalk.org/index.php?topic=3D225690.0">h=
ttps://bitcointalk.org/index.php?topic=3D225690.0</a><br /><br />proof-=
of-burn is a nice alternative to proof-of-work.&nbsp; &nbsp;i always<br=
 />suspected that, if designed correctly, it could be a proven<br />equ=
ivalent.&nbsp; &nbsp;you could spin up a fork of bitcoin that allows ag=
ed,<br />burned, coins instead of POW that would probably work just fin=
e.<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" target=3D"=5F=
blank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<br />&gt;<br />&gt; Hi, I ha=
ve submitted the BIP Pull Request here: <a rel=3D"noreferrer noreferrer=
" target=3D"=5Fblank" href=3D"https://github.com/bitcoin/bips/pull/1084=
">https://github.com/bitcoin/bips/pull/1084</a><br />&gt;<br />&gt; Hop=
ing to receive a BIP # for the draft prior to development/reference imp=
lementation.<br />&gt;<br />&gt; Best regards, Andrew<br />&gt;<br />&g=
t; On Mon, Mar 8, 2021, 6:40 PM Lonero Foundation &lt;<a rel=3D"norefer=
rer" target=3D"=5Fblank" href=3D"mailto:loneroassociation@gmail.com">lo=
neroassociation@gmail.com</a>&gt; wrote:<br />&gt;&gt;<br />&gt;&gt; Hi=
, here is the list to the BIP proposal on my own repo: <a rel=3D"norefe=
rrer noreferrer" target=3D"=5Fblank" href=3D"https://github.com/Mentors=
4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki">https://github.com=
/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki</a><br />&g=
t;&gt; 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.<br />&gt;&gt;<br />&gt;&gt; Best regards, Andre=
w<br />&gt;&gt;<br />&gt;&gt; On Sat, Mar 6, 2021, 10:42 AM Lonero Foun=
dation &lt;<a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:lon=
eroassociation@gmail.com">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 befo=
re doing a pull request on BIP'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 Ricardo Filipe &lt;<a =
rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:ricardojdfilipe@g=
mail.com">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 BIP =
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"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">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 percentage of nodes running on AWS,=
 I heard the same thing is for Bitcoin but for mining. Had trouble find=
ing the article online so take it with a grain of salt. The point thoug=
h is that both servers and ASIC specific hardware would still be able t=
o benefit from the cryptography upgrade I am proposing, as this was in =
relation to the disinfranchisemet 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's =
draft format and any questions people have can be answered in the reqeu=
st's comments. That way people don't have to get emails everytime there=
 is a reply, but replies still get seen as opposed to offline discussio=
n. Since the instructions say to email bitcoin-dev before doing a bip d=
raft, I have done that. Since people want to see the draft beforehand a=
nd it isn't merged manually anyways, I think it is the easiest way to h=
andle this.<br />&gt;&gt;&gt;&gt; &gt;<br />&gt;&gt;&gt;&gt; &gt; I'm a=
lso okay w/ continuing the discussion on bitcoin-dev but rather form a =
discussion on git instead given I don't want to accidentally impolitely=
 bother people given this is a moderated list and we already establishe=
d 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; &gt;<br=
 />&gt;&gt;&gt;&gt; &gt; Best regards, Andrew<br />&gt;&gt;&gt;&gt; &gt=
;<br />&gt;&gt;&gt;&gt; &gt; On Fri, Mar 5, 2021, 7:41 PM Keagan McClel=
land &lt;<a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:keaga=
n.mcclelland@gmail.com">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-asic specif=
ic hardware anyways. A majority of them would benefit from a hybrid pro=
of, and the fact that it is hybrid in that manner wouldn't disenfranchi=
se 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 i=
s an outlandish 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, 20=
21 at 3:22 PM Lonero Foundation via bitcoin-dev &lt;<a rel=3D"noreferre=
r" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">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 me=
ntioned a proof of space and time hybrid which is much different than s=
taking. Sorry to draw for the confusion as PoC is more commonly used th=
en 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 stands: <a=
 rel=3D"noreferrer noreferrer" target=3D"=5Fblank" href=3D"https://en.w=
ikipedia.org/wiki/Proof=5Fof=5Fspace">https://en.wikipedia.org/wiki/Pro=
of=5Fof=5Fspace</a><br />&gt;&gt;&gt;&gt; &gt;&gt;&gt; It has rarely be=
en done though given the technological complexity of being both CPU com=
patible and memory-hard compatible. There are lots of benefits outside =
of the realm of efficiency, and I already looked into numerous fault to=
lerant designs as well and what others in the cryptography community at=
tempted to propose. The actual argument you have only against this is t=
he Proof of Memory fallacy, which is only partially true. Given how the=
 current hashing algorithm works, hard memory allocation wouldn't be of=
 much benefit given it is more optimized for CPU/ASIC specific mining. =
I'm working towards a hybrid mechanism that fixes that. BTW: The way Bi=
tcoin currently stands in its cryptography still needs updating regardl=
ess. If someone figures out NP hardness or the halting problem the trad=
itional rule of millions of years to break all of Bitcoin's cryptograph=
y now comes down to minutes. Bitcoin is going to have to eventually rad=
ically upgrade their cryptography and hashing algo in the future regard=
less. I want to integrate some form of NP complexity in regards to the =
hybrid cryptography I'm aiming to provide which includes a polynomial t=
ime algorithm in the cryptography. More than likely the first version o=
f my BTC hard fork will be coded in a way where integrating such comple=
xity in the future only requires a soft fork or minor upgrade to its ch=
ain.<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br />&gt;&gt;&gt;&gt; &gt;&gt;&=
gt; In regards to the argument, "As a separate issue, proposing a hard =
fork in the hashing algorithm will invalidate the enormous amount of ca=
pital expenditure by mining entities and disincentivize future capital =
expenditure into mining hardware that may compute these more "useful" p=
roofs of work."<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 serv=
ers and non-asic specific hardware anyways. A majority of them would be=
nefit from a hybrid proof, and the fact that it is hybrid in that manne=
r wouldn't disenfranchise currently optimized mining entities as well.<=
br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt; T=
here are other reasons why a cryptography upgrade like this is benefici=
al. Theoretically one can argue BItcoin isn't fully decentralized. It i=
s 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 happe=
n. I have various research in regards to this area and work alot with d=
istributed computing. I believe if the BTC community likes such a propo=
sal, I would single handedly be able to build the cryptographic proof m=
yself (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;&gt;&gt=
; Anyways just something to consider. We are in the same space in regar=
ds to what warrants a shitcoin or the whole argument against staking.<b=
r />&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer noreferrer" targ=
et=3D"=5Fblank" href=3D"https://hackernoon.com/ethereum-you-are-a-centr=
alized-cryptocurrency-stop-telling-us-that-you-arent-pi3s3yjl">https://=
hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-stop-telli=
ng-us-that-you-arent-pi3s3yjl</a><br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br=
 />&gt;&gt;&gt;&gt; &gt;&gt;&gt; Best regards,&nbsp; Andrew<br />&gt;&g=
t;&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" target=3D=
"=5Fblank" href=3D"mailto:keagan.mcclelland@gmail.com">keagan.mcclellan=
d@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 "useless" in order for the security mod=
el to be the same. If the work was useful it provides an avenue for act=
ors to have nothing at stake when submitting a proof of work, since the=
 marginal cost of block construction will be lessened by the fact that =
the work was useful in a different context and therefore would have bee=
n done anyway. This actually degrades the security of the network in th=
e 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 has=
hing algorithm will invalidate the enormous amount of capital expenditu=
re by mining entities and disincentivize future capital expenditure int=
o mining hardware that may compute these more "useful" proofs of work. =
This is because any change in the POW algorithm will be considered unst=
able and subject to change in the future. This puts the entire network =
at even more risk meaning that no entity is tying their own interests t=
o 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 deciding what the new "useful" proof of work should be.<br />&gt;&gt=
;&gt;&gt; &gt;&gt;&gt;&gt;<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; All o=
f 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:48 PM Lonero Foundation via bitcoin-dev &lt;<=
a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; w=
rote:<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 ite=
rate 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 sak=
e of simplicity, I do want to do this BIP because it tackles lots of th=
e issues in regards to this manner and can provide useful insight to th=
e community. If things such as bigger block height have been proposed a=
s hard forks, I feel at the very least an upgrade regarding the hashing=
 algorithm and cryptography does at least warrant some discussion. Anyw=
ays I hope I can send you my BIP, just let me know on the preferred for=
mat?<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&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" target=3D"=5F=
blank" href=3D"mailto:loneroassociation@gmail.com">loneroassociation@gm=
ail.com</a>&gt; wrote:<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<b=
r />&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; Hi, this isn't about the =
energy efficient argument in regards to renewables or mining devices bu=
t a better cryptography layer to get the most out of your hashing for v=
alidation. I do understand the arbitrariness of it, but do want to stil=
l 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;&g=
t;<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; &g=
t;&gt;&gt;&gt;&gt;&gt; On Fri, Mar 5, 2021, 10:07 AM Devrandom &lt;<a r=
el=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:c1.devrandom@nifty=
box.net">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, Ma=
r 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev &lt;<a rel=3D"noreferre=
r" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">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;&g=
t;&gt;&gt;&gt;&gt;&gt;&gt;<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&g=
t;&gt;&gt;&nbsp; &nbsp;<a rel=3D"noreferrer noreferrer" target=3D"=5Fbl=
ank" href=3D"https://www.truthcoin.info/blog/pow-cheapest/">https://www=
.truthcoin.info/blog/pow-cheapest/</a><br />&gt;&gt;&gt;&gt; &gt;&gt;&g=
t;&gt;&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp;"Nothing is Cheaper than Proo=
f of Work"<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;=
 &nbsp; &nbsp;on | 04 Aug 2015<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;<br />=
&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; Just to belabor this a bi=
t, the paper demonstrates that the mining market will tend to expend re=
sources equivalent to miner reward.&nbsp; It does not 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 externali=
ties and that we should move to other resources.&nbsp; I would argue th=
at the negative externalities will go away soon because of the move to =
renewables, so the point is likely moot.<br />&gt;&gt;&gt;&gt; &gt;&gt;=
&gt;&gt;&gt;&gt;&gt;<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; =5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br />&gt;&=
gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br />&gt;&gt;=
&gt;&gt; &gt;&gt;&gt;&gt;&gt; <a rel=3D"noreferrer" target=3D"=5Fblank"=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a><br />&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; <a=
 rel=3D"noreferrer noreferrer" target=3D"=5Fblank" href=3D"https://list=
s.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linux=
foundation.org/mailman/listinfo/bitcoin-dev</a><br />&gt;&gt;&gt;&gt; &=
gt;&gt;&gt;<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt; =5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br />&gt;&gt;&gt;&gt; &gt=
;&gt;&gt; bitcoin-dev mailing list<br />&gt;&gt;&gt;&gt; &gt;&gt;&gt; <=
a rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />=
&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer noreferrer" target=3D=
"=5Fblank" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/b=
itcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev</a><br />&gt;&gt;&gt;&gt; &gt;<br />&gt;&gt;&gt;&gt; &gt; =5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br />&gt;&=
gt;&gt;&gt; &gt; bitcoin-dev mailing list<br />&gt;&gt;&gt;&gt; &gt; <a=
 rel=3D"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />&=
gt;&gt;&gt;&gt; &gt; <a rel=3D"noreferrer noreferrer" target=3D"=5Fblan=
k" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><=
br />&gt;<br />&gt; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F<br />&gt; bitcoin-dev mailing list<br />&gt; <a rel=3D=
"noreferrer" target=3D"=5Fblank" href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />&gt; <a =
rel=3D"noreferrer noreferrer" target=3D"=5Fblank" href=3D"https://lists=
.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a></blockquote></div></bloc=
kquote><br /><br /><br />&nbsp;</blockquote></div></blockquote></div></=
blockquote><br /><br /><br />&nbsp;</html>

------=_=-_OpenGroupware_org_NGMime-6146-1615623205.217798-539--------