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
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
Return-Path: <melvincarvalho@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id E1E78C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Mar 2021 11:06:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id C89B74EBD4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Mar 2021 11:06:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 96XZPOurHjhC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Mar 2021 11:06:12 +0000 (UTC)
X-Greylist: delayed 00:38:11 by SQLgrey-1.8.0
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com
[IPv6:2607:f8b0:4864:20::d31])
by smtp4.osuosl.org (Postfix) with ESMTPS id 2F9654D10E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Mar 2021 11:06:12 +0000 (UTC)
Received: by mail-io1-xd31.google.com with SMTP id u8so29176373ior.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 04 Mar 2021 03:06:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=EBprI8bu507DT7oNwYm/DRAQEWBOqf0M1hnGjnn8UY4=;
b=l3uUvtZLbqYo8Jc2FkKf1ha/vsm4YJW9JfBpm/Dhv+Maaf5J7hpIpLXCmLovSnMGq4
LQFjm7Y9JWjtJXjZiEcSaXUlKW6jBneAJLqzidw/D/zXX8e5g3rJHI+LJqtzzkbgFTE6
YXXUK4KrBeYkxIXMRVpjmsgQfPr69tCTueWMEwvgChIWWDwls0OkAnpX3bA2N2zXYXzV
SDuWqte7W3LVrJoWusVfFKX3aDLE+u/1MWm6JqDQ78QecK2aaAfredztUIAGieaURnDC
gv5T42lHcKtV1QGlxL04L2GaFtfNnNRhe5/P9cl7i4prQoaYYVh7pT9hRvGF+7DtiAqv
0mag==
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;
bh=EBprI8bu507DT7oNwYm/DRAQEWBOqf0M1hnGjnn8UY4=;
b=oXoebJfBVQqOxrC3qvaHnkz7qS7MjxT7DZqhpMsPdP9vGbpjd9G+q4gkOCMvIv+/X2
QFgsjA8xmR9fgVfLo2+Q1KdMpfqfexd/neHoMrPkUSPsKjEW6tDAJZ4T/ptXJxplViDB
OqOpajXWLdsRkS9CHPRghsIJ/Jki2QUG3Yp2kMmWLQr7p3EWhTTpVHDyRedYaQ5GVnZH
GoolCbR6MTctCS1T0L8H/vkL1dDUhwq+lu6qyDNbaivm+QoNTRFsFPEUfrJiQS1W9+Uv
ARmY7sRl33ZPrnXx4qFQICU5F/bnloW7CWsHXFlDHqB9/0Zl3JWq+JxKO/5wyC6UoMFb
Gu1w==
X-Gm-Message-State: AOAM533PsSS9MgILkG4A5jC461ynswED6WDJnwzEhx7IX6wVbGlvHmCk
dU/yfEEuEi6rpJcKbtTUPq40TmtcvEdlOtgeJ9f8uzut4vM=
X-Google-Smtp-Source: ABdhPJz441EA8furdQOYpaxQ2dQ6tm4JDApwyxWy26QVT02tHI9Awax17c4MHEssfxHfID+Nr8ltUaED3rkwrUK6okk=
X-Received: by 2002:a5d:9644:: with SMTP id d4mr2858297ios.54.1614849952946;
Thu, 04 Mar 2021 01:25:52 -0800 (PST)
MIME-Version: 1.0
References: <CAJXtxW=Rix7Q-ra=CADsB00r13pr5DC_76QMGcYrt74FxAWEbQ@mail.gmail.com>
In-Reply-To: <CAJXtxW=Rix7Q-ra=CADsB00r13pr5DC_76QMGcYrt74FxAWEbQ@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Thu, 4 Mar 2021 10:25:41 +0100
Message-ID: <CAKaEYhKszo_0KHdMzmFtBVO2sL5Bh382e+koAL-0KMEtR29Opg@mail.gmail.com>
To: John Rand <johnqrand@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cf9e0605bcb28d12"
X-Mailman-Approved-At: Thu, 04 Mar 2021 11:23:13 +0000
Subject: Re: [bitcoin-dev] activation mechanism considerations
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: Thu, 04 Mar 2021 11:06:14 -0000
--000000000000cf9e0605bcb28d12
Content-Type: text/plain; charset="UTF-8"
On Thu, 4 Mar 2021 at 10:07, John Rand via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Consensus is important for both taproot and separately for the activation
> mechanism. There are more soft-forks that Bitcoin will need, so it is
> important to achieve positive progress on the activation topic also, not
> get impatient and rush something ill-considered. Not all future soft-forks
> maybe as widely supported as taproot, and yet it could become existentially
> critical that Bitcoin prevails in achieving a future upgrade in dramatic
> circumstances, even against powerful interests counter to Bitcoin user and
> investors interests. We should treat the activation topic in a considered
> way and with decorum, provide tight non-emotive reasoning devoid of
> frustration and impatience. This is a low drama and convenient time to
> incrementally improve activation. People have varied views about the
> deciding factor, or even which factors resulted in segwit activating after
> BIP 141 failed using BIP 9. We do not have to solve everything in one
> step, incremental improvement is good, for complex unintuitive topics, to
> learn as we go - and it should not be hard to do less badly than what
> transpired leading up to BIP 148 and BIP 91. Failure to upgrade if
> permanent, or demoralizing to protocol researchers could be a systemic risk
> in itself as there are more upgrades Bitcoin will need. We are not Ents
> but we should use our collective ingenuity to find an incremental
> improvement for activation.
>
Great high level thoughts
The Ents themselves were created in Tolkien's fork of Shakespeare, when he
was frustrated to learn that trees didnt actually march :)
Having followed standards for 10+ years consensus can be tricky
IIRC last time with segwit there was a straw poll in the wiki where devs
could express leanings in an informal, async way. Something like that
could be of value.
There's an insightful spec written at the IETF "On Consensus and Humming in
the IETF", then IMHO is worth reading
https://tools.ietf.org/html/rfc7282
That said, if we could find an incorruptible machine that could gather the
highest fee tx from the mempool and post it every 10 minutes, bitcoin would
largely run itself. So, while understanding the gravity of each change, we
could perhaps have the mindset that there are a finite number, such that
when complete bitcoin will move to an endgame where for the user it 'just
works', much like the internet. If devs and changes are needed less, that
could be viewed as a sign of success. This is a hand wavy way of saying
that forks could potentially be a diminishing issue over time
Just my 2 satoshis
>
> John R
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000cf9e0605bcb28d12
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, 4 Mar 2021 at 10:07, John Ran=
d via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Consensus is impo=
rtant for both taproot and separately for the activation mechanism.=C2=A0 T=
here are more soft-forks that Bitcoin will need, so it is important to achi=
eve positive progress on the activation topic also, not get impatient and r=
ush something ill-considered.=C2=A0 Not all future soft-forks maybe as wide=
ly supported as taproot, and yet it could become existentially critical tha=
t Bitcoin prevails in achieving a future upgrade in dramatic circumstances,=
even against powerful interests counter to Bitcoin user and investors inte=
rests.=C2=A0 We should treat the activation topic in a considered way and w=
ith decorum, provide tight non-emotive reasoning devoid of frustration and =
impatience.=C2=A0 This is a low drama and convenient time to incrementally =
improve activation.=C2=A0 People have varied views about the deciding facto=
r, or even which factors resulted in segwit activating after BIP 141 failed=
using BIP 9.=C2=A0 We do not have to solve everything in one step, increme=
ntal improvement is good, for complex unintuitive topics, to learn as we go=
- and it should not be hard to do less badly than what transpired leading =
up to BIP 148 and BIP 91.=C2=A0 Failure to upgrade if permanent, or demoral=
izing to protocol researchers could be a systemic risk in itself as there a=
re more upgrades Bitcoin will need.=C2=A0 We are not Ents but we should use=
our collective ingenuity to find an incremental improvement for activation=
.</div></blockquote><div><br></div><div>Great high level thoughts</div><div=
><br></div><div>The Ents themselves were created in Tolkien's fork of S=
hakespeare, when he was frustrated to learn that trees didnt actually march=
:)<br></div><div><br></div><div>Having followed standards for 10+ years co=
nsensus can be tricky</div><div><br></div><div>IIRC last time with segwit t=
here was a straw poll in the wiki where devs could express leanings in an i=
nformal, async way.=C2=A0 Something like that could be of value.<br></div><=
div><br></div><div>There's an insightful spec written at the IETF "=
;On Consensus and Humming in the IETF", then IMHO is worth reading<br>=
</div><div><br></div><div><a href=3D"https://tools.ietf.org/html/rfc7282">h=
ttps://tools.ietf.org/html/rfc7282</a></div><div><br></div><div>That said, =
if we could find an incorruptible machine that could gather the highest fee=
tx from the mempool and post it every 10 minutes, bitcoin would largely ru=
n itself.=C2=A0 So, while understanding the gravity of each change, we coul=
d perhaps have the mindset that there are a finite number, such that when c=
omplete bitcoin will move to an endgame where for the user it 'just wor=
ks', much like the internet.=C2=A0 If devs and changes are needed less,=
that could be viewed as a sign of success.=C2=A0 This is a hand wavy way o=
f saying that forks could potentially be a diminishing issue over time<br><=
/div><div><br></div><div>Just my 2 satoshis<br></div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><br=
></div></div><div>John R</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></div>
--000000000000cf9e0605bcb28d12--
|