summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAnton Ragin <anton@etc-group.com>2021-05-18 00:02:07 +0100
committerbitcoindev <bitcoindev@gnusha.org>2021-05-17 23:02:29 +0000
commitc9e2aaa7a788d0e79694f7bf96cb15668a6b53c4 (patch)
tree96027d18ec7aef900d4e774b41695e66b92a00cf
parent38a5f64800b791e9c091998ca8a0e05959d431a8 (diff)
downloadpi-bitcoindev-c9e2aaa7a788d0e79694f7bf96cb15668a6b53c4.tar.gz
pi-bitcoindev-c9e2aaa7a788d0e79694f7bf96cb15668a6b53c4.zip
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
-rw-r--r--ae/f9e48f6e4d7d5614b152ae0885ad677b9f7c80549
1 files changed, 549 insertions, 0 deletions
diff --git a/ae/f9e48f6e4d7d5614b152ae0885ad677b9f7c80 b/ae/f9e48f6e4d7d5614b152ae0885ad677b9f7c80
new file mode 100644
index 000000000..fe837fc4a
--- /dev/null
+++ b/ae/f9e48f6e4d7d5614b152ae0885ad677b9f7c80
@@ -0,0 +1,549 @@
+Return-Path: <anton@etcm.ltd>
+Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id E5E99C0001
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 17 May 2021 23:02:29 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by smtp2.osuosl.org (Postfix) with ESMTP id C779840218
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 17 May 2021 23:02:29 +0000 (UTC)
+X-Virus-Scanned: amavisd-new at osuosl.org
+X-Spam-Flag: NO
+X-Spam-Score: -1.751
+X-Spam-Level:
+X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5
+ tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
+ DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
+ HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
+ autolearn=no autolearn_force=no
+Authentication-Results: smtp2.osuosl.org (amavisd-new);
+ dkim=pass (2048-bit key) header.d=etc-group.com
+Received: from smtp2.osuosl.org ([127.0.0.1])
+ by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id 2ezb0TQ7EOpV
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 17 May 2021 23:02:28 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.8.0
+Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com
+ [IPv6:2a00:1450:4864:20::42c])
+ by smtp2.osuosl.org (Postfix) with ESMTPS id 9BC4740206
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 17 May 2021 23:02:27 +0000 (UTC)
+Received: by mail-wr1-x42c.google.com with SMTP id j14so6325374wrq.5
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 17 May 2021 16:02:27 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=etc-group.com; s=google;
+ h=mime-version:references:in-reply-to:from:date:message-id:subject:to
+ :cc; bh=199WZe/TRxOh+sdUvYjpyTTlmayNlFJM5InlNCRevu8=;
+ b=XwMzqfy+0FAvuGGPZrcf68Leepqc9mShPMdyKUT/pwW/Xtjb+yQRFswwvkPvs5GXuT
+ Q29K3DRN500RED0a+NyODG2NIrXAzoPz9s+oLSAF6KqfjYYE9GnzmfnRBVmky5K7Xe1q
+ jmli59X9+HosrMlB8OMq5xPY203wKji+cEavo3BA8L6a+qhBbQtAi4+DwJzOuZ9SOXRf
+ oEb0i7DWpXQW3NxFcqdyTTeK0VT1de0vaz/kbJgFIjgLWw4AUjZPqczc+PWFhK+oWvwa
+ 2x2IV38p381Euq/vPvOhgXx5Zp8KESaihOiDE6ZyRh7aVAR5prV5RWCUmKOW84KZQNHk
+ 85lA==
+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=199WZe/TRxOh+sdUvYjpyTTlmayNlFJM5InlNCRevu8=;
+ b=PyH2lI/glNDgqHaF1885mCl1Hs23IF43VhEYXf2KNkx8quV5wn9idH1KQhyuJXec3h
+ qFMx59QrE7kDI4+lysePAreBM+6b0JZ8Hgx74qVyre6NEPXZKqHQrsj5QeviQVaFDw1M
+ vXE5OIrUxp8aNL5lQ9K9BG76pX4UutdmUeoOoTRhPEn2wgxA3KRCvucjw9vxCmGF2cyZ
+ GW8LEF8gvCJZIISRBH3P376uNOCPYVXS09nu/rA9FtBABU0NTfdBBdtfPfHdi2BRlZJ/
+ /hCobMX2f/h+8nofbka3SyEvSMMbJsTZRCE9pFgxSW+KDIzwIYWuxlcPrs4XErquP7lv
+ dXpg==
+X-Gm-Message-State: AOAM530giMjU/O8So5Z2LuIZNoqowpIdzP4RY3VA5Q8BajcQRIUDVMn8
+ Gk1zyLMnKOjlV88+8gT1zcuzcjxSG9/y+w2k6ayg/Q==
+X-Google-Smtp-Source: ABdhPJxhA6JDrp1j4tfSCbk8ao7/CxVgoiEjG2FAPophHHLY6ZsQ6tSKSdoiZ807KT0zzEffbsvtqXb1gRMXbgaW6mg=
+X-Received: by 2002:a5d:4c46:: with SMTP id n6mr2494097wrt.95.1621292545794;
+ Mon, 17 May 2021 16:02:25 -0700 (PDT)
+MIME-Version: 1.0
+References: <jawWY4NALDmoikH8U4l9sTFxF54GPGQBFMBfgcI2NhVOmu3kRnsDkhTZ48wQCngfaRn0q6VY0bVlFdBPz9g1PSUoHTN0jmAv97_TPNlcY_I=@protonmail.com>
+ <CAPyV_jAOwQN+Xx4+b7-Oa5jz1C6uZMrEFqg8J=AUm2=P3UCh6Q@mail.gmail.com>
+ <CALeFGL1=_FSDT6TjmbL9N4TkLGvm5cMf9MsfLXT2rn5m2Cea3g@mail.gmail.com>
+In-Reply-To: <CALeFGL1=_FSDT6TjmbL9N4TkLGvm5cMf9MsfLXT2rn5m2Cea3g@mail.gmail.com>
+From: Anton Ragin <anton@etc-group.com>
+Date: Tue, 18 May 2021 00:02:07 +0100
+Message-ID: <CAPyV_jBqeTJQskKnzOwcwH0Byed8E6RLy4qLhQG-aWsH62NbTw@mail.gmail.com>
+To: Keagan McClelland <keagan.mcclelland@gmail.com>
+Content-Type: multipart/alternative; boundary="00000000000044fbe905c28e965c"
+X-Mailman-Approved-At: Tue, 18 May 2021 09:52:40 +0000
+Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes
+ to save 90% of mining energy
+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: Mon, 17 May 2021 23:02:30 -0000
+
+--00000000000044fbe905c28e965c
+Content-Type: text/plain; charset="UTF-8"
+
+>> This is not possible for rather obvious reasons:
+>> 1. transaction sizes cannot be allowed to be unbounded because this
+creates denial of service attacks for the broader network
+>> 2. if the valid certificate set is not unbounded, then centralization
+pressure will mount on the bound between the Nth and N+1th certifier.
+
+>> Finally, all of this would require a rather large consensus change to
+even implement. Given how contentious the proposal of a "choose your
+miner/certifier" is, it is unlikely to gain the necessary support in the
+form of code, review, miner signaling, or user uptake for a UASF.
+
+My original suggestion was to hold an unbounded number of copies of
+asymmetrically-encrypted transactions in the mempool, each of them could be
+decrypted with the key which is owned by a particular miner. Once one of
+them get mined, all other copies are discarded (this can be done by holding
+hashes of transactions in the mempool unencrypted, so once the node sees
+the transaction matching the hash mined - it can discard the other copies
+sharing the same hash).
+
+I agree that that opens the door to potential DoS attack - people can start
+transmitting invalid transactions to perform a DoS attack on the network.
+
+However, the following adaptation of the idea might work: the transaction
+is duly signed and communicated to the mempool, but have an unbonded list
+of certificates of 'preferred' miners. If for within M blocks a preferred
+miner manages to mine the block - fine, if within M blocks it does not
+happen, transaction can be mined by any miner. Additionally, full nodes can
+demand a minimum fee which is dependant on the number of attached
+certificates (e.g. if attaching N certificates makes the transaction
+message 2x the size of normal message, the minimum fee is twice bigger). It
+appears to me, that such M-block delay + list of preferred miners which can
+be arbitrary long, but user pays higher fees if it is unreasonably long,
+does not raise DoS concerns as it does not materially affect the dynamics
+of things how they are right now.
+
+>> If you truly care about only having your transactions mined by "green"
+miners or whatever other qualification you are going after, then this can
+likely be implemented in upper layers as you suggested. You can submit your
+transaction via an overlay network directly to any miners that fit your
+criteria. Since miners operate in a selfish way, it is not in their
+interest to share your transaction with other miners, and the probable case
+is that your transaction will only be included in a block that is signed by
+your preferred authority.
+
+Overlay network is one of the solutions, however community-supported
+functionality of giving some miners a priority as suggested above will
+
+>> It is, in fact, an open forum and everyone is entitled to their view,
+including being dismissive of yours.
+
+Accepted :)
+
+On Mon, May 17, 2021 at 6:28 PM Keagan McClelland <
+keagan.mcclelland@gmail.com> wrote:
+
+> In principle the idea of making your transactions not mineable except by
+> miners who follow some particular practice is something that can and should
+> be discussed. For instance, it could help give economic signals for future
+> soft forks such that users can declare preference in a costly, sybil
+> resistant way.
+>
+> As I understand what you are asking, you want users to be able to issue
+> transactions that can only be included in blocks that are signed by miners
+> whose certificates can be traced back to some set of certificates that the
+> sender has "whitelisted". The trouble here is that in order for this to be
+> an open system, the user would need to be able to include an unbounded
+> number of optional certificates in the transaction itself, otherwise the
+> rest of the network would be unable to validate whether or not the
+> transaction, when included in the block fit the consensus rules or not.
+>
+> This is not possible for rather obvious reasons:
+> 1. transaction sizes cannot be allowed to be unbounded because this
+> creates denial of service attacks for the broader network
+> 2. if the valid certificate set is not unbounded, then centralization
+> pressure will mount on the bound between the Nth and N+1th certifier.
+>
+> Finally, all of this would require a rather large consensus change to even
+> implement. Given how contentious the proposal of a "choose your
+> miner/certifier" is, it is unlikely to gain the necessary support in the
+> form of code, review, miner signaling, or user uptake for a UASF.
+>
+> That said, not all is lost. If you truly care about only having your
+> transactions mined by "green" miners or whatever other qualification you
+> are going after, then this can likely be implemented in upper layers as you
+> suggested. You can submit your transaction via an overlay network directly
+> to any miners that fit your criteria. Since miners operate in a selfish
+> way, it is not in their interest to share your transaction with other
+> miners, and the probable case is that your transaction will only be
+> included in a block that is signed by your preferred authority.
+>
+> I should note though, that you may be waiting forever for your
+> transactions to be mined and your business partners might choose not to do
+> business with you in the future due to delays caused by virtue signaling to
+> nocoiners.
+>
+> > Please don't be dismissive, it is an open forum and everybody is
+> entitled to his/her/its own opinion.
+>
+> It is, in fact, an open forum and everyone is entitled to their view,
+> including being dismissive of yours.
+>
+> > I respectfully submit that people who know how to launch rockets to the
+> sky and beam high-speed internet from the satellites to every place on
+> earth are at least capable of understanding how Bitcoin works. There is
+> even an english expression which reads 'it is not a rocket science' which I
+> think fits especially nicely in this particular case :)
+>
+> No one is contesting that Elon and the rest of the technical staff at
+> Tesla are *capable* of understanding Bitcoin. We are just asserting that,
+> at present, they do not understand the underlying mechanics well enough to
+> give consistent rationale for their choices, and because their public
+> statements reveal either a deep hypocrisy, or deep ignorance in their
+> understanding of Bitcoin.
+>
+> Keagan
+>
+> On Mon, May 17, 2021 at 8:11 AM Anton Ragin via bitcoin-dev <
+> bitcoin-dev@lists.linuxfoundation.org> wrote:
+>
+>> Hello, list
+>>
+>> >Hello centralisation. Might as well just have someone sign miner keys,
+>> and get
+>> >rid of PoW entirely...
+>> >No, it is not centralization -
+>>
+>> No, it is not centralization, as:
+>>
+>> (a) different miners could use different standards / certifications for
+>> 'green' status, there are many already;
+>>
+>>
+>> >> That does not refute the claim at all. Just because you can choose
+>> from multiple centralized authorities, which are well known and can
+>> collude, it does not mean it is decentralized by any reasonable definition
+>> of the term.
+>>
+>> (b) it does not affect stability of the network in a material way, rather
+>> creates small (12.5% of revenue max) incentive to move to green sources of
+>> energy (or buy carbon credits) and get certified - miners who would choose
+>> to run dirty energy will still be able to do so.
+>> and
+>>
+>>
+>> >> Who is to issue these credits? A centralized entity I guess ... There
+>> is no place for such in Bitcoin.
+>>
+>> If I am to concede on the point that *voluntarily* green-status miner
+>> certification is 'centralization', can you please explain *in detail* why
+>> aren't 'bitcoin.org' and GitHub repo similar examples of
+>> 'centralization'? You make a correct point that bitcoin.org and the
+>> GitHub repo are not 'official' things of Bitcoin network, however nowhere
+>> in my proposals on green miner certification I was suggesting to introduce
+>> an 'official' certificate for such a thing. May be I mis-formulated my
+>> ideas, in that case I apologize:
+>>
+>> The only thing which I suggested was to introduce an option to have some
+>> transactions encrypted in the mempool to allow Bitcoin users some control
+>> over who mines their transaction - full stop. Users could then decide how
+>> to use this functionality themselves, and such functionality could have
+>> uses way beyond 'green miners' - for example, some users might prefer to
+>> send their transactions *directly to trusted miners* to prevent certain
+>> quantum computer enabled attacks (e.g. when there is a window of
+>> opportunity to steal coins if you have fast QC when you spend even from
+>> p2phk address). Another example - if users are given some flexibility whom
+>> to send the transactions, they might actually want to steer them away from
+>> huge mining pools such as Antpool to support small independent miners, smth
+>> of this sort - which actually would boost diversity in the network.
+>>
+>> You may or may not agree that climate change is real, or may or may not
+>> agree that Bitcoin energy consumption is a problem - I respectfully submit
+>> it is not the right forum to find truth on these topics. We are discussing
+>> ideas which *might *make Bitcoin a better solution for users who care
+>> about certain things, *without *making it worse for somebody else (like
+>> you, for example - who don't like centralization in any form).
+>>
+>> >> (c) nothing is being proposed beyond what is already possible -
+>> Antpool can go green today, and solicit users to send them signed
+>> transactions directly instead of adding them to a public mempool, under the
+>> pretext that it would make the transfer 'greener'.
+>>
+>> >> And if there was an economic advantage in doing so, miners would quite
+>> likely already implement that. Yet, somehow, they are not doing that.
+>>
+>> Arguments of the sort 'if something could be done or should have been
+>> done - it would be done already' are flawed, in my opinion, as following
+>> the same logic nothing (including Bitcoin itself) should have been done
+>> ever. As a matter of fact, we are working on a green miner initiative with
+>> certain miners, having a call with Hut8 in 20 minutes myself - and I know
+>> that we are not the only ones. Green crypto initiatives are actually
+>> widespread, and the solutions will be popping up soon.
+>>
+>> >> Please stop with the carbon credit nonsense. There is likely no such
+>> thing to exist on a free market and no one is interested in these state
+>> regulations.
+>>
+>> Please read this Wikipedia Article:
+>> https://en.wikipedia.org/wiki/Carbon_offset
+>>
+>> "There are two types of markets for carbon offsets, compliance and
+>> *voluntary*" [emphasis added].
+>>
+>> Voluntary carbon offset markets are actually growing really fast.
+>>
+>> >> Just because a big company is controlled by people who do not
+>> understand Bitcoin, it does not make the issue valid. There are no such
+>> environmental concerns once you understand how Bitcoin and free market
+>> work. Don't help to spread the FUD.
+>>
+>> I respectfully submit that people who know how to launch rockets to the
+>> sky and beam high-speed internet from the satellites to every place on
+>> earth are at least capable of understanding how Bitcoin works. There is
+>> even an english expression which reads 'it is not a rocket science' which I
+>> think fits especially nicely in this particular case :)
+>>
+>> >> Once people stop spreading FUD, the price will likely skyrocket.
+>> Start with yourself please.
+>>
+>> I guess you misinterpret my intentions, I think it doesn't matter what
+>> Bitcoin price is - my personal interest is the widest possible adoption of
+>> blockchain as a peer-to-peer way to transfer value between consenting
+>> individuals free from government control or intervention. Environmental
+>> concerns are real and at least some parts of the community are clearly
+>> interested to at least discuss this matter (e.g. I am not the one who
+>> started this thread).
+>>
+>> Please don't be dismissive, it is an open forum and everybody is entitled
+>> to his/her/its own opinion.
+>> _______________________________________________
+>> bitcoin-dev mailing list
+>> bitcoin-dev@lists.linuxfoundation.org
+>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>>
+>
+
+--00000000000044fbe905c28e965c
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div dir=3D"ltr">&gt;&gt; This is not possible for rather=
+=C2=A0obvious reasons:<br></div><div>&gt;&gt; 1. transaction sizes cannot b=
+e allowed to be unbounded because this creates denial of service attacks fo=
+r the broader network</div><div>&gt;&gt; 2. if the valid certificate set is=
+ not unbounded, then centralization pressure will mount on the bound betwee=
+n the Nth and N+1th certifier.</div><div><br></div><div>&gt;&gt; Finally, a=
+ll of this would require a rather large consensus change to even implement.=
+ Given how contentious the proposal of a &quot;choose your miner/certifier&=
+quot; is, it is unlikely to gain the necessary support in the form of code,=
+ review, miner signaling, or user uptake for a UASF.</div><div><br></div><d=
+iv>My original suggestion was to hold an unbounded number of copies of asym=
+metrically-encrypted transactions in the mempool, each of them could be dec=
+rypted with the key which is owned by a particular miner. Once one of them =
+get mined, all other copies are discarded (this can be done by holding hash=
+es of transactions in the mempool unencrypted, so once the node sees the tr=
+ansaction matching the hash mined - it can discard the other copies sharing=
+ the same hash).</div><div><br></div><div>I agree that that opens the door =
+to potential DoS attack - people can start transmitting invalid transaction=
+s to perform a DoS attack on the network.=C2=A0</div><div><br></div><div>Ho=
+wever, the following adaptation of the idea might work: the transaction is =
+duly signed and communicated to the mempool, but have an unbonded list of c=
+ertificates of &#39;preferred&#39; miners. If for within M blocks a preferr=
+ed miner manages to mine the block - fine, if within M blocks it does not h=
+appen, transaction can be mined by any miner. Additionally, full nodes can =
+demand a minimum fee which is dependant on the number of attached certifica=
+tes (e.g. if attaching N certificates makes the transaction message 2x the =
+size of normal message, the minimum fee is twice bigger). It appears to me,=
+ that such M-block delay=C2=A0+ list of preferred miners which can be arbit=
+rary long, but user pays higher fees if it is unreasonably long, does not r=
+aise DoS concerns as it does not materially affect the dynamics of things h=
+ow they are right now.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">&gt=
+;&gt;=C2=A0
+
+If you truly care about only having your transactions mined by &quot;green&=
+quot; miners or whatever other qualification you are going after, then this=
+ can likely be implemented in upper layers as you suggested. You can submit=
+ your transaction via an overlay network directly to any miners that fit yo=
+ur criteria. Since miners operate in a selfish way, it is not in their inte=
+rest to share your transaction with other miners, and the probable case is =
+that your transaction will only be included in a block that is signed by yo=
+ur preferred authority.
+
+</div><div dir=3D"ltr"><br></div><div>Overlay network is one of the solutio=
+ns, however community-supported functionality of giving some miners a prior=
+ity as suggested above will=C2=A0</div><div><br></div><div>&gt;&gt;=C2=A0
+
+It is, in fact, an open forum and everyone is entitled to their view, inclu=
+ding being dismissive of yours.
+
+</div><div><br></div><div>Accepted :)</div><br><div class=3D"gmail_quote"><=
+div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 17, 2021 at 6:28 PM Keagan=
+ McClelland &lt;<a href=3D"mailto:keagan.mcclelland@gmail.com">keagan.mccle=
+lland@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
+tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
+ding-left:1ex"><div dir=3D"ltr">In principle the idea of making your transa=
+ctions not mineable except by miners who follow some particular practice is=
+ something that can and should be discussed. For instance, it could help gi=
+ve economic signals for future soft forks such that users can declare prefe=
+rence in a costly, sybil resistant way.<div><br></div><div>As I understand =
+what you are asking, you want users to be able to issue transactions that c=
+an only be included in blocks that are signed by miners whose certificates =
+can be traced back to some set of certificates that the sender has &quot;wh=
+itelisted&quot;. The trouble here is that in order for this to be an open s=
+ystem, the user would need to be able to include an unbounded number of opt=
+ional certificates in the transaction itself, otherwise the rest of the net=
+work would be unable to validate whether or not the transaction, when inclu=
+ded in the block fit the consensus rules or not.</div><div><br></div><div>T=
+his is not possible for rather=C2=A0obvious reasons:</div><div>1. transacti=
+on sizes cannot be allowed to be unbounded because this creates denial of s=
+ervice attacks for the broader network</div><div>2. if the valid certificat=
+e set is not unbounded, then centralization pressure will mount on the boun=
+d between the Nth and N+1th certifier.</div><div><br></div><div>Finally, al=
+l of this would require a rather large consensus change to even implement. =
+Given how contentious the proposal of a &quot;choose your miner/certifier&q=
+uot; is, it is unlikely to gain the necessary support in the form of code, =
+review, miner signaling, or user uptake for a UASF.</div><div><br></div><di=
+v>That said, not all is lost. If you truly care about only having your tran=
+sactions mined by &quot;green&quot; miners or whatever other qualification =
+you are going after, then this can likely be implemented in upper layers as=
+ you suggested. You can submit your transaction via an overlay network dire=
+ctly to any miners that fit your criteria. Since miners operate in a selfis=
+h way, it is not in their interest to share your transaction with other min=
+ers, and the probable case is that your transaction will only be included i=
+n a block that is signed by your preferred authority.</div><div><br></div><=
+div>I should note though, that you may be waiting forever for your transact=
+ions to be mined and your business partners might choose not to do business=
+ with you in the future due to delays caused by virtue signaling to nocoine=
+rs.</div><div><br></div><div>&gt; Please don&#39;t be dismissive, it is an =
+open forum and everybody is entitled to his/her/its own opinion.=C2=A0<br><=
+/div><div><br></div><div>It is, in fact, an open forum and everyone is enti=
+tled to their view, including being dismissive of yours.</div><div><br></di=
+v><div>&gt; I respectfully submit that people who know how to launch rocket=
+s to the sky and beam high-speed internet from the satellites to every plac=
+e on earth are at least capable of understanding how Bitcoin works. There i=
+s even an english expression which reads &#39;it is not a rocket science&#3=
+9; which I think fits especially nicely in this particular case :)</div><di=
+v><br></div><div>No one is contesting that Elon and the rest of the technic=
+al staff at Tesla are *capable* of understanding Bitcoin. We are just asser=
+ting that, at present, they do not understand the underlying mechanics well=
+ enough to give consistent=C2=A0rationale for their choices, and because th=
+eir public statements reveal either a deep hypocrisy, or deep ignorance in =
+their understanding of Bitcoin.</div><div><br></div><div>Keagan</div></div>=
+<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon=
+, May 17, 2021 at 8:11 AM Anton Ragin via bitcoin-dev &lt;<a href=3D"mailto=
+:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
+.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
+te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
+);padding-left:1ex"><div dir=3D"ltr"><div>Hello, list</div><div><br></div><=
+div><blockquote type=3D"cite"><div dir=3D"ltr"><div><div>&gt;Hello centrali=
+sation. Might as well just have someone sign miner keys, and get<br></div><=
+div>&gt;rid of PoW entirely...<br></div></div><div>&gt;No, it is not centra=
+lization -=C2=A0<br></div><div><br></div><div>No, it is not centralization,=
+ as:<br></div><div><br></div><div>(a) different miners could use different =
+standards / certifications for &#39;green&#39; status, there are many alrea=
+dy;<br></div></div></blockquote><div><br></div><div>&gt;&gt; That does not =
+refute the claim at all. Just because you can choose from multiple centrali=
+zed authorities, which are well known and can collude, it does not mean it =
+is decentralized by any reasonable definition of the term.</div><div><br></=
+div><div><blockquote type=3D"cite"><div dir=3D"ltr"><div>(b)
+ it does not affect stability of the network in a material way, rather
+creates small (12.5% of revenue max) incentive to move to green sources
+of energy (or buy carbon credits) and get certified - miners who would
+choose to run dirty energy will still be able to do so.<br></div><div><div>=
+and<br></div></div></div></blockquote><div><br></div><div>&gt;&gt; Who is t=
+o issue these credits? A centralized entity I guess ... There is no place f=
+or such in Bitcoin.</div></div><div><br></div><div>If I am to concede on th=
+e point that <u>voluntarily</u> green-status miner certification is &#39;ce=
+ntralization&#39;, can you please explain <i>in detail</i>=C2=A0why aren&#3=
+9;t &#39;<a href=3D"http://bitcoin.org" target=3D"_blank">bitcoin.org</a>&#=
+39; and GitHub repo similar examples of &#39;centralization&#39;? You make =
+a correct point that <a href=3D"http://bitcoin.org" target=3D"_blank">bitco=
+in.org</a> and the GitHub repo are not &#39;official&#39; things of Bitcoin=
+ network, however nowhere in my proposals on green miner certification I wa=
+s suggesting to introduce an &#39;official&#39; certificate for such a thin=
+g. May be I mis-formulated my ideas, in that case I apologize:</div><div><b=
+r></div><div>The only thing which I suggested was to introduce an option to=
+ have some transactions encrypted in the mempool to allow Bitcoin users som=
+e control over who mines their transaction - full stop. Users could then de=
+cide how to use this functionality themselves, and such functionality could=
+ have uses way beyond &#39;green miners&#39; - for example, some users migh=
+t prefer to send their transactions <i>directly to trusted miners</i> to pr=
+event certain quantum computer enabled attacks (e.g. when there is a window=
+ of opportunity to steal coins if you have fast QC when you spend even from=
+ p2phk address). Another example - if users are given some flexibility whom=
+ to send the transactions, they might actually want to steer them away from=
+ huge mining pools such as Antpool to support small independent miners, smt=
+h of this sort - which actually would boost diversity in the network.</div>=
+<div><br></div><div>You may or may not agree that climate change is real, o=
+r may or may not agree that Bitcoin energy consumption is a problem - I res=
+pectfully submit it is not the right forum to find truth on these topics. W=
+e are discussing ideas which <i>might </i>make Bitcoin a better solution fo=
+r users who care about certain things, <i>without </i>making it worse for s=
+omebody else (like you, for example - who don&#39;t like centralization in =
+any form).</div><div><br></div><div>&gt;&gt; (c)
+ nothing is being proposed beyond=C2=A0what is already possible - Antpool c=
+an
+ go green today, and solicit users to send them signed transactions
+directly instead of adding them to a public mempool, under the pretext
+that it would make the transfer &#39;greener&#39;.</div><div><br></div><div=
+>&gt;&gt; And if there was an economic advantage in doing so, miners would =
+quite likely already implement that. Yet, somehow, they are not doing that.=
+</div><div><br></div><div>Arguments of the sort &#39;if something could be =
+done or should have been done - it would be done already&#39; are flawed, i=
+n my opinion, as following the same logic nothing (including Bitcoin itself=
+) should have been done ever. As a matter of fact, we are working on a gree=
+n miner initiative with certain miners, having a call with Hut8 in 20 minut=
+es=C2=A0myself - and I know that we are not the only ones. Green crypto ini=
+tiatives are actually widespread, and the solutions will be popping up soon=
+.</div><div><br></div><div>&gt;&gt;=C2=A0
+
+Please stop with the carbon credit nonsense. There is likely no such thing =
+to exist on a free market and no one is interested in these state regulatio=
+ns.
+
+</div><div><br></div><div>Please read this Wikipedia Article:=C2=A0<a href=
+=3D"https://en.wikipedia.org/wiki/Carbon_offset" target=3D"_blank">https://=
+en.wikipedia.org/wiki/Carbon_offset</a></div><div><br></div><div>&quot;<spa=
+n style=3D"color:rgb(32,33,34);font-family:sans-serif;font-size:14px">There=
+ are two types of markets for carbon offsets, compliance and <u>voluntary</=
+u>&quot; [emphasis added].</span></div><div><span style=3D"color:rgb(32,33,=
+34);font-family:sans-serif;font-size:14px"><br></span></div><div><span styl=
+e=3D"color:rgb(32,33,34);font-family:sans-serif;font-size:14px">Voluntary c=
+arbon offset markets are actually growing really fast.</span></div><div><sp=
+an style=3D"color:rgb(32,33,34);font-family:sans-serif;font-size:14px"><br>=
+</span></div><div><span style=3D"color:rgb(32,33,34);font-family:sans-serif=
+;font-size:14px">&gt;&gt;=C2=A0</span>Just because a big company is control=
+led by people who do not understand Bitcoin, it does not make the issue val=
+id. There are no such environmental concerns once you understand how Bitcoi=
+n and free market work. Don&#39;t help to spread the FUD.</div><div><br></d=
+iv><div>I respectfully submit that people who know how to launch rockets to=
+ the sky and beam high-speed internet from the satellites to every place on=
+ earth are at least capable of understanding how Bitcoin works. There is ev=
+en an english expression which reads &#39;it is not a rocket science&#39; w=
+hich I think fits especially nicely in this particular case :)</div><div><b=
+r></div><div>&gt;&gt;=C2=A0
+
+Once people stop spreading FUD, the price will likely skyrocket. Start with=
+ yourself please.
+
+</div><div><br></div><div>I guess you misinterpret my intentions, I think i=
+t doesn&#39;t matter what Bitcoin price is - my personal interest is the wi=
+dest possible adoption of blockchain as a peer-to-peer way to transfer valu=
+e between consenting individuals free from government control or interventi=
+on. Environmental concerns are real and at least some parts of the communit=
+y are clearly interested to at least discuss this matter (e.g. I am not the=
+ one who started this thread).</div><div><br></div><div>Please don&#39;t be=
+ dismissive, it is an open forum and everybody is entitled to his/her/its o=
+wn opinion.=C2=A0</div></div></div>
+_______________________________________________<br>
+bitcoin-dev mailing list<br>
+<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
+bitcoin-dev@lists.linuxfoundation.org</a><br>
+<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
+rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
+man/listinfo/bitcoin-dev</a><br>
+</blockquote></div>
+</blockquote></div></div>
+
+--00000000000044fbe905c28e965c--
+