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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 70790C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Mar 2021 17:57:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with UTF8SMTP id 6C194606AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Mar 2021 17:57:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with UTF8SMTP id qyvbdrMNoE0q
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Mar 2021 17:57:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp3.osuosl.org (Postfix) with UTF8SMTPS id 4096C606A2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Mar 2021 17:57:25 +0000 (UTC)
Received: by mail.as397444.net (Postfix) with UTF8SMTPSA id C1ED94CCF8C;
Sat, 6 Mar 2021 17:57:22 +0000 (UTC)
X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com;
s=1615051263; t=1615053442;
bh=I5kqp9yO/OuUpa4Ku5u7zI/+CTHCryJPQLWrY3P3rYg=;
h=Date:Subject:To:Cc:References:From:In-Reply-To:From;
b=ilyZxyLyBlt3Bv+3hglXxm/8uUYMJfN3j7rT3eRlmgKAC+QHaOx3q1e6o04LWsyPi
BpvsaG68xduCQe5dKDLfvFB5BK++f33uVzq+GgPytt5zhkDgs9WzyB2rQTrufcLLM2
WGxMAYRiKFUZuutNiVAK9BcFZojbSLEbJwtKVTKO4CB9WJcCFi16XliARSLa8Lgimw
hbjjHWRIvsrcz12YzHaaqvG28mn+ocIEg7uYGlePqkRrupqMVSYnRh0aU8MDjLDQbt
b8T+t3uV+v4I8BmFzGFV6lo1YdIt2Epp4ziWJX2F2PYYHI4tGadmRcCRK0eN+Cb1ye
ckPXgULpfKApA==
Message-ID: <686cc38a-6ab7-1370-971e-69f6b8f834dc@mattcorallo.com>
Date: Sat, 6 Mar 2021 12:57:22 -0500
MIME-Version: 1.0
Content-Language: en-US
To: Russell O'Connor <roconnor@blockstream.com>
References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
<CAMZUoKkWmdwi-VH3WUvFfG+5MDK3xhvZUac3eBQbxXX_b_btWw@mail.gmail.com>
<4947b02e-90fb-9044-4552-767de805ff14@mattcorallo.com>
<CAMZUoKmTL+2GMpv8Qr5uOUC2bMgyuzMPw1zjdjuD+XNE23-65A@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAMZUoKmTL+2GMpv8Qr5uOUC2bMgyuzMPw1zjdjuD+XNE23-65A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sat, 06 Mar 2021 17:57:26 -0000
Replies inline. Several sections removed, where I basically agree.
On 3/4/21 08:47, Russell O'Connor wrote:
> Appologies as I've rearranged your comments in my reply.
> I agree with you. I also think we have plenty of evidence to proceed with taproot and could proceed with a PR for such
> a flag day activation. If there is support for it to be merged, that would be fantastic. I think we should proceed
> along these lines forthwith.
>
> However, the existence and/or release of a flag day activation code does not in of itself preclude concurrently
> developing and/or releasing a BIP8 LOT=false deployment. Activating taproot is "idempotent" after all. We could even do
> a Core release with a flag day activation while we continue to discuss BIP8 LOT=false if that gets the ball rolling.
> Certainly having a flag day activation code merged would take a lot of pressure off further BIP8 LOT=false work.
Hmm, while this is certainly true at a technical level, it adds a lot of complexity both in terms of discussion, and for
users - "I already upgraded to Taproot, why did I just see a fork with an invalid Taproot spend?".
> As Aaron noted on IRC, if the sticking point here is the MUST_SIGNAL state, then running BIP8 LOT=false alongside a flag
> day activation at timeout may be the way to go. Once a flag day deployment is released, the LOT=true people would have
> their guaranteed activation and would be less interested in an alternative client. And without a MUST_SIGNAL state, I
> believe the LOT=false deployment won't lead any hashpower that is following standardness rules to create invalid blocks.
This is indeed a significant improvement over BIP 8 in my opinion. However, as I pointed out on a Reddit discussion with
Aaron, I'm still incredibly worried about users pushing for some UASF-style forced-signaling guerilla faster-activation.
It may absolutely be the case that Taproot activates quickly or that such users are a tiny minority of transacting.
However, as we saw with BIP 148/UASF, even a tiny minority of transacting users can set the tone and claim victory over
how a soft-fork activates. I worry that even your approach here runs the risk of yet further normalization of consensus
rule diversity on the network.
Maybe my worry is overblown, and I'm certainly not going to try to solely stand in the way on this one, but now that
we're stuck in yet another overblown debate, we might as well take it as an opportunity to reinforce the idea that
consensus rule diversity runs the risk of consensus failure, and isn't a reasonable risk.
>
> > 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.
>
> How do you propose avoiding divergent consensus rules on the network, something which a number of commentors on this
> list have publicly committed to?
>
>
> Firstly, it is an open network. Anyone can join and run whatever consensus rules they want. People have run divergent
> consensus rules on the network in the past and it will continue to do so in the future.
> It is troublesome when it happens in mass, but it isn't fatal. We can't prevent it, and we should continue working to
> keep the protocol robust in the face of it.
> And we certainly shouldn't be bullied by anyone who comes threatening their own soft-fork.
Apologies. I should have phrased my comment better. My worry, at a broad level is that
(a) people have taken the events around the Segwit BIP 148 UASF to mean that a very small minority of users can (and
maybe should) push consensus rules through threats of breaking consensus and
(b) there is a very vocal group today which is reinforcing this belief by ignoring the complex context around Segwit and
behaving similarly with regards to Taproot.
Indeed, there is nothing we can, or should, do to actively prevent people from running their own software which
interprets Bitcoin's consensus rules in...creative ways. But that isn't to say there is no use worrying about it. 95% of
Bitcoin users aren't aware that this debate is even happening. Of the remaining 5%, 90% haven't had the time to research
and think deeply enough to form an opinion. Our responsibility is to the 99.5% of users.
Sure, individuals running different consensus rules won't cause immediate harm to others, but the net effect of many
users doing so and especially the community normalizing such behavior very significantly can. Ill-informed transactors
running such software (including wallet providers with users who were unaware of the events) can be screwed out of their
Bitcoin. This outcome very well could have occurred in the case of the BIP 148 UASF, and repeating the same pattern many
times will not help to de-risk that.
> Even simply doing nothing may not prevent divergent consensus from appearing on the network. Playing conservative isn't
> playing it safe because there is nothing more conservative than doing nothing, which isn't guaranteed to be safe in this
> sense.
Indeed. The obvious most conservative action is not activating Taproot at all. Obviously this is unlikely to solve the
issue :).
> Secondly, for the specific concern of people running BIP8 LOT=true clients, we could start with "Let’s see what happens"
> with a short 3 or 4 month signaling period. A short enough signaling period is not "hijackable". We could add a longer
> LOCKED_IN period if there are worries about getting enough nodes upgraded in time for activation. I see other options
> as well.
Potentially indeed. Though I'm not so sure that several months represents a period that is not "hijackable", given the
speed at which someone can hack together naive activation code.
> I keep being told that miners are ready and willing to activate, and taproot will probably activate in two months. All
> we have to do is get something out the door that does that. If taproot activates in two months, great. If it fails to
> activate we will learn so much in so little time. UASF's will get to say "I told you so" without waiting a year. Users
> will get to take active, meaningful and observable steps to demonstrate their desire for a taproot upgrade. Very little
> time will be wasted, in particular we don't have to finish debating how best to handle the unlikely scenario where
> taproot doesn't activate right away for whatever reason that is, an scenario that isn't even likely to occur.
Indeed, I've always suggested a miner activation window first to "learn something" about the state of it. However, I do
think we've passed the point where that should be a chief concern. The strength and diversity of public statements in
support of Taproot as a change to the network is rather overwhelming.
> I'm still very optimistic. I see multiple plausible and potentially acceptable paths towards activation still open and
> we don't even have to choose only one. I can hardly wait to look at the forthcoming PRs for these possibilities.
I agree :).
|
