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
|
Return-Path: <matthewonthemoon@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 64B8AC0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 22:13:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 58ED586CAF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 22:13:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Gz8vNiYNshE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 22:13:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com
[209.85.218.44])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 3651186A2F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 22:13:13 +0000 (UTC)
Received: by mail-ej1-f44.google.com with SMTP id u20so15682368ejb.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Feb 2021 14:13:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=F/KThvQREzQSqTjECG31nApt3RU2wnLEQ5xpCNpNJNQ=;
b=o/497dgr5/kBXI3ODNqmtgiHXPGv1Mfig0Zb1lNqJRyesUnyuHLCCQHvHJ6I3OSy3K
+qCBd50asnAX3FqrRCWwMCo6ISQsnpYuJKU7aQGuOJUDkNGTHnYHMrlTVKeyb8RjuXSE
2fFLLJsBX9V6Ajomg5fQZYztRxF93qBo91o+GBohrKR5sVhIVVJFMetOI7WWFAyL8Y4M
z1oMPtBB2Xl4J3pTWEu7FUCHJwIlrJ7715NA1ICwj+cex4+ATlXo1qlmu0XgyqVO57Tm
UFr1zXjD+6jk8XGIfSNL0OsAz2eH6cIVh8zMGvyfJWjvOeKStNhmRmiTi9hd2V0aRdql
+YZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=F/KThvQREzQSqTjECG31nApt3RU2wnLEQ5xpCNpNJNQ=;
b=g5LQ0nSpXmY19qOS3hISeoTLCjKj7G4MxnUzbOJ6NTS+z17tb+LJKkw8ljKLfKuapv
6y5XL9cu/kAHd/kgNhfgqrgVMoY4vRIc2TDA4g9VhgEIvxSrt+zkX6Jwr9c/zxkze9kp
1rttpHgmR6zzAOO0clxrhRW2ho0hmOa5Iml8wtQejFDWYjQ2WxwLy5tj5yPJ/8Y4+vMA
fu2yKgL6pkU53iyAjYt1zWb96ZMKeD3vW/BKZ2UfCDi/FA/7ctKgAY4F7TC0DJPQ5g9q
ZAb1p6T0sLOyF+5kIYUBgTAkvu061u6R6UHbU24IysKJeZBkLN8DHMpi3FdEtez5oHkV
cjhQ==
X-Gm-Message-State: AOAM531pDAo9QrScRNUmDRrpDXAx6sKMAG0Db+TRGZm/ccgHn9l90Kgp
v0heuPPV3AgXXv79xllOV744DPZaJ0lxwDWAdNAhthmO
X-Google-Smtp-Source: ABdhPJyVePvQ1O6aV3u9pbW7L3+NupXYMlZI0xhR7r+CxXb+432vCrEGSL6HLE01l8Ap8/9vhzzzu4qV9uFHaltnwTM=
X-Received: by 2002:a17:906:958b:: with SMTP id
r11mr10461856ejx.23.1613772731251;
Fri, 19 Feb 2021 14:12:11 -0800 (PST)
MIME-Version: 1.0
From: Matt Hill <matthewonthemoon@gmail.com>
Date: Fri, 19 Feb 2021 15:12:00 -0700
Message-ID: <CABVK+EUVw7S=oA0sLC3iQUBrUY6G8FFSPQf_NkToPSkJhLM=1w@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000064fdc505bbb7be08"
X-Mailman-Approved-At: Fri, 19 Feb 2021 22:43:06 +0000
Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
lockinontimeout (LOT)
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: Fri, 19 Feb 2021 22:13:17 -0000
--00000000000064fdc505bbb7be08
Content-Type: text/plain; charset="UTF-8"
Good day all, this is my first post to this mailing list. Per Adam's
comment below:
> given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.
Both here and elsewhere, the debate taking place is around the manner of
Taproot activation, not whether or not Taproot should be activated. The
latter seems to have widespread support. Given this favorable environment,
it seems to me this is an incredible opportunity for the developer
contingency to "take the high road" while also minimizing time to Taproot
activation using political incentives. By offering power on the left hand
to miners and and power on the right to users, neither of whom is
expressing disapproval of activation, but both of whom are able to activate
without the consent of the other, both are incentivized to signal
activation as quickly as possible to emerge as the "group that did it". All
that must be done is to include a LOT=true option to Bitcoin Core that
carries a default of LOT=false. Miners can activate at any time, users can
signal their intent to activate should miners renege, and developers emerge
as politically neutral in the eyes of both.
Extrapolating a bit, I contend this expanded agency of full node
operatorship may result in more users running a full node, which is good
and healthy. From a miner's point of view, more full nodes only increases
the likelihood of future UASFs, and so they are even further incentivized
to expedite Taproot activation. Perhaps this is a stretch, perhaps not.
To summarize: (1) this positions developers as neutral facilitators who
deferred power to the other contingencies; (2) we may see a rise in the
popularity of running a full node and the number of full node operators;
(3) miners are incentivized to activate quickly to avoid being perceived as
the "bad guys" and to avoid the spread of full nodes; and (4) even if
miners do not activate, users can organize a UASF in a grass-roots way.
Matt Hill
--00000000000064fdc505bbb7be08
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div style=3D"font-family:sans-serif;font-size:12.8px" di=
r=3D"auto">Good day all, this is my first post to this mailing list. Per Ad=
am's comment below:<br></div><div style=3D"color:rgb(80,0,80);font-fami=
ly:sans-serif;font-size:12.8px" dir=3D"auto"><div><br></div><div>> given=
there are clearly people of both views, or for now don't care<br>but m=
ight later, it would minimally be friendly and useful if<br>bitcoin-core ha=
s a LOT=3Dtrue option - and that IMO goes some way to<br>avoid the assumpti=
ve control via defaults.</div><div><br></div></div><div style=3D"font-famil=
y:sans-serif;font-size:12.8px" dir=3D"auto">Both here and elsewhere, the de=
bate taking place is around the manner of Taproot activation, not whether o=
r not Taproot should be activated. The latter seems to have widespread supp=
ort. Given this favorable environment, it seems to me this is an incredible=
opportunity for the developer contingency to "take the high road"=
; while also minimizing time to Taproot activation using political incentiv=
es. By offering power on the left hand to miners and and power on the right=
to users, neither of whom is expressing disapproval of activation, but bot=
h of whom are able to activate without the consent of the other, both are i=
ncentivized to signal activation as quickly as possible to emerge as the &q=
uot;group that did it". All that must be done is to include a LOT=3Dtr=
ue option to Bitcoin Core that carries a default of LOT=3Dfalse. Miners can=
activate at any time, users can signal their intent to activate should min=
ers renege, and developers emerge as politically neutral in the eyes of bot=
h.</div><div style=3D"font-family:sans-serif;font-size:12.8px" dir=3D"auto"=
><br></div><div style=3D"font-family:sans-serif;font-size:12.8px" dir=3D"au=
to">Extrapolating a bit, I contend this expanded agency of full node operat=
orship may result in more users running a full node, which is good and heal=
thy. From a miner's point of view, more full nodes only increases the l=
ikelihood of future UASFs, and so they are even further incentivized to exp=
edite Taproot activation. Perhaps this is a stretch, perhaps not.<br></div>=
<div style=3D"font-family:sans-serif;font-size:12.8px" dir=3D"auto"><br></d=
iv><div style=3D"font-family:sans-serif;font-size:12.8px" dir=3D"auto">To s=
ummarize: (1) this positions developers as neutral facilitators who deferre=
d power to the other contingencies; (2) we may see a rise in the popularity=
of running a full node and the number of full node operators; (3) miners a=
re incentivized to activate quickly to avoid being perceived as the "b=
ad guys" and to avoid the spread of full nodes; and (4) even if miners=
do not activate, users can organize a UASF in a grass-roots way.</div><div=
style=3D"font-family:sans-serif;font-size:12.8px" dir=3D"auto"><br></div><=
div style=3D"font-family:sans-serif;font-size:12.8px" dir=3D"auto">Matt Hil=
l</div></div>
--00000000000064fdc505bbb7be08--
|
