Date: Mon, 11 Oct 2021 18:03:16 +0200 (CEST)
From: Prayank <prayank@tutanota.de>
To: Michael Folkson <michaelfolkson@gmail.com>
Message-ID: <Mlk5-NX--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_1360451_2137504804.1633968196164"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On the regularity of soft forks
Precedence: list

------=_Part_1360451_2137504804.1633968196164
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Michael,

Agree with almost everything.

> Miner signaling is a tool for signaling readiness. It is not voting for the soft fork or expressing support for the soft fork. There should not be any attempt to facilitate miner signaling until there is sufficient community consensus (the mining community is a subset of the community) on the soft fork. 

This is really important which gets ignored. I wish there was a way to solve this problem in a way that it is not misinterpreted by users.

During signalling for taproot, there were lots of users in different communities that believed miners are voting for taproot and we need some percentage of miners to agree before making any changes in Bitcoin. It was not just non-technical users but few mining pools, exchanges etc. also considered miners signaling as some voting process.

Best I could do at that moment was share this link: https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/

However I am sure there are lot of people who still think miners vote during signaling. Opinions of few developers on MASF vs UASF also adds more confusion to this thing. I could not think of any solution to solve this problem.
-- 
Prayank

A3B1 E430 2298 178F

------=_Part_1360451_2137504804.1633968196164
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>Hi Michael,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Agr=
ee with almost everything.<br></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">&gt; Miner signaling is a tool for signaling readiness. It is not vo=
ting for the soft fork or expressing support for the soft fork. There shoul=
d not be any attempt to facilitate miner signaling until there is sufficien=
t community consensus (the mining community is a subset of the community) o=
n the soft fork. <br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Th=
is is really important which gets ignored. I wish there was a way to solve =
this problem in a way that it is not misinterpreted by users.<br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">During signalling for taproot, th=
ere were lots of users in different communities that believed miners are vo=
ting for taproot and we need some percentage of miners to agree before maki=
ng any changes in Bitcoin. It was not just non-technical users but few mini=
ng pools, exchanges etc. also considered miners signaling as some voting pr=
ocess.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Best I could =
do at that moment was share this link: https://bitcoin.stackexchange.com/qu=
estions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/<br=
></div><div><br>However I am sure there are lot of people who still think m=
iners vote during signaling. Opinions of few developers on MASF vs UASF als=
o adds more confusion to this thing. I could not think of any solution to s=
olve this problem.</div><div dir=3D"auto"><br></div><div>-- <br></div><div>=
Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></=
div>  </body>
</html>

------=_Part_1360451_2137504804.1633968196164--