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
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
Return-Path: <prayank@tutanota.de>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5DCF0C002F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 17:22:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 3F01E40262
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 17:22:09 +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, 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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=tutanota.de
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 v3sC6Z_6SQew
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 17:22:08 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 4C54F4020B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Jan 2022 17:22:08 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
by w1.tutanota.de (Postfix) with ESMTP id 3141BFBF517;
Tue, 18 Jan 2022 17:22:05 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1642526525;
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=gWFrQjfr+fOLoceMu1bWhOsf6+TmB8hFKiUapxkru98=;
b=xV0nngW27DB4TeKB09rMcyD8G45fHhxVsPXno/Rmc66ou2V+nzn4f2vDUjI/ymdX
CLy7oPqsJ7bWnh2g1Jkzu+Ymo1OvoiZwoONXG/R3/8g1TztQ89fNU1FFePflP2Lo2KD
y3pAInHY96QDdKAqknBiK+vgbUfkTNCnGfCTm/5CJRChbkMPJfyKojzSVHH6hD2KTHh
BX8pCBCmr2QQvL78/YafofXK+wrWGylENiVMyLnMMzowOD0FXSwa04DhR9tEn89LLaS
797Hkq1p4Lcx5VgeuNFowtknZu37ojzk+Qf59huFLkbBx/upiwrthZk7+Nge4VhHejZ
o05aiB0XsA==
Date: Tue, 18 Jan 2022 18:22:05 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Billy Tetrud <billy.tetrud@gmail.com>
Message-ID: <MtiCR2x--7-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_9089_356154592.1642526525185"
X-Mailman-Approved-At: Tue, 18 Jan 2022 19:21:18 +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: Tue, 18 Jan 2022 17:22:09 -0000
------=_Part_9089_356154592.1642526525185
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
> We should strive to one day get to a point where the bitcoin consensus isn't updating at all.
That day is nowhere near IMO and maybe we won't see it in my lifetime.
> Perhaps we should come to a consensus as a consensus as a community what the minimum time between soft forks should be, and just as importantly, what the minimum time between finalized consensus-change implementation and when we decide community consensus has been achieved.
This is not possible in a decentralized network like Bitcoin and makes no sense. Soft forks can/should be done as and when required. This does not mean we do them often but if a change makes sense, looks ready, got enough consensus, reviewed properly etc. then timing doesn't really matter in every case.
> Activating multiple consensus changes in a bundle is far safer than having multiple separate in-flight soft forks at once.
This is not true. More changes bundled require more review and still more probability to have bugs. Security is always about keeping things simple.
> One solution is that we could be a lot more direct about how decisions are made. There's been a lot of rhetoric around UASF and how the economic majority is really who's running the show.
BIP 8 with LOT=TRUE was a better activation mechanism option in Taproot but some influential developers wrote its misleading, unsafe etc. on social media so you can call me negative at this moment however I have realized the truth is really sad and we can't blindly follow some people. There are lot of people who will tell you bad things about UASF and how speedy trial is the best thing Bitcoin has ever experienced.
Michael Folkson also had some opinion in activation mechanism IIRC,
--
Prayank
A3B1 E430 2298 178F
------=_Part_9089_356154592.1642526525185
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>> We should strive to one day get to a point where the bitcoin cons=
ensus isn't updating at all.<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">That day is nowhere near IMO and maybe we won't see it in my life=
time.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">> Perhaps w=
e should come to a consensus as a consensus as a community what the minimum=
time between soft forks should be, and just as importantly, what the minim=
um time between finalized consensus-change implementation and when we decid=
e community consensus has been achieved.<br></div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">This is not possible in a decentralized network like B=
itcoin and makes no sense. Soft forks can/should be done as and when requir=
ed. This does not mean we do them often but if a change makes sense, looks =
ready, got enough consensus, reviewed properly etc. then timing doesn't rea=
lly matter in every case.<br></div><div dir=3D"auto"><br></div><div dir=3D"=
auto">> Activating multiple consensus changes in a bundle is far safer t=
han having multiple separate in-flight soft forks at once.<br></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">This is not true. More changes bundl=
ed require more review and still more probability to have bugs. Security is=
always about keeping things simple.<br></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">> One solution is that we could be a lot more direct ab=
out how decisions are made. There's been a lot of rhetoric around UASF and =
how the economic majority is really who's running the show.<br></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">BIP 8 with LOT=3DTRUE was a better =
activation mechanism option in Taproot but some influential developers wrot=
e its misleading, unsafe etc. on social media so you can call me negative a=
t this moment however I have realized the truth is really sad and we can't =
blindly follow some people. There are lot of people who will tell you bad t=
hings about UASF and how speedy trial is the best thing Bitcoin has ever ex=
perienced.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Michael F=
olkson also had some opinion in activation mechanism IIRC,<br></div><div di=
r=3D"auto"><br></div><div><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_9089_356154592.1642526525185--
|
