summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLonero Foundation <loneroassociation@gmail.com>2021-03-12 18:21:36 -0500
committerbitcoindev <bitcoindev@gnusha.org>2021-03-12 23:21:51 +0000
commit0583dbdaa8725ba168a53057ce395831879a1072 (patch)
treebf75eb3747a3e21d5cd5bcf7ad2fe0c135452b0b
parente45c07b22cea37f2caf7f4e27d8ee4c1c0e607f3 (diff)
downloadpi-bitcoindev-0583dbdaa8725ba168a53057ce395831879a1072.tar.gz
pi-bitcoindev-0583dbdaa8725ba168a53057ce395831879a1072.zip
Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST Datastore for Energy Efficient Mining
-rw-r--r--3e/825c71e90b76ae7aa1f0090ab852fdbde34518736
1 files changed, 736 insertions, 0 deletions
diff --git a/3e/825c71e90b76ae7aa1f0090ab852fdbde34518 b/3e/825c71e90b76ae7aa1f0090ab852fdbde34518
new file mode 100644
index 000000000..49d8df5ac
--- /dev/null
+++ b/3e/825c71e90b76ae7aa1f0090ab852fdbde34518
@@ -0,0 +1,736 @@
+Return-Path: <loneroassociation@gmail.com>
+Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id E8FFAC0001
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 12 Mar 2021 23:21:51 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by smtp4.osuosl.org (Postfix) with ESMTP id CDFC5400A4
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 12 Mar 2021 23:21:51 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+X-Spam-Flag: NO
+X-Spam-Score: -2.099
+X-Spam-Level:
+X-Spam-Status: No, score=-2.099 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]
+ 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 LUJttSKAf0YS
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 12 Mar 2021 23:21:49 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.8.0
+Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com
+ [IPv6:2607:f8b0:4864:20::b30])
+ by smtp4.osuosl.org (Postfix) with ESMTPS id 03CA0444E5
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 12 Mar 2021 23:21:48 +0000 (UTC)
+Received: by mail-yb1-xb30.google.com with SMTP id f145so10654336ybg.11
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Fri, 12 Mar 2021 15:21:48 -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=Le1rcUYiDL2AfC8LPODDzEIp5m9utpJm6Y7a4MMQNB0=;
+ b=FAWJNxUD1nia/b42jEseOgm46tpGZpC7Q7Xd6qmE5+n93PHehuZBxRp8173atVOOMk
+ slbmS2msxsyPOvD8kfBGBHvC/PMXt0ES4zCYLQYazgyyV1PlJk/U+SV7IwxDFPDdudci
+ 3g4c+enLeY+TYT5gXupvrqLeLESlry8iThOq6kMoRd51Ne65qVg5XQWHEgngSM5pXjeS
+ QvPJ0gdM7cWAOUvd+Vu+Arit+bCotp7QonbpEA+hB4ygEs0IPw6pQOcLWVISweH7zmVw
+ wsIGyLErG+IDbZ2Fjr05hlpC2YdGbFM8adsZkjpmDtc8ydCZnrIDD99hksRqTk4lN1SX
+ Wm3w==
+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=Le1rcUYiDL2AfC8LPODDzEIp5m9utpJm6Y7a4MMQNB0=;
+ b=CdyJ608gruViv3fOHu6Vny5yCxNDckYZhfGpFQUObK5K/OnicHyOLEmw3P3OuUO+uo
+ M5gysHbOdocejFpgBzzwY/pfNIKAvX9B8H3YIZcd0DbzxOMbllcU3HdB4hXkHvLphZb1
+ aaALGm1WlIsWlYnHXYmSL0GyT8fvi3oZFbZXkODe/550ulAivITzvHIRF2d4nexhRq9+
+ G1j0ov/peAvq1tFvoKOzvzQa4VWCLkBKRKQ7j2LQsfxFqKeisQg3m90EztCy4cS7mBnh
+ m8QSwHOj4KBUuHrrnhSeefJVP94OLm3815ooVuNZXvQ45b5o13WJRpVku91vLHi3nCth
+ GF5A==
+X-Gm-Message-State: AOAM533Tx5KoHAuc4WZwIri7NLxRvEzqLqilvsJlP7wBJpr9llNYn0tQ
+ Tb2Q3imf5MdYu8TQYWSHt/QpQDE6ZzGdautJWjY=
+X-Google-Smtp-Source: ABdhPJxA6eXDgRitQROtWQPfC+r3TxHaTw/O/nnjFXkXAQmu+49sDUidBcx4Z5zWgaW8X/CEV3QW9CjiHq/mqmE85bU=
+X-Received: by 2002:a25:ae14:: with SMTP id a20mr23715460ybj.129.1615591307812;
+ Fri, 12 Mar 2021 15:21:47 -0800 (PST)
+MIME-Version: 1.0
+References: <CA+YkXXz9aHfZtt-it_8w4ovF=-QaZ4_9vwDS0Kz36qhHwVDC5Q@mail.gmail.com>
+ <3d65-604bed00-17d-6093c680@171273340>
+In-Reply-To: <3d65-604bed00-17d-6093c680@171273340>
+From: Lonero Foundation <loneroassociation@gmail.com>
+Date: Fri, 12 Mar 2021 18:21:36 -0500
+Message-ID: <CA+YkXXzNAWrPPJfDtB-DXaSf9yoojkuEXeCXzkB2_cMtyHfFXA@mail.gmail.com>
+To: "email@yancy.lol" <email@yancy.lol>
+Content-Type: multipart/alternative; boundary="00000000000001255805bd5f2a53"
+X-Mailman-Approved-At: Sat, 13 Mar 2021 22:53:20 +0000
+Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] BIP Proposal: Consensus (hard fork) PoST
+ Datastore for Energy Efficient Mining
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.15
+Precedence: list
+List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Fri, 12 Mar 2021 23:21:52 -0000
+
+--00000000000001255805bd5f2a53
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+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 changes
+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 consensus
+that I am working on. This is a highly technologically complex idea that I
+am willing to "call my bluff on" and expand upon. As for it being a draft,
+I think this is a good starting point at least for draft status prior to
+working on technological implementation.
+
+Best regards, Andrew
+
+On Fri, Mar 12, 2021 at 5:37 PM email@yancy.lol <email@yancy.lol> wrote:
+
+> I think Andrew himself is an algo. The crypto training set must not be
+> very good.
+>
+> Cheers,
+> -Yancy
+>
+> On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev <
+> bitcoin-dev@lists.linuxfoundation.org> wrote:
+>
+>
+> Hi, I awkwardly phrased that part, I was referring to key validation in
+> relation to that section as well as the hashing related to those keys. I
+> might rephrase it.
+>
+> In regards to technical merit, the main purpose of the BIP is to get a
+> sense of the idea. Once I get assigned a BIP draft #, I am willing to
+> follow it up with many preprints or publications to go in the references
+> implementation section and start dev work before upgrading to final statu=
+s.
+>
+> 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.medi=
+awiki
+>> >> Can I submit a pull request on the BIPs repo for this to go into draf=
+t
+>> mode? Also, I think this provides at least some more insight on what I w=
+ant
+>> 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 doin=
+g
+>> 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 reposito=
+ry
+>> >>>> and bring it to discussion on the mailing list. then you can do a P=
+R
+>> >>>>
+>> >>>> Lonero Foundation via bitcoin-dev
+>> >>>> <bitcoin-dev@lists.linuxfoundation.org> escreveu no dia s=C3=A1bado=
+,
+>> >>>> 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. Ha=
+d
+>> 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 wa=
+s
+>> in relation to the disinfranchisemet point.
+>> >>>> >
+>> >>>> > That said, I think the best way to move forward is to submit a BI=
+P
+>> pull request for a draft via GitHub using BIP #2's draft format and any
+>> questions people have can be answered in the reqeust's comments. That wa=
+y
+>> people don't have to get emails everytime there is a reply, but replies
+>> still get seen as opposed to offline discussion. Since the instructions =
+say
+>> to email bitcoin-dev before doing a bip draft, I have done that. Since
+>> people want to see the draft beforehand and it isn't merged manually
+>> anyways, I think it is the easiest way to handle this.
+>> >>>> >
+>> >>>> > I'm also okay w/ continuing the discussion on bitcoin-dev but
+>> rather form a discussion on git instead given I don't want to accidental=
+ly
+>> 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 an=
+d
+>> non-asic specific hardware anyways. A majority of them would benefit fro=
+m a
+>> hybrid proof, and the fact that it is hybrid in that manner wouldn'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 is
+>> much different than staking. Sorry to draw for the confusion as PoC is m=
+ore
+>> commonly used then PoST.
+>> >>>> >>> There is a way to make PoC cryptographically compatible w/ Proo=
+f
+>> 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. Ther=
+e
+>> 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 t=
+he
+>> cryptography community attempted to propose. The actual argument you hav=
+e
+>> only against this is the Proof of Memory fallacy, which is only partiall=
+y
+>> true. Given how the current hashing algorithm works, hard memory allocat=
+ion
+>> wouldn't be of much benefit given it is more optimized for CPU/ASIC
+>> specific mining. I'm working towards a hybrid mechanism that fixes that.
+>> BTW: The way Bitcoin currently stands in its cryptography still needs
+>> updating regardless. If someone figures out NP hardness or the halting
+>> problem the traditional rule of millions of years to break all of Bitcoi=
+n's
+>> cryptography now comes down to minutes. Bitcoin is going to have to
+>> eventually radically upgrade their cryptography and hashing algo in the
+>> future regardless. I want to integrate some form of NP complexity in
+>> regards to the hybrid cryptography I'm aiming to provide which includes =
+a
+>> polynomial time algorithm in the cryptography. More than likely the firs=
+t
+>> version of my BTC hard fork will be coded in a way where integrating suc=
+h
+>> complexity in the future only requires a soft fork or minor upgrade to i=
+ts
+>> chain.
+>> >>>> >>>
+>> >>>> >>> In regards to the argument, "As a separate issue, proposing a
+>> hard fork in the hashing algorithm will invalidate the enormous amount o=
+f
+>> capital expenditure by mining entities and disincentivize future capital
+>> expenditure into mining hardware that may compute these more "useful"
+>> proofs of work."
+>> >>>> >>>
+>> >>>> >>> A large portion of BTC is already mined through AWS servers and
+>> non-asic specific hardware anyways. A majority of them would benefit fro=
+m a
+>> hybrid proof, and the fact that it is hybrid in that manner wouldn't
+>> disenfranchise currently optimized mining entities as well.
+>> >>>> >>>
+>> >>>> >>> There are other reasons why a cryptography upgrade like this is
+>> beneficial. Theoretically one can argue BItcoin isn't fully decentralize=
+d.
+>> It is few unsolved mathematical proofs away from being entirely broken. =
+My
+>> goal outside of efficiency is to build cryptography in a way that preven=
+ts
+>> such an event from happening in the future, if it was to ever happen. I
+>> have various research in regards to this area and work alot with
+>> distributed computing. I believe if the BTC community likes such a
+>> proposal, I would single handedly be able to build the cryptographic pro=
+of
+>> myself (though would like as many open source contributors as I can get =
+:)
+>> >>>> >>>
+>> >>>> >>> Anyways just something to consider. We are in the same space in
+>> regards to what warrants a shitcoin or the whole argument against stakin=
+g.
+>> >>>> >>>
+>> https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency-sto=
+p-telling-us-that-you-arent-pi3s3yjl
+>> >>>> >>>
+>> >>>> >>> Best regards, Andrew
+>> >>>> >>>
+>> >>>> >>> On Fri, Mar 5, 2021 at 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. If the w=
+ork
+>> was useful it provides an avenue for actors to have nothing at stake whe=
+n
+>> submitting a proof of work, since the marginal cost of block constructio=
+n
+>> will be lessened by the fact that the work was useful in a different
+>> context and therefore would have been done anyway. This actually degrade=
+s
+>> the security of the network in the process.
+>> >>>> >>>>
+>> >>>> >>>> As a separate issue, proposing a hard fork in the hashing
+>> algorithm will invalidate the enormous amount of capital expenditure by
+>> mining entities and disincentivize future capital expenditure into minin=
+g
+>> 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 mo=
+re
+>> risk meaning that no entity is tying their own interests to that of the
+>> bitcoin network at large. It also puts the developers in a position wher=
+e
+>> they can be bribed by entities with a vested interest in deciding what t=
+he
+>> 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 m=
+y
+>> cryptography proposal helps behind the efficiency category but also tack=
+les
+>> problems such as NP-Completeness or Halting which is something the 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 s=
+uch
+>> as bigger block height have been proposed as hard forks, I feel at the v=
+ery
+>> least an upgrade regarding the hashing algorithm and cryptography does a=
+t
+>> least warrant some discussion. Anyways I hope I can send you my BIP, jus=
+t
+>> 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 regard=
+s
+>> to renewables or mining devices but a better cryptography layer to get t=
+he
+>> most out of your hashing for validation. I do understand the arbitrarine=
+ss
+>> of it, but do want to still propose a document. Do I use the Media Wiki
+>> format on GitHub and just attach it as my proposal?
+>> >>>> >>>>>>
+>> >>>> >>>>>> Best regards, Andrew
+>> >>>> >>>>>>
+>> >>>> >>>>>> On Fri, Mar 5, 2021, 10:07 AM Devrandom <
+>> c1.devrandom@niftybox.net> wrote:
+>> >>>> >>>>>>>
+>> >>>> >>>>>>> Hi Ryan and Andrew,
+>> >>>> >>>>>>>
+>> >>>> >>>>>>> On Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev <
+>> bitcoin-dev@lists.linuxfoundation.org> wrote:
+>> >>>> >>>>>>>>
+>> >>>> >>>>>>>>
+>> >>>> >>>>>>>> https://www.truthcoin.info/blog/pow-cheapest/
+>> >>>> >>>>>>>> "Nothing is Cheaper than Proof of Work"
+>> >>>> >>>>>>>> on | 04 Aug 2015
+>> >>>> >>>>>>>>
+>> >>>> >>>>>>>
+>> >>>> >>>>>>> Just to belabor this a bit, the paper demonstrates that the
+>> mining market will tend to expend resources equivalent to miner reward. =
+ It
+>> 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 argue
+>> 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-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
+>> >
+>> > _______________________________________________
+>> > bitcoin-dev mailing list
+>> > bitcoin-dev@lists.linuxfoundation.org
+>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+>
+>
+>
+>
+
+--00000000000001255805bd5f2a53
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div>Hi, I also want to emphasize that my main point isn&#=
+39;t just to create a BTC hardfork or become another Bitcoin 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 changes I am proposing can fix. In regards to technological imp=
+lementation, once this is assigned draft status I am more than willing to c=
+reate preprints explaining the cryptography, hashing algorithm improvements=
+, and consensus that I am working on. This is a highly technologically comp=
+lex idea that I am willing to &quot;call my bluff on&quot; and expand upon.=
+ As for it being a draft, I think this is a good starting point at least fo=
+r draft status prior to working on technological implementation.</div><div>=
+<br></div><div>Best regards, Andrew<br></div></div><br><div class=3D"gmail_=
+quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 12, 2021 at 5:37 P=
+M email@yancy.lol &lt;email@yancy.lol&gt; wrote:<br></div><blockquote class=
+=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
+b(204,204,204);padding-left:1ex">I think Andrew himself is an algo.=C2=A0 T=
+he crypto training set must not be very good.<br><br>Cheers,<br>-Yancy<br><=
+br>On Friday, March 12, 2021 17:54 CET, Lonero Foundation via bitcoin-dev &=
+lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
+k">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>=C2=A0<blockquot=
+e type=3D"cite" cite=3D"http://CA+YkXXz9aHfZtt-it_8w4ovF=3D-QaZ4_9vwDS0Kz36=
+qhHwVDC5Q@mail.gmail.com"><div dir=3D"auto">Hi, I awkwardly phrased that pa=
+rt, I was referring to key validation in relation to that section as well a=
+s the hashing related to those keys. I might rephrase it.=C2=A0<div dir=3D"=
+auto">=C2=A0</div><div dir=3D"auto">In regards to technical merit, the main=
+ purpose of the BIP is to get a sense of the idea. Once I get assigned a BI=
+P draft #, I am willing to follow it up with many preprints or publications=
+ to go in the references implementation section and start dev work before u=
+pgrading to final status.</div><div dir=3D"auto">=C2=A0</div><div dir=3D"au=
+to">This will take about 400 hours of my time, but is something I am person=
+ally 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 assigne=
+d a number to references I do at the very least hope to describe various pa=
+rts of the cryptographic proofs and algorithmic structure I am hoping for.<=
+/div><div dir=3D"auto">=C2=A0</div><div dir=3D"auto">Best regards, Andrew</=
+div></div>=C2=A0<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
+attr">On Fri, Mar 12, 2021, 10:03 AM Erik Aronesty &lt;<a href=3D"mailto:er=
+ik@q32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:</div><blockquote =
+class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
+id rgb(204,204,204);padding-left:1ex">secp236k1 isn&#39;t a hashing algo.=
+=C2=A0 =C2=A0your BIP needs about 10 more pages<br>and some degree of techn=
+ical merit.<br><br>i suggest you start here:<br><br><a rel=3D"noreferrer no=
+referrer" href=3D"https://en.bitcoin.it/wiki/Proof_of_burn" target=3D"_blan=
+k">https://en.bitcoin.it/wiki/Proof_of_burn</a><br><a rel=3D"noreferrer nor=
+eferrer" href=3D"https://bitcointalk.org/index.php?topic=3D225690.0" target=
+=3D"_blank">https://bitcointalk.org/index.php?topic=3D225690.0</a><br><br>p=
+roof-of-burn is a nice alternative to proof-of-work.=C2=A0 =C2=A0i always<b=
+r>suspected that, if designed correctly, it could be a proven<br>equivalent=
+.=C2=A0 =C2=A0you could spin up a fork of bitcoin that allows aged,<br>burn=
+ed, coins instead of POW that would probably work just fine.<br><br>- erik<=
+br><br>On Thu, Mar 11, 2021 at 11:56 AM Lonero Foundation via bitcoin-dev<b=
+r>&lt;<a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
+n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
+e:<br>&gt;<br>&gt; Hi, I have submitted the BIP Pull Request here: <a rel=
+=3D"noreferrer noreferrer" href=3D"https://github.com/bitcoin/bips/pull/108=
+4" target=3D"_blank">https://github.com/bitcoin/bips/pull/1084</a><br>&gt;<=
+br>&gt; Hoping to receive a BIP # for the draft prior to development/refere=
+nce implementation.<br>&gt;<br>&gt; Best regards, Andrew<br>&gt;<br>&gt; On=
+ Mon, Mar 8, 2021, 6:40 PM Lonero Foundation &lt;<a rel=3D"noreferrer" href=
+=3D"mailto:loneroassociation@gmail.com" target=3D"_blank">loneroassociation=
+@gmail.com</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; Hi, here is the list to t=
+he BIP proposal on my own repo: <a rel=3D"noreferrer noreferrer" href=3D"ht=
+tps://github.com/Mentors4EDU/bip-amkn-posthyb/blob/main/bip-draft.mediawiki=
+" target=3D"_blank">https://github.com/Mentors4EDU/bip-amkn-posthyb/blob/ma=
+in/bip-draft.mediawiki</a><br>&gt;&gt; Can I submit a pull request on the B=
+IPs repo for this to go into draft mode? Also, I think this provides at lea=
+st some more insight on what I want to work on.<br>&gt;&gt;<br>&gt;&gt; Bes=
+t regards, Andrew<br>&gt;&gt;<br>&gt;&gt; On Sat, Mar 6, 2021, 10:42 AM Lon=
+ero Foundation &lt;<a rel=3D"noreferrer" href=3D"mailto:loneroassociation@g=
+mail.com" target=3D"_blank">loneroassociation@gmail.com</a>&gt; wrote:<br>&=
+gt;&gt;&gt;<br>&gt;&gt;&gt; [off-list]<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Okay=
+. I will do so and post the link here for discussion before doing a pull re=
+quest on BIP&#39;s repo as the best way to handle it.<br>&gt;&gt;&gt;<br>&g=
+t;&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" 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 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" href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
+ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; es=
+creveu no dia s=C3=A1bado,<br>&gt;&gt;&gt;&gt; 6/03/2021 =C3=A0(s) 08:58:<b=
+r>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&gt; &gt; I know Ethereum had an out=
+landishly 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 ta=
+ke 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 upgr=
+ade 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 b=
+est way to move forward is to submit a BIP pull request for a draft via Git=
+Hub using BIP #2&#39;s draft format and any questions people have can be an=
+swered in the reqeust&#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 t=
+o offline discussion. Since the instructions say to email bitcoin-dev befor=
+e doing a bip draft, I have done that. Since people want to see the draft b=
+eforehand and it isn&#39;t merged manually anyways, I think it is the easie=
+st way to handle this.<br>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&gt; &gt; I&=
+#39;m also okay w/ continuing the discussion on bitcoin-dev but rather form=
+ a discussion on git instead given I don&#39;t want to accidentally impolit=
+ely 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;&g=
+t;&gt; &gt; Does that seem fine?<br>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&g=
+t; &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 McClelland &lt;<a rel=3D"noreferrer=
+" href=3D"mailto:keagan.mcclelland@gmail.com" target=3D"_blank">keagan.mccl=
+elland@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 ser=
+vers 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 would=
+n&#39;t disenfranchise currently optimized mining entities as well.<br>&gt;=
+&gt;&gt;&gt; &gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt; My instincts tell me tha=
+t this is 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, 2021 at 3:22 P=
+M Lonero Foundation via bitcoin-dev &lt;<a rel=3D"noreferrer" href=3D"mailt=
+o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
+s.linuxfoundation.org</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>&g=
+t;&gt;&gt;&gt; &gt;&gt;&gt; Actually I mentioned a proof of space and time =
+hybrid which is much different than staking. Sorry to draw for the confusio=
+n as PoC is more 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 stands: <a rel=3D"noreferrer noreferrer" href=3D"https://en.wi=
+kipedia.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 bee=
+n done though given the technological complexity of being both CPU compatib=
+le and memory-hard compatible. There are lots of benefits outside of the re=
+alm of efficiency, and I already looked into numerous fault tolerant design=
+s as well and what others in the cryptography community attempted to propos=
+e. The actual argument you have only against this is the Proof of Memory fa=
+llacy, which is only partially true. Given how the current hashing algorith=
+m works, hard memory allocation wouldn&#39;t be of much benefit given it is=
+ more optimized for CPU/ASIC specific mining. I&#39;m working towards a hyb=
+rid mechanism that fixes that. BTW: The way Bitcoin currently stands in its=
+ cryptography still needs updating regardless. If someone figures out NP ha=
+rdness or the 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 has=
+hing algo in the future regardless. I want to integrate some form of NP com=
+plexity in regards to the hybrid cryptography I&#39;m aiming to provide whi=
+ch includes a polynomial time algorithm in the cryptography. More than like=
+ly the first version of my BTC hard fork will be coded in a way where integ=
+rating such complexity in the future only requires a soft fork or minor upg=
+rade 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 expenditure by mining entities and disincentivize future capital e=
+xpenditure into mining hardware that may compute these more &quot;useful&qu=
+ot; proofs of work.&quot;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;<br>&gt;&gt;&gt;&=
+gt; &gt;&gt;&gt; A large portion of BTC is already mined through AWS server=
+s and non-asic specific hardware anyways. A majority of them would benefit =
+from a hybrid proof, and the fact that it is hybrid in that manner wouldn&#=
+39;t disenfranchise currently optimized mining entities as well.<br>&gt;&gt=
+;&gt;&gt; &gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; There are other rea=
+sons why a cryptography upgrade like this is beneficial. Theoretically one =
+can argue BItcoin isn&#39;t fully decentralized. It is few unsolved mathema=
+tical proofs away from being entirely broken. My goal outside of efficiency=
+ is to build cryptography in a way that prevents such an event from happeni=
+ng in the future, if it was to ever happen. I have various research in rega=
+rds to this area and work alot with distributed computing. I believe if the=
+ BTC community likes such a proposal, I would single handedly be able to bu=
+ild the cryptographic proof myself (though would like as many open source c=
+ontributors 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 s=
+pace in regards to what warrants a shitcoin or the whole argument against s=
+taking.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer noreferrer" h=
+ref=3D"https://hackernoon.com/ethereum-you-are-a-centralized-cryptocurrency=
+-stop-telling-us-that-you-arent-pi3s3yjl" target=3D"_blank">https://hackern=
+oon.com/ethereum-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;<b=
+r>&gt;&gt;&gt;&gt; &gt;&gt;&gt; On Fri, Mar 5, 2021 at 4:11 PM Keagan McCle=
+lland &lt;<a rel=3D"noreferrer" href=3D"mailto:keagan.mcclelland@gmail.com"=
+ target=3D"_blank">keagan.mcclelland@gmail.com</a>&gt; wrote:<br>&gt;&gt;&g=
+t;&gt; &gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; It is importan=
+t to understand that it is critical for the work to be &quot;useless&quot; =
+in order for the security model to be the same. If the work was useful it p=
+rovides an avenue for actors to have nothing at stake when submitting a pro=
+of 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 w=
+ould have been done anyway. This actually degrades the security of the netw=
+ork 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 hashin=
+g algorithm will invalidate the enormous amount of capital expenditure by m=
+ining entities and disincentivize future capital expenditure into mining ha=
+rdware that may compute these more &quot;useful&quot; 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 of the bit=
+coin 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 =
+&quot;useful&quot; proof of work should be.<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt=
+;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; All of these things make the Bit=
+coin 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 Foundati=
+on via bitcoin-dev &lt;<a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@lis=
+ts.linuxfoundation.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 i=
+terate that my cryptography proposal helps behind the efficiency category b=
+ut also tackles problems such as NP-Completeness or Halting which is someth=
+ing 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 in re=
+gards to this manner and can provide useful insight to the community. If th=
+ings such as bigger block height have been proposed as hard forks, I feel a=
+t the very least an upgrade regarding the hashing algorithm and cryptograph=
+y does at least warrant some discussion. Anyways I hope I can send you my B=
+IP, just let me know on the preferred format?<br>&gt;&gt;&gt;&gt; &gt;&gt;&=
+gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; Best regards, Andrew<b=
+r>&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"norefer=
+rer" href=3D"mailto:loneroassociation@gmail.com" target=3D"_blank">loneroas=
+sociation@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 bu=
+t a better cryptography layer to get the most out of your hashing for valid=
+ation. I do understand the arbitrariness of it, but do want to still propos=
+e a document. Do I use the Media Wiki format on GitHub and just attach it a=
+s my proposal?<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;=
+&gt; &gt;&gt;&gt;&gt;&gt;&gt; Best regards, Andrew<br>&gt;&gt;&gt;&gt; &gt;=
+&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt; On Fri, M=
+ar 5, 2021, 10:07 AM Devrandom &lt;<a rel=3D"noreferrer" href=3D"mailto:c1.=
+devrandom@niftybox.net" target=3D"_blank">c1.devrandom@niftybox.net</a>&gt;=
+ wrote:<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt=
+; &gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi Ryan and Andrew,<br>&gt;&gt;&gt;&gt; &gt;=
+&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; O=
+n Fri, Mar 5, 2021 at 5:42 AM Ryan Grant via bitcoin-dev &lt;<a rel=3D"nore=
+ferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
+ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>&gt;&gt;&gt;&g=
+t; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt=
+;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;=C2=A0 =
+=C2=A0<a rel=3D"noreferrer noreferrer" href=3D"https://www.truthcoin.info/b=
+log/pow-cheapest/" target=3D"_blank">https://www.truthcoin.info/blog/pow-ch=
+eapest/</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 2015<b=
+r>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt=
+;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; =
+Just to belabor this a bit, the paper demonstrates that the mining market w=
+ill tend to expend resources equivalent to miner reward.=C2=A0 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 external=
+ities and that we should move to other resources.=C2=A0 I would argue that =
+the negative externalities will go away soon because of the move to renewab=
+les, 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; __________________________=
+_____________________<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"=
+ href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
+tcoin-dev@lists.linuxfoundation.org</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt=
+;&gt; <a rel=3D"noreferrer noreferrer" href=3D"https://lists.linuxfoundatio=
+n.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfo=
+undation.org/mailman/listinfo/bitcoin-dev</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&=
+gt;<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; ______________________________________=
+_________<br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; bitcoin-dev mailing list<br>&gt;=
+&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer" href=3D"mailto:bitcoin-dev@=
+lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
+ion.org</a><br>&gt;&gt;&gt;&gt; &gt;&gt;&gt; <a rel=3D"noreferrer noreferre=
+r" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
+n-dev</a><br>&gt;&gt;&gt;&gt; &gt;<br>&gt;&gt;&gt;&gt; &gt; _______________=
+________________________________<br>&gt;&gt;&gt;&gt; &gt; bitcoin-dev maili=
+ng list<br>&gt;&gt;&gt;&gt; &gt; <a rel=3D"noreferrer" href=3D"mailto:bitco=
+in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
+foundation.org</a><br>&gt;&gt;&gt;&gt; &gt; <a rel=3D"noreferrer noreferrer=
+" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" t=
+arget=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin=
+-dev</a><br>&gt;<br>&gt; _______________________________________________<br=
+>&gt; bitcoin-dev mailing list<br>&gt; <a rel=3D"noreferrer" href=3D"mailto=
+:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
+.linuxfoundation.org</a><br>&gt; <a rel=3D"noreferrer noreferrer" href=3D"h=
+ttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_b=
+lank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></b=
+lockquote></div></blockquote><br><br><br>=C2=A0
+</blockquote></div>
+
+--00000000000001255805bd5f2a53--
+
+