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
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
|
Return-Path: <ricardojdfilipe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D7E4BE22
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 15:53:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com
[209.85.223.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 009EB182
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 15:53:04 +0000 (UTC)
Received: by mail-io0-f181.google.com with SMTP id l127so13579515iof.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 09 Feb 2016 07:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=DGkRzdDoJc971Zz1dGEned/1x+MAiaUijt5MCIPoME0=;
b=GjaMF/2IMphtRP93/tUGb++v/LPe4x69b3MVN7SAsUso+j5iqWNbb7Uc0vprrVdDjt
+wFsdL6ffEZQsPPvWUQNRDf8KUN2e/6mAajVgPr/5+IOxTo3fWFsEMmbLI/w7JKujnkh
obKzrKl/9Fq6+EVOs4wIVLlTSOg1R8BInmZldwUo3fJZeHtd4k+FuhEc2T5shqqtxR2S
eFSCIgn8O5mUM3PqoqzUZiU/h/oSIxHq0wHQXvqBzFDy/+25vJCFRrmfnKDCUJLQ4VF8
FiYVMZ46BxQctyb29SvLkTfuyGTHYf29UPfH0a/MvgvrDnASyUZSEDPuDr99uw3a/5/o
GQ6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=DGkRzdDoJc971Zz1dGEned/1x+MAiaUijt5MCIPoME0=;
b=jeQVW2UEqiA0gfyY3WQutWL9QZJkW7caJ80u0Rdm35MM73J5ldrRrNWrYMW6LJ/TWC
Wnm9RII3dHS99qc97j92LADuM/OlK+apdp7Byh2jt+0WGJ1a2axpCAKDUrRRdVu7NaQf
hZjHPusrHq5JYGbGELpxPbyl9nwL8UrVqlLMKopdNOa4ywXcif3CqEEEzaRDCvYm/LP6
8DYKq4WUR8gTtOZ9SP8v9Q7PXt8wsFaERxmmdf1stm1nQWs36jVGToXmOEOX3Qruk1cf
VoIorCng9aI/aS3vdhae767xd1RD3Jh1kKGo+ZOpFUOwQoQeqi1XC8t3j9Qf2Ar6wUbf
o9Nw==
X-Gm-Message-State: AG10YOS/GQRxRdWKld8xT5Ui7U6m6hjlNAust75xtk0dmi0tSH4b9OJHjxd76RZAfj+5zR7FPymwH62gyGy9dw==
MIME-Version: 1.0
X-Received: by 10.107.136.194 with SMTP id s63mr36540715ioi.88.1455033184440;
Tue, 09 Feb 2016 07:53:04 -0800 (PST)
Received: by 10.36.203.65 with HTTP; Tue, 9 Feb 2016 07:53:04 -0800 (PST)
In-Reply-To: <239b01d16344$717712d0$54653870$@xbt.hk>
References: <239b01d16344$717712d0$54653870$@xbt.hk>
Date: Tue, 9 Feb 2016 15:53:04 +0000
Message-ID: <CALC81CP13k_k7kQykYRbZbvRqxQfS99P4nSvsfk26viApbGa0Q@mail.gmail.com>
From: Ricardo Filipe <ricardojdfilipe@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a113eb3241858b3052b5850f5
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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: Tue, 09 Feb 2016 21:57:57 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A roadmap to a better header format and bigger
block size
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Tue, 09 Feb 2016 15:53:05 -0000
--001a113eb3241858b3052b5850f5
Content-Type: text/plain; charset=UTF-8
I believe i've seen Luke say this several times before, but there are
several more things that the majority of the devs agree should be in
bitcoin.
I would suggest to compile that list for your stage 3, so that you can have
an hardfork that fixes most of those things, and there should be some
repository with those changes deployed.
2016-02-09 14:16 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> I would like to present a 2-3 year roadmap to a better header format and
> bigger block size
>
> Objectives:
>
> 1. Multistage rule changes to make sure everyone will have enough time to
> upgrade
> 2. Make mining easier, without breaking existing mining hardware and the
> Stratum protocol
> 3. Make future hardfork less disruptive (with Luke-Jr's proposal)
>
> Stage 1 is Segregated Witness (BIP141), which will not break any existing
> full or light nodes. This may happen in Q2-Q3 2016
>
> Stage 2 is fixes that will break existing full nodes, but not light nodes:
> a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this
> roadmap), potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. (optional) Move segwit's commitments to the header Merkle tree. This is
> optional at this stage as it will be fixed in Stage 3 anyway
> This may happen in Q1-Q2 2017
>
> Stage 3 is fixes that will break all existing full nodes and light nodes:
> a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the
> rules and activation logic should be included already
> b. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure. All existing mining hardware with
> Stratum protocol should work.
> c. Reclaiming unused bits in header for mining. All existing mining chips
> should still work. Newly designed chips should be ready for the new rule.
> d. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. Light nodes (usually less tech-savvy users) will have longer time to
> upgrade
> b. The stage 2 is opt-in for full nodes.
> c. The stage 3 is opt-in for light nodes.
>
> Cons:
> a. The stage 2 is not opt-in for light nodes. They will blindly follow the
> longest chain which they might actually don't want to
> b. Non-upgraded full nodes will follow the old chain at Stage 2, which is
> likely to have lower value.
> c. Non-upgraded light nodes will follow the old chain at Stage 3, which is
> likely to have lower value. (However, this is not a concern as no one
> should
> be mining on the old chain at that time)
>
> -------------------------------
> An alternative roadmap would be:
>
> Stage 2 is fixes that will break existing full nodes and light nodes.
> However, they will not follow the minority chain
> a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount
> b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts
> c. Change the header format to Luke-Jr's proposal, and move all commitments
> (tx, witness, etc) to the new structure.
> This may happen in mid 2017 or later
>
> Stage 3 is fixes that will break all existing full nodes and light nodes.
> a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade
> again, as the rules and activation logic should be included already
> b. Reclaiming unused bits in header for mining. All existing mining chips
> should still work.
> c. Fix the time warp attack
> This may happen in 2018 to 2019
>
> Pros:
> a. The stage 2 and 3 are opt-in for everyone
> b. Even failing to upgrade, full nodes and light nodes won't follow the
> minority chain at stage 2
>
> Cons:
> a. Non-upgraded full/light nodes will follow the old chain at Stage 3,
> which
> is likely to have lower value. (However, this is not a concern as no one
> should be mining on the old chain at that time)
> b. It takes longer to implement stage 2 to give enough time for light node
> users to upgrade
>
> -------------------------------
>
> In terms of safety, the second proposal is better. In terms of disruption,
> the first proposal is less disruptive
>
> I would also like to emphasize that it is miners' responsibility, not the
> devs', to confirm that the supermajority of the community accept changes in
> Stage 2 and 3.
>
> Reference:
> Matt Corallo's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.
> html
> Luke-Jr's proposal:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.
> html
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113eb3241858b3052b5850f5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I believe i've seen Luke say this several times before=
, but there are several more things that the majority of the devs agree sho=
uld be in bitcoin.<div>I would suggest to compile that list for your stage =
3, so that you can have an hardfork that fixes most of those things, and th=
ere should be some repository with those changes deployed.</div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">2016-02-09 14:16 GMT+0=
0:00 jl2012--- via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>></span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would =
like to present a 2-3 year roadmap to a better header format and<br>
bigger block size<br>
<br>
Objectives:<br>
<br>
1. Multistage rule changes to make sure everyone will have enough time to<b=
r>
upgrade<br>
2. Make mining easier, without breaking existing mining hardware and the<br=
>
Stratum protocol<br>
3. Make future hardfork less disruptive (with Luke-Jr's proposal)<br>
<br>
Stage 1 is Segregated Witness (BIP141), which will not break any existing<b=
r>
full or light nodes. This may happen in Q2-Q3 2016<br>
<br>
Stage 2 is fixes that will break existing full nodes, but not light nodes:<=
br>
a. Increase the MAX_BLOCK_SIZE (the exact value is not suggested in this<br=
>
roadmap), potentially change the witness discount<br>
b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts<br>
c. (optional) Move segwit's commitments to the header Merkle tree. This=
is<br>
optional at this stage as it will be fixed in Stage 3 anyway<br>
This may happen in Q1-Q2 2017<br>
<br>
Stage 3 is fixes that will break all existing full nodes and light nodes:<b=
r>
a. Full nodes upgraded to Stage 2 will not need to upgrade again, as the<br=
>
rules and activation logic should be included already<br>
b. Change the header format to Luke-Jr's proposal, and move all commitm=
ents<br>
(tx, witness, etc) to the new structure. All existing mining hardware with<=
br>
Stratum protocol should work.<br>
c. Reclaiming unused bits in header for mining. All existing mining chips<b=
r>
should still work. Newly designed chips should be ready for the new rule.<b=
r>
d. Fix the time warp attack<br>
This may happen in 2018 to 2019<br>
<br>
Pros:<br>
a. Light nodes (usually less tech-savvy users) will have longer time to<br>
upgrade<br>
b. The stage 2 is opt-in for full nodes.<br>
c. The stage 3 is opt-in for light nodes.<br>
<br>
Cons:<br>
a. The stage 2 is not opt-in for light nodes. They will blindly follow the<=
br>
longest chain which they might actually don't want to<br>
b. Non-upgraded full nodes will follow the old chain at Stage 2, which is<b=
r>
likely to have lower value.<br>
c. Non-upgraded light nodes will follow the old chain at Stage 3, which is<=
br>
likely to have lower value. (However, this is not a concern as no one shoul=
d<br>
be mining on the old chain at that time)<br>
<br>
-------------------------------<br>
An alternative roadmap would be:<br>
<br>
Stage 2 is fixes that will break existing full nodes and light nodes.<br>
However, they will not follow the minority chain<br>
a. Increase the MAX_BLOCK_SIZE, potentially change the witness discount<br>
b. Anti-DoS rules for the O(n^2) validation of non-segwit scripts<br>
c. Change the header format to Luke-Jr's proposal, and move all commitm=
ents<br>
(tx, witness, etc) to the new structure.<br>
This may happen in mid 2017 or later<br>
<br>
Stage 3 is fixes that will break all existing full nodes and light nodes.<b=
r>
a. Full nodes and light nodes upgraded to Stage 2 will not need to upgrade<=
br>
again, as the rules and activation logic should be included already<br>
b. Reclaiming unused bits in header for mining. All existing mining chips<b=
r>
should still work.<br>
c. Fix the time warp attack<br>
This may happen in 2018 to 2019<br>
<br>
Pros:<br>
a. The stage 2 and 3 are opt-in for everyone<br>
b. Even failing to upgrade, full nodes and light nodes won't follow the=
<br>
minority chain at stage 2<br>
<br>
Cons:<br>
a. Non-upgraded full/light nodes will follow the old chain at Stage 3, whic=
h<br>
is likely to have lower value. (However, this is not a concern as no one<br=
>
should be mining on the old chain at that time)<br>
b. It takes longer to implement stage 2 to give enough time for light node<=
br>
users to upgrade<br>
<br>
-------------------------------<br>
<br>
In terms of safety, the second proposal is better. In terms of disruption,<=
br>
the first proposal is less disruptive<br>
<br>
I would also like to emphasize that it is miners' responsibility, not t=
he<br>
devs', to confirm that the supermajority of the community accept change=
s in<br>
Stage 2 and 3.<br>
<br>
Reference:<br>
Matt Corallo's proposal:<br>
<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Febr=
uary/012403.
html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2016-February/012403.<br>
html</a><br>
Luke-Jr's proposal:<br>
<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Febr=
uary/012377.
html" rel=3D"noreferrer" target=3D"_blank">http://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2016-February/012377.<br>
html</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
--001a113eb3241858b3052b5850f5--
|