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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6A347C000A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Mar 2021 09:18:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 49FE4402FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Mar 2021 09:18:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001]
autolearn=ham autolearn_force=no
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 I3Q-Ag0QB7DP
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Mar 2021 09:18:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp4.osuosl.org (Postfix) with ESMTPS id 7E01F402F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 Mar 2021 09:18:08 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1lQo26-0002EO-GV; Mon, 29 Mar 2021 19:18:05 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Mon, 29 Mar 2021 19:17:57 +1000
Date: Mon, 29 Mar 2021 19:17:57 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210329091757.GA13603@erisian.com.au>
References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
<CAMZUoKkWmdwi-VH3WUvFfG+5MDK3xhvZUac3eBQbxXX_b_btWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMZUoKkWmdwi-VH3WUvFfG+5MDK3xhvZUac3eBQbxXX_b_btWw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
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, 29 Mar 2021 09:18:10 -0000
On Wed, Mar 03, 2021 at 02:08:21PM -0500, Russell O'Connor via bitcoin-dev wrote:
> While I support essentially any proposed taproot activation method, including a
> flag day activation, I think it is premature to call BIP8 dead.
>
> Even today, I still think that starting with BIP8 LOT=false is, generally
> speaking, considered a reasonably safe activation method in the sense that I
> think it will be widely considered as a "not wholly unacceptable" approach to
> activation.
If everyone started with lot=false, that would be true -- that was how
segwit then BIP148/BIP91 worked, and was at least how I had been assuming
people were going to make use of the new improved BIP8.
But it seems more likely that when activation starts, even if many
people run lot=false, many other people will run lot=true: see Luke's
arguments on this list [0], Rusty's campaign for a lot=true option [1],
the ##uasf channel (initial topic: Development of a Taproot activation
implementation with default LOT=true) [2], or Samson's hat designs [3].
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
[1] https://rusty.ozlabs.org/?p=628
https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3667311
[2] http://gnusha.org/uasf/
[3] https://twitter.com/Excellion/status/1363751091460956167
With lot=false and lot=true nodes active on the network, a chain split
occurs if the activation is blocked: perhaps that might happen for good
reasons, eg because there are implementation bugs found after activation
settings are merged but prior to activation locking in, or perhaps for
neutral or bad reasons that cause miners to be opposed.
In the event of a huge conflict or emergency as bad as or worse than
occurred with segwit, a chain split might well be the lesser evil
compared to the activation being blocked or delayed substantially;
but as default scenario for every consensus change, before we know if
someone might find a problem while there's still time to back out, and
before we know if there is going to be a huge conflict? It doesn't seem
as focussed on safety as I'd expect from bitcoin.
> After a normal and successful Core update with LOT=false, we will have more
> data showing broad community support for the taproot upgrade in hand. In the
> next release, 6 months later or so, Core could then confidently deploy a BIP8
> LOT=true client, should it prove to be necessary.
BIP8/lot=true is great for the situation we found ourselves in with
BIP91/BIP148: there's an activation underway, that is being unexpectedly
opposed, we want to ensure it activates, *and* we don't want to have
everyone have to do a new round of software upgrades.
But if we're able to calmly put out a new release with new activation
parameters, with enough time before it takes effect that everyone can
reasonably upgrade to it, that's a pretty different situation.
First, since we're giving everyone time to upgrade, it can be a clean
secondary deployment -- there's no need to try to drag the original
lot=false users along -- we're giving everyone time to upgrade, and
everyone includes them.
Second, lot=true implies we're doing some unsignalled consensus change
anyway -- blocks would be considered invalid if they don't signal for
activation as of some height, with no prior on-chain signalling that
that rule change has occurred. So if we're allowing that, there's no
principle that requires signalling to lock in the change we're actually
trying to activate.
So at that point why not simply reverse the burden of proof entirely? Run
an initial "speedy trial" type event that allows fast activation via miner
enforcement prior to everyone having upgraded; and if that fails but there
haven't been valid reasonable objections to activation identified, run
a secondary activation attempt that instead of requiring 90% signalling
to activate, requires 90% signalling to *fail*.
Miners not upgrading is then not a blocker, and even if a few miners are
buggy and signal accidently, that doesn't cause a risk to them of having
their blocks dropped, or to the network of having the upgrade blocked.
If there are good reasons to object to the fork being activated that are
discovered/revealed (very) late, this also provides an opportunity to
cleanly cancel the activation by convincing miners that the activation
is undesirable and having them agree to signal for cancellation (via
BIP-91 style coordination or even BIP-148 style mandatory signalling, eg).
And, on the other hand, if 90% of miners are opposed to a soft fork for
some selfish or bad reason, with that much hashpower they could easily do
a 51% attack on the network after activation to prevent any new features
being used, so cancelling activation in that case is probably not worse
in practice than it would be continue with it despite the opposition.
I think a state machine along the lines of:
DEFINED - for 6 months after code release
STARTED - exactly 1 period
FAILED - if sufficient signalling occurs
DELAYED - 6 months
LOCKED_IN - exactly 1 period
ACTIVE
would work fine for an if-at-first-you-don't-succeed approach to
deployment along the above lines.
That seems to me to have a lot of desirable properties:
- a minority of hashpower can't block activation
- miners don't have to do anything and don't have to worry about
their blocks getting orphaned
- devs aren't making any final decisions on consensus changes,
even if everyone's committed to running the same codebase
(unlike when merging either lot=true or flag day activations)
- there's no need to run different clients, or carefully configure your
node to stay in consensus
- if economic actors want to influence activation by setting up
markets, they have a single signalling period to focus on, with 6
months lead time to set everything up and stabilise price discovery,
and a fairly definite endpoint and clear result for closing out
everyone's positions, whichever outcome occurs
- there's no need/encouragement to use the machine vetting your business
income as leverage to force/prevent changes to bitcoin consensus;
configuring your node to not follow the most work chain is only
needed when both devs and miners are getting it wrong, *and* market
incentives haven't been enough to correct things
The main drawback is that it doesn't allow faster activation with miner
support; even with a speedy trial first, it's just a boolean: did miners
indicate they've upgraded quickly enough to hit the early activation
or not?
Cheers,
aj
|
