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
|
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 F40B37A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 09:54:59 +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 5298389
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 09:54:59 +0000 (UTC)
Received: from localhost ([::1]:52535 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>) id 1ZRdbc-000pB5-S4
for bitcoin-dev@lists.linuxfoundation.org;
Tue, 18 Aug 2015 05:54:56 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 18 Aug 2015 05:54:56 -0400
From: jl2012@xbt.hk
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
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-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20,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
Subject: [bitcoin-dev] =?utf-8?q?Bitcoin_is_an_experiment=2E_Why_don=27t_w?=
=?utf-8?q?e_have_an_experimental_hardfork=3F?=
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, 18 Aug 2015 09:55:00 -0000
As I understand, there is already a consensus among core dev that block
size should/could be raised. The remaining questions are how, when, how
much, and how fast. These are the questions for the coming Bitcoin
Scalability Workshops but immediate consensus in these issues are not
guaranteed.
Could we just stop the debate for a moment, and agree to a scheduled
experimental hardfork?
Objectives (by order of importance):
1. The most important objective is to show the world that reaching
consensus for a Bitcoin hardfork is possible. If we could have a
successful one, we would have more in the future
2. With a slight increase in block size, to collect data for future
hardforks
3. To slightly relieve the pressure of full block, without minimal
adverse effects on network performance
With the objectives 1 and 2 in mind, this is to NOT intended to be a
kick-the-can-down-the-road solution. The third objective is more like a
side effect of this experiment.
Proposal (parameters in ** are my recommendations but negotiable):
1. Today, we all agree that some kind of block size hardfork will happen
on t1=*1 June 2016*
2. If no other consensus could be reached before t2=*1 Feb 2016*, we
will adopt the backup plan
3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
4. If the backup plan is adopted, we all agree that a better solution
should be found before t4=*31 Dec 2017*.
Rationale:
t1 = 1 June 2016 is chosen to make sure everyone have enough time to
prepare for a hardfork. Although we do not know what actually will
happen but we know something must happen around that moment.
t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2
months after the workshops). If it is successful, we don't need to
activate the backup plan
t3 = 30 days is chosen to make sure every full nodes have enough time to
upgrade after the actual hardfork date is confirmed
t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate,
hopefully we would find a better solution. It is important to
acknowledge that the backup plan is not a final solution
m = 80%: We don't want a very small portion of miners to have the power
to veto a hardfork, while it is important to make sure the new fork is
secured by enough mining power. 80% is just a compromise.
s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that
all types of technology has since improved by >50%. I don't mind making
it a bit smaller but in that case not much valuable data could be
gathered and the second objective of this experiment may not be
archived.
--------------------
If the community as a whole could agree with this experimental hardfork,
we could announce the plan on bitcoin.org and start coding of the patch
immediately. At the same time, exploration for a better solution
continues. If no further consensus could be reached, a new version of
Bitcoin Core with the patch will be released on or before 1 Feb 2016 and
everyone will be asked to upgrade immediately.
|
