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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6BE73E0C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 14:15:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DA5A4144
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Feb 2016 14:15:52 +0000 (UTC)
Received: from 119246245241.ctinets.com ([119.246.245.241]:50987 helo=2012R2)
by server47.web-hosting.com with esmtpsa
(TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86)
(envelope-from <jl2012@xbt.hk>) id 1aT955-002vPq-4W
for bitcoin-dev@lists.linuxfoundation.org;
Tue, 09 Feb 2016 09:15:51 -0500
From: <jl2012@xbt.hk>
To: <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 9 Feb 2016 22:16:15 +0800
Message-ID: <239b01d16344$717712d0$54653870$@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdFjPCfq2WqZcTB2TK+sxTx7uSOT6w==
Content-Language: en-hk
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: [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 14:15:53 -0000
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
|
