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
|
Return-Path: <rgrant@rgrant.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 62FED516
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Jun 2017 19:31:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb0-f177.google.com (mail-yb0-f177.google.com
[209.85.213.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A15241BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Jun 2017 19:31:31 +0000 (UTC)
Received: by mail-yb0-f177.google.com with SMTP id o9so23353923yba.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Jun 2017 12:31:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=rgrant-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=tzqcPiYbK8SXralvOhFg6cFkBPGFiWYy1Yj7PQ+aR9E=;
b=erUFPGwWzrEBTKaeoUQUhTCejxEmFnDluIN+g672HzH+IdW4LmQor2p5ALJJ5jR6AA
XGLIGETI7lWmSYbNmGwp6Li1ZcC0d42jFOJJrXJPW5TI3eSiQzyM1+Zb400fUhIDgxwn
OheiBUyy4Vt24aJ5oZgu72qxUMdu3gERWAI7PB61Bh2ag2CC9daHHfLwfdN/0AgfgDKY
9xJ1i+LVbbqfewRXa5l0XVTwUfl8BLhlXT3O8KEaAl7K5ag2c7edxQkWrm/HdammAYvD
IDX/gOrOTF3u0e4gXgF0MSkZnFAStwr1NI7IcQjRtrSz7cQRtE2aaDrlhbgE/PT6km/Q
jl5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=tzqcPiYbK8SXralvOhFg6cFkBPGFiWYy1Yj7PQ+aR9E=;
b=rg2YRtKSxz5ahSSGWOGql3Qw1GvnxceDl0szri/AcQanIW/XK5ROc0wML5kaMi7WE3
/HD2b459EpcO1IrsKOnEczg8gcGKybaX4mQJloA0J/KTa/sqsF0eemilQm6VJgtY4al9
ZOe6ay6vhmpFxwDSQd0cddnXmCgao1sk0z6PRiiOBq+XDk8PwZPgjRp+NWMEHx/azPuo
K9m4SAU64utz1+wNG/SGmlrmgFlOY+V5L9d4yHeBeTFNVxEUCoD+I2u1qRsQ2B/9cw6k
o0H3g3pmBWa4OYqilawETXtjoTQQY1P3gAYwjvfSjjvSDnqnFnlPEfL5CqE3h2H733u1
ukcw==
X-Gm-Message-State: AODbwcAKjWgBanD6Wh4/UhoZfdBEqJqV8dZC5OMX5Omf0N/t3Yw0pthv
9xf4Ylg5/LV0nTDIFA7urF/nAZVgYvSFwT70Vw==
X-Received: by 10.37.32.195 with SMTP id g186mr23598025ybg.109.1497209490554;
Sun, 11 Jun 2017 12:31:30 -0700 (PDT)
MIME-Version: 1.0
Sender: rgrant@rgrant.org
Received: by 10.37.55.86 with HTTP; Sun, 11 Jun 2017 12:31:00 -0700 (PDT)
In-Reply-To: <CAMnpzfr5hLFqRm0_KWb6=N8YsD4dfQBtRBPFwfjz-EHA31d34A@mail.gmail.com>
References: <CAMnpzfr5hLFqRm0_KWb6=N8YsD4dfQBtRBPFwfjz-EHA31d34A@mail.gmail.com>
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Sun, 11 Jun 2017 15:31:00 -0400
X-Google-Sender-Auth: --Vb0_x1LIAIwluDf-9LiznDUBs
Message-ID: <CAMnpzfrx5QA0qqOjfRn=q0_HUtcDpbhAKxRLPitU02ycxN1+kQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] extended BIP9 activation of segwit,
for legacy nodes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sun, 11 Jun 2017 19:31:32 -0000
This[1] idea from April would assist in a BIP149-like segwit
activation on November 16th.
Its goal is to be incredibly easy to test and deploy, right now, even
before a decision on revisions to BIP149 is made, and well before such
"BIP149ish" testing is itself complete.
UASFs don't need time for most legacy nodes to upgrade - that's the
point of a soft fork. UASFs simply need to have inevitability,
which is provided by some nodes more than others. But for the node
less instrumental in that inevitability, and more relaxed about
scheduling upgrade work, being moved to a miner-protected consensus
ruleset is not as desirable a position as the opportunity to
participate fully. As a courtesy, the plan for soft forks has
always been to allow legacy nodes time to upgrade to full
participation. How much time should rollouts allow for this
courtesy?
Extended BIP9 activation of segwit (for legacy nodes) separates
concerns between intending to activate segwit and its method of
deployment, allowing "semi-legacy" nodes that have upgraded to
include this proposal to participate immediately in a successful
segwit activation, without needing any courtesy time to upgrade to
the particular deployment logic.
Code for deployment is included in the original email[1]. There's
nothing missing from the logic shown. The whole intent of the
proposal is that other deployment specifics are left to be defined
by future proposals. In the same block that THRESHOLD_ACTIVE is
reached for segwit, require Consensus::DEPLOYMENT_SEGWIT_ALT1 to
also reach THRESHOLD_ACTIVE, and the burden of the future proposal
is fulfilled.
If the idea proves broken or of no benefit, when actually
implementing and testing future deployments, then we can avoid using
DEPLOYMENT_SEGWIT_ALT1 until it expires, and zero nodes get hurt.
Let's look at how this affects options for how to deploy segwit...
/ BIP149ish UASF, without this proposal /
roadmap:
- BIP149ish debated (handles BIP141 success, unlike BIP149)
- BIP149ish tested
- BIP149ish courtesy timeout debated
- BIP148 fails
- BIP149ish released
- BIP141 fails
- BIP149ish courtesy timeout expires
- BIP149ish activates
- segwit activates
- legacy nodes must upgrade before recognizing BIP149 activation
If we try to restrict ourselves to only the original service bit, we
see a tension between activating soon and leaving legacy nodes on a
miner-protected consensus. We also see a tension between *planning*
how long it will take to debate and test UASF logic, and setting
expectations for when a reasonable activation date is.
These seemingly small tensions complicate the solution, and push it
out of developer's visions of what is feasible. It's not clear how
soon it can happen, so it doesn't get started in an urgent manner.
It doesn't get started in an urgent manner, so it's not clear how
soon it can happen.
/ BIP149ish UASF, with this proposal /
roadmap:
- this proposal debated
- this proposal tested
- this proposal released (courtesy begins)
- BIP149ish debated (handles BIP141 success, unlike BIP149)
- BIP149ish tested
- BIP148 fails
- BIP149ish released
- BIP141 fails
- BIP149ish activates
- segwit activates
- semi-legacy nodes *immediately* use segwit, via this proposal
We can remove the courtesy timeout problem, because the courtesy
begins as soon as this proposal goes live. This simplifies debate on
how BIP149ish should deploy, and helps make reasonable a much quicker
segwit activation should BIP141 fail.
With a clear route to quick activation for semi-legacy nodes, the
UASF can be planned for activation in as short a window as the key
nodes can upgrade. Not even all the key nodes need to upgrade: it's
still a soft fork, and UASFs simply need to have inevitability.
These differences can help us aim for activating segwit on November
16th, if BIP141 and BIP148 do not succeed earlier. Since BIP149 as
originally conceived is slow as molasses, BIP149ish still needs
debate, BIP141 has steadfast enemies, and the community is slow to
adapt to BIP148's complicated commitment requirements, it is prudent
to take this intermediate step allowing quicker BIP149ish activation.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014160.html
|
