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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ACC2440A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 May 2017 22:44:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B187A168
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 May 2017 22:44:47 +0000 (UTC)
Received: from [33.253.80.67] (unknown [172.56.18.219])
by mail.bluematt.me (Postfix) with ESMTPSA id EEA6A135E1B;
Mon, 12 Jan 1970 09:11:22 +0000 (UTC)
Date: Fri, 26 May 2017 22:44:44 +0000
In-Reply-To: <CADvTj4o2pFXZFHALfP-dJ10+AQxfFLVuohcpBn-tupf+CHRBYA@mail.gmail.com>
References: <CAAUaCyiHUOQ-rhN5XiGyMc6ocfsNBuH_tzK_QWu7sg1=Qd-o=Q@mail.gmail.com>
<9e2e7009-7bec-845a-bc9f-3ee03d4b4e7f@mattcorallo.com>
<CAAUaCyj1Yo+CpmwR40U711wknwerYeE_WkLERHuKf3uX-fcQjA@mail.gmail.com>
<CADvTj4o2pFXZFHALfP-dJ10+AQxfFLVuohcpBn-tupf+CHRBYA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: James Hilliard <james.hilliard1@gmail.com>,
Jacob Eliosoff <jacob.eliosoff@gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <18D47015-A4F0-438C-8D46-812E3F20EE2B@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <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 22:44:48 -0000
While I'm not 100% convinced there are strict technical reasons for needing=
to wait till after segwit is active before a hard fork can be started (you=
can, after all, activate segwit as a part of the HF), there are useful des=
ign and conservatism reasons (not causing massive discontinuity in fee mark=
et, handling major system changes one at a time, etc)=2E
Still, totally agree that attempting to design, code, and test a new hard =
fork in six months, let alone deploy it, let alone simultaneously with segw=
it, is a joke and fails to take seriously the investment many have made in =
the bitcoin system=2E Previous, rather simple, soft forks required similar =
if not more development time, not counting deployment and activation time=
=2E
If the community is unable to form consensus around segwit alone for polit=
ical reasons, further research into hard fork design may help, but even for=
ks tied together would nearly certainly need to activate months apart=2E
On May 26, 2017 5:30:37 PM EDT, James Hilliard <james=2Ehilliard1@gmail=2E=
com> wrote:
>Mandatory signalling is the only way to lock in segwit with less than
>95% hashpower without a full redeployment(which for a number of
>technical reasons isn't feasible until after the existing segwit
>deployment expires)=2E There's no reason not to signal BIP141 bit 1
>while also signalling bit 4, but you would want to use bit 4 to
>coordinate bit 1 mandatory signalling=2E
>
>It would not be feasible to schedule any HF until one can be
>completely sure BIP141 is active(at least not without waiting for the
>timeout and doing a redeployment) due to activation/p2p codepath
>complexity=2E This is why the mandatory signalling period is needed=2E
>
>Since it is likely a HF will take months of development and testing I
>see this or something similar as the fastest safe path forward:
>1=2E Use BIP91 or similar to activate BIP141 via mandatory signalling
>ASAP(likely using bit 4)
>2=2E Develop HF code based on assumption that BIP141 is active so that
>you only have to test the BIP141->HF upgrade/activation codepath=2E
>3=2E Deploy HF after BIP141 lock in(bit 4 can be reused again here since
>this will be after BIP91 expiration)
>
>When rolling out some features it often makes sense to combine them
>into a single fork for example BIP's 68, 112, 113 were rolled out at
>the same time as are BIP's 141, 143, 144, 145 for segwit, however a HF
>has required features that would conflict with with features in the
>segwit rollout which is why attempting to simultaneously deploy them
>would cause major complexity/testing issues(you would have to deal
>with feature conflict resolution for multiple potential activation
>scenarios)=2E By doing a staged rollout of segwit and then a HF you get
>a single testable upgrade path=2E
>
>Based on past development experiences I wouldn't expect a 6 month
>timeline to be realistic for a properly tested HF, but this proposed
>upgrade path should be the fastest available for both SegWit and a HF
>regardless=2E
>
>On Fri, May 26, 2017 at 4:10 PM, Jacob Eliosoff via bitcoin-dev
><bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrote:
>> Just to clarify one thing, what I described differs from BIP91 in
>that
>> there's no orphaning=2E Just when Segwit2MB support reaches 80%, those
>80%
>> join everyone else in signaling for BIP141=2E BIP91 orphaning is an
>optional
>> addition but my guess is it wouldn't be needed=2E
>>
>>
>> On May 26, 2017 4:02 PM, "Matt Corallo" <lf-lists@mattcorallo=2Ecom>
>wrote:
>>>
>>> Your proposal seems to be simply BIP 91 tied to the
>>> as-yet-entirely-undefined hard fork Barry et al proposed=2E
>>>
>>> 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=2E
>>>
>>> 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=2E
>>>
>>> Matt
>>>
>>> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:
>>> > Forgive me if this is a dumb question=2E Suppose that rather than
>>> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's
>lock-in
>>> > just triggered BIP141 signaling (plus later HF)=2E 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=2E My focus here is how
>>> > incompatibility with existing nodes could be minimized=2E
>>> >
>>> > (BIP91 could also be used if BIP141 support still fell short of
>95%=2E
>>> > But if Segwit2MB support reaches 80%, it seems likely that an
>additional
>>> > 15% will support BIP141-without-HF=2E)
>>> >
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>>> > https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
>>> >
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists=2Elinuxfoundation=2Eorg
>> https://lists=2Elinuxfoundation=2Eorg/mailman/listinfo/bitcoin-dev
>>
|
