1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
Return-Path: <prayank@tutanota.de>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id BE37BC000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Oct 2021 16:03:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 9F949816F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Oct 2021 16:03:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=tutanota.de
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Rr3vduknJoKP
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Oct 2021 16:03:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
by smtp1.osuosl.org (Postfix) with ESMTPS id 5C6E680F6D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Oct 2021 16:03:19 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
by w1.tutanota.de (Postfix) with ESMTP id 2C34EFBF84C;
Mon, 11 Oct 2021 16:03:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1633968196;
s=s1; d=tutanota.de;
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender;
bh=6Bc+MgE51oNetFwTsgk8RZuN96t1TSCobbsWhCXNdf4=;
b=Q70M/0YEF7CH/XJAiJjgXkEHVEEz63hvsx+Hdbt4GqOZ4jvr+TUnvgf6T/ZH7xs6
eprK6Qj15p21fPgUVsonAmxojIOndeB2MbFJxUk7y+5gp2PwaDiRqhpi+lWQllpROFS
MPS72HUrFGp8aUcE25SSeG/a6ho18g+H4Sqj7wG0MnWnAsMNNPfKDSol5B2gRFMfjcr
729Qh/z4iNRELsrMY+mk2ALvZJ2O+R1JoT/DwPVCRNjzl+BjmSfJPyusHBBrF1y9/da
rT2jDUoX45v52X2SCAdk/D+IHYcVF1rKuQAYsUM5nYbqEZSuKJB/ly2sKaH6AbfFTcD
avjohN0nrg==
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"
X-Mailman-Approved-At: Tue, 12 Oct 2021 15:34:37 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On the regularity of soft forks
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, 11 Oct 2021 16:03:21 -0000
------=_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">> 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--
|
