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
|
Return-Path: <jacob.eliosoff@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F29195E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Jun 2017 04:41:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com
[209.85.215.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2A565EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Jun 2017 04:41:00 +0000 (UTC)
Received: by mail-lf0-f45.google.com with SMTP id o83so25230480lff.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 08 Jun 2017 21:40:59 -0700 (PDT)
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=2E+xA8ixVMjtr1csqATrxdnA403lLCAUOp9aPy7p/To=;
b=jeBl5Tg2hh4SIPjfAXyVk76Mor9eIiOLJ4Kf5/pWc15dQNO4W03fPcMNK/6Gwf9wx+
SnF46YucxKMbUPQUE48Uk6DXrBSt1UIyTOJE47RJT7D7sqnNR1ySpIw9CGFyRfd18Xrx
iJjJGAbcHArrmcjKxarsNAUlflWG3bu6o8iNycObyVVZYHNXJ7vcbuR+vXUloVOrGvX+
t76azQb9ti6WUZ6vwF6ijnSTbbcvMBU42sPqNKcZo22A792XUJya8GCaIp2kPCiCGfqp
pKFQZEMJj0K77Opxud4fAfoWy2A9vAzr0eWJVEUtbAQ7qQxA2JtnveJ2XqKK1zQcHTQp
ykjQ==
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=2E+xA8ixVMjtr1csqATrxdnA403lLCAUOp9aPy7p/To=;
b=mlTRNJSZTNnYOhCNhY3bMpLidQgMJImBPxCdVzC8UQr9i9qpkuQuoG9v3qRV0ibWA7
ZLzQviObaui7FHq+FwQPQwKRSpDBJOC6NQ6fh9FqdLRBDiSfoRS0ACs9LWI5pe6au0Cs
81S/Koxc5kKbBY9MSryXYPYeSD7JXswREBIe1Uz2TevgQx68zU3rst4jMvtwv7iZTwcG
7BTzOTkqcjxD4OFvqOfWVQQMke80bs4Nd1qzm+fhrvaTOcfpQ1iO7ofMGgIaORZtn8Y1
16LoZwMbJOfb0/IFCtxnNdduEiSg+hlmGatzAHqinD8/BsRYXAnPcP1z1BbzlHb+NCxz
kTJA==
X-Gm-Message-State: AODbwcBa+vMS/almNhw2ksHfJccimCN5gBl0QWbxx5CojuAN1vp4F8+K
ai/nj4BUDSs+cENe5m8un85ziOoolEe0nmM=
X-Received: by 10.25.152.79 with SMTP id a76mr11268689lfe.165.1496983258109;
Thu, 08 Jun 2017 21:40:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.24.22 with HTTP; Thu, 8 Jun 2017 21:40:57 -0700 (PDT)
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Fri, 9 Jun 2017 00:40:57 -0400
Message-ID: <CAAUaCygRaXNX5xWuka1xrrXwKv1tqevT9-cHd-5mh_AkHpg9gA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a11401bc4559d1305517f9300"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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
X-Mailman-Approved-At: Fri, 09 Jun 2017 06:48:18 +0000
Subject: [bitcoin-dev] The BIP148 chain split may be inevitable
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: Fri, 09 Jun 2017 04:41:02 -0000
--001a11401bc4559d1305517f9300
Content-Type: text/plain; charset="UTF-8"
I've been trying to work out the expected interaction between James
Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
use variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is
subtle so CORRECTIONS WELCOME, but my conclusions are:
1. It's extremely unlikely BIP91-type logic can activate segwit in time to
avoid a BIP148 chain split.
2. So, in practice all we can do is ensure the BIP148 split is as painless
as possible.
REASONING: First, some dates. BIP148, whose deadline is already deployed
and thus unlikely to be postponed, starts orphaning non-segwit blocks on
midnight (GMT) the morning of August 1. Meanwhile, here are Bitcoin's
rough expected next four difficulty adjustment dates (they could vary by
~1-3 days depending on block times, but it's unlikely to matter here):
1. June 17
2. June 30
3. July 13
4. July 27
If Segwit activates on adj date #5 or later (August), it will be too late
to avoid BIP148's split, which will have occurred the moment August began.
So, working backwards, and assuming we want compatibility with old BIP141
nodes:
- Segwit MUST activate by adj #4 (~July 27)
- Therefore segwit MUST be locked in by adj #3 (~July 13: this is
inflexible, since this logic is in already-deployed BIP141 nodes)
- Therefore, I *think* >50% of hashpower needs to be BIP91 miners,
signaling bit 1 and orphaning non-BIP91 (ie, BIP91's bit 4 must activate),
by adj #2 (June 30)?
- Therefore, as currently designed, BIP91 bit 4 must be locked in by adj #1
(June 17)
- Therefore, >=80% of hashrate must start signaling BIP91's bit 4 by a few
days ago...
There are ways parts of this could be sped up, eg, James' "rolling
100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. But
to be compatible with old BIP141 nodes, >50% of hashrate must be activated
BIP91 miners by ~June 30: there's no fudging that.
So, it seems to me that to avoid the BIP148 split, one of two things would
have to happen:
a) 95% of hashrate start signaling bit 1 by ~June 30. Given current stat
is 32%, this would basically require magic.
b) BIP91 is deployed and >50% (80% or whatever) of hashrate is *activated*
BIP91 miners by ~June 30, ~3 weeks from now. Again, much too soon.
So, I think the BIP148 split is inevitable. I actually expect that few
parts of the ecosystem will join the fork, so disruption will be bearable.
But anyway let me know any flaws in the reasoning above.
[1] https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014508.html
[3] https://github.com/btc1/bitcoin/pull/11
[4] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
[5] https://github.com/btc1/bitcoin/pull/6#issuecomment-305917729
--001a11401bc4559d1305517f9300
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I've been trying to work out the expected interac=
tion between James Hilliard's BIP91 [1] (or splitprotection [2], or Seg=
wit2x [3], which both use variants of BIP91 activation) and the BIP148 UASF=
[4].=C2=A0 Some of this is subtle so CORRECTIONS WELCOME, but my conclusio=
ns are:</div><div>1. It's extremely unlikely BIP91-type logic can activ=
ate segwit in time to avoid a BIP148 chain split.</div><div>2. So, in pract=
ice all we can do is ensure the BIP148 split is as painless as possible.</d=
iv><div><br></div><div>REASONING: =C2=A0First, some dates.=C2=A0 BIP148, wh=
ose deadline is already deployed and thus unlikely to be postponed, starts =
orphaning non-segwit blocks on midnight (GMT) the morning of August 1.=C2=
=A0 Meanwhile, here are Bitcoin's rough expected next four difficulty a=
djustment dates (they could vary by ~1-3 days depending on block times, but=
it's unlikely to matter here):</div><div>1. June 17</div><div>2. June =
30</div><div>3. July 13</div><div>4. July 27</div><div><br></div><div>If Se=
gwit activates on adj date #5 or later (August), it will be too late to avo=
id BIP148's split, which will have occurred the moment August began.=C2=
=A0 So, working backwards, and assuming we want compatibility with old BIP1=
41 nodes:</div><div><br></div><div>- Segwit MUST activate by adj #4 (~July =
27)</div><div>- Therefore segwit MUST be locked in by adj #3 (~July 13: thi=
s is inflexible, since this logic is in already-deployed BIP141 nodes)</div=
><div>- Therefore, I *think* >50% of hashpower needs to be BIP91 miners,=
signaling bit 1 and orphaning non-BIP91 (ie, BIP91's bit 4 must activa=
te), by adj #2 (June 30)?</div><div>- Therefore, as currently designed, BIP=
91 bit 4 must be locked in by adj #1 (June 17)</div><div>- Therefore, >=
=3D80% of hashrate must start signaling BIP91's bit 4 by a few days ago=
...</div><div><br></div><div>There are ways parts of this could be sped up,=
eg, James' "rolling 100-block lock-in periods" [5], to get B=
IP91 signaling bit 1 sooner.=C2=A0 But to be compatible with old BIP141 nod=
es, >50% of hashrate must be activated BIP91 miners by ~June 30: there&#=
39;s no fudging that.</div><div><br></div><div>So, it seems to me that to a=
void the BIP148 split, one of two things would have to happen:</div><div>a)=
95% of hashrate start signaling bit 1 by ~June 30.=C2=A0 Given current sta=
t is 32%, this would basically require magic.</div><div>b) BIP91 is deploye=
d and >50% (80% or whatever) of hashrate is *activated* BIP91 miners by =
~June 30, ~3 weeks from now.=C2=A0 Again, much too soon.</div><div><br></di=
v><div>So, I think the BIP148 split is inevitable.=C2=A0 I actually expect =
that few parts of the ecosystem will join the fork, so disruption will be b=
earable.=C2=A0 But anyway let me know any flaws in the reasoning above.</di=
v><div><br></div><div>[1] <a href=3D"https://github.com/bitcoin/bips/blob/m=
aster/bip-0091.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0=
091.mediawiki</a></div><div>[2] <a href=3D"https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2017-June/014508.html">https://lists.linuxfoundatio=
n.org/pipermail/bitcoin-dev/2017-June/014508.html</a></div><div>[3] <a href=
=3D"https://github.com/btc1/bitcoin/pull/11">https://github.com/btc1/bitcoi=
n/pull/11</a></div><div>[4] <a href=3D"https://github.com/bitcoin/bips/blob=
/master/bip-0148.mediawiki">https://github.com/bitcoin/bips/blob/master/bip=
-0148.mediawiki</a></div><div>[5] <a href=3D"https://github.com/btc1/bitcoi=
n/pull/6#issuecomment-305917729">https://github.com/btc1/bitcoin/pull/6#iss=
uecomment-305917729</a></div></div>
--001a11401bc4559d1305517f9300--
|
