path: root/ae/f9e48f6e4d7d5614b152ae0885ad677b9f7c80

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--