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
196
197
198
199
200
201
202
|
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 EF3DEC16
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 May 2017 20:10:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com
[209.85.215.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1F49118F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 May 2017 20:10:41 +0000 (UTC)
Received: by mail-lf0-f51.google.com with SMTP id m18so11323499lfj.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 May 2017 13:10:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=TiU9UIZ8u/a+6rpVxRXt1+rW+Iy01hiRGREkgNOr4oc=;
b=bcbvWueTCJYdFT00ZnX4AiUyVRr7Nfo93pc2TPzUDdqcyiRXGlqHQxtnF+zntbb3Fn
6MAhZWCCDIJAqXBKxWr1AuS+gAbDC6FNy+5bUCeNmMpZOzRFCD37xC4dziBLb/PALq2D
5uBz11VD+XWqz8235lMhkFhB61wsSDuA3Z+UdAn7c3RPkrOFMG3bVPG+tm2zhp/aNLdG
7/enTXZKgAgNhHbofdnP1zUhrsouEFjxTAa7R/ZYYHo1X4lGzD4Z4xXvSezChPLFYkDe
f5dKyHuglMfek8WkSrC7TKNzCnf9aeuF7gbmUU2Z+AZTjntoVWxbc4/PnKB5rl4p5z7M
VpTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=TiU9UIZ8u/a+6rpVxRXt1+rW+Iy01hiRGREkgNOr4oc=;
b=h6ezcA3sJK9zuinGHf5sPIDfHKIHMUfkvZ5HeW+BaSxgipySm8gBc22YIdtJdS/Uij
ZZbECxLxEW7g2majesz6polQ+VDYQ61EzSiYc44/cz6+UvIXKBuAxD2TYevExm8a4kZ9
jdAjovphq9RaD7LOZ0858XdjKIFVxYtr74UY1fndgatyed8jGF+sH2akthrLUVVMwjAw
sOjHD9oN4E3Qv1lZ6gPY5FWQY55/auCF9EwgaYbsS3Bx6gv59Zs0HPLv+l7lyRo/ekYc
PCLD2OqccOyk9IZ30F1V1+U72hUsYbT6Mq2ZmO2MXhnukVYKddxxbZz8KaGXb8OzxAvB
2nQg==
X-Gm-Message-State: AODbwcDU1LzI1vRwiZ7BLxeQl8dg0mAHV0JborganQiGmftllMqlQn4p
yQCo5CjZzGgSgfQ/KJZALvf25E8hMwd/
X-Received: by 10.25.202.27 with SMTP id a27mr1035887lfg.70.1495829439471;
Fri, 26 May 2017 13:10:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.80.4 with HTTP; Fri, 26 May 2017 13:10:38 -0700 (PDT)
Received: by 10.25.80.4 with HTTP; Fri, 26 May 2017 13:10:38 -0700 (PDT)
In-Reply-To: <9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com>
References: <CAAUaCyiHUOQ-rhN5XiGyMc6ocfsNBuH_tzK_QWu7sg1=Qd-o=Q@mail.gmail.com>
<9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com>
From: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Date: Fri, 26 May 2017 16:10:38 -0400
Message-ID: <CAAUaCyj1Yo+CpmwR40U711wknwerYeE_WkLERHuKf3uX-fcQjA@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="f403045ea59c626895055072ee5c"
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, 26 May 2017 20:13:15 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement
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, 26 May 2017 20:10:42 -0000
--f403045ea59c626895055072ee5c
Content-Type: text/plain; charset="UTF-8"
Just to clarify one thing, what I described differs from BIP91 in that
there's no orphaning. Just when Segwit2MB support reaches 80%, those 80%
join everyone else in signaling for BIP141. BIP91 orphaning is an optional
addition but my guess is it wouldn't be needed.
On May 26, 2017 4:02 PM, "Matt Corallo" <lf-lists@mattcorallo.com> wrote:
> Your proposal seems to be simply BIP 91 tied to the
> as-yet-entirely-undefined hard fork Barry et al proposed.
>
> Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as
> you propose, would make the deployment on the incredibly short timeline
> Barry et al proposed slightly more realistic, though I would expect to
> see hard fork code readily available and well-tested at this point in
> order to meet that timeline.
>
> Ultimately, due to their aggressive timeline, the Barry et al proposal
> is incredibly unlikely to meet the requirements of a
> multi-billion-dollar system, and continued research into meeting the
> spirit, not the text, of their agreement seems warranted.
>
> Matt
>
> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:
> > Forgive me if this is a dumb question. Suppose that rather than
> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in
> > just triggered BIP141 signaling (plus later HF). Would that avoid
> > incompatibility with existing BIP141 nodes, and get segwit activated
> > sooner? Eg:
> >
> > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support
> > for "segwit now, HF (TBD) at scheduled date (Nov 23?)"
> > - If bit 4 support reaches 80%, it locks in two things: the scheduled HF
> > (conditional on segwit), and *immediately* turning on bit 1 (BIP141
> support)
> >
> > I realize this would still leave problems like the aggressive HF
> > schedule, possible chain split at the HF date between Segwit2MB nodes
> > and any remaining BIP141 nodes, etc. My focus here is how
> > incompatibility with existing nodes could be minimized.
> >
> > (BIP91 could also be used if BIP141 support still fell short of 95%.
> > But if Segwit2MB support reaches 80%, it seems likely that an additional
> > 15% will support BIP141-without-HF.)
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
--f403045ea59c626895055072ee5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Just to clarify one thing, what I described differs from =
BIP91 in that there's no orphaning.=C2=A0 Just when Segwit2MB support r=
eaches 80%, those 80% join everyone else in signaling for BIP141.=C2=A0 BIP=
91 orphaning is an optional addition but my guess is it wouldn't be nee=
ded.<div dir=3D"auto"><br></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On May 26, 2017 4:02 PM, "Matt Corallo" <=
<a href=3D"mailto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a>>=
; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Your propos=
al seems to be simply BIP 91 tied to the<br>
as-yet-entirely-undefined hard fork Barry et al proposed.<br>
<br>
Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as<=
br>
you propose, would make the deployment on the incredibly short timeline<br>
Barry et al proposed slightly more realistic, though I would expect to<br>
see hard fork code readily available and well-tested at this point in<br>
order to meet that timeline.<br>
<br>
Ultimately, due to their aggressive timeline, the Barry et al proposal<br>
is incredibly unlikely to meet the requirements of a<br>
multi-billion-dollar system, and continued research into meeting the<br>
spirit, not the text, of their agreement seems warranted.<br>
<br>
Matt<br>
<br>
On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:<br>
> Forgive me if this is a dumb question.=C2=A0 Suppose that rather than<=
br>
> directly activating segwit, the Silbert/NYC Segwit2MB proposal's l=
ock-in<br>
> just triggered BIP141 signaling (plus later HF).=C2=A0 Would that avoi=
d<br>
> incompatibility with existing BIP141 nodes, and get segwit activated<b=
r>
> sooner?=C2=A0 Eg:<br>
><br>
> - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support<=
br>
> for "segwit now, HF (TBD) at scheduled date (Nov 23?)"<br>
> - If bit 4 support reaches 80%, it locks in two things: the scheduled =
HF<br>
> (conditional on segwit), and *immediately* turning on bit 1 (BIP141 su=
pport)<br>
><br>
> I realize this would still leave problems like the aggressive HF<br>
> schedule, possible chain split at the HF date between Segwit2MB nodes<=
br>
> and any remaining BIP141 nodes, etc.=C2=A0 My focus here is how<br>
> incompatibility with existing nodes could be minimized.<br>
><br>
> (BIP91 could also be used if BIP141 support still fell short of 95%.<b=
r>
> But if Segwit2MB support reaches 80%, it seems likely that an addition=
al<br>
> 15% will support BIP141-without-HF.)<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
><br>
</blockquote></div></div>
--f403045ea59c626895055072ee5c--
|
