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
|
Return-Path: <danny.thorpe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A59B8279
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 20:48:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com
[209.85.214.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C703719E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 20:48:50 +0000 (UTC)
Received: by obbop1 with SMTP id op1so152402795obb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Aug 2015 13:48:49 -0700 (PDT)
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=9HnSuSXj+iKrVfxnSz/2+B4vUHXXgj27NtfU3lq6uGE=;
b=Vea8pNVwFXG6LWiBtYrP/qPwySFKc0Qr47rUv9u2YI27Vct/avQJICPtsuZGWGMy0A
nYzoQwrSWgGuG4OmtPCuU5t2kvWaLckgWqrahXtQ6hWxpn6JLfyvK081vpvco19OAJfo
JqKnnKDmYCRnoE5/pU/+nVx/qh2a4kboZExkBfWKqjIYOtt9vMgp4Y5iBnpRaM6z25O9
ydxrV0b7/BcVIcAdneK+OOTzfHHToQV42Oh35nxQK7hpGqGLuUngu99hc1CukBUmIxSc
8zZSFjyz+7FNSc9l3w8ZTv5/KuL0ZoOLRrBsAqoFRXcnbjQOFRySBwFoNypiIOZ1xanU
Tx8w==
MIME-Version: 1.0
X-Received: by 10.182.250.137 with SMTP id zc9mr7457770obc.79.1439930929776;
Tue, 18 Aug 2015 13:48:49 -0700 (PDT)
Received: by 10.202.134.78 with HTTP; Tue, 18 Aug 2015 13:48:49 -0700 (PDT)
In-Reply-To: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
References: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
Date: Tue, 18 Aug 2015 13:48:49 -0700
Message-ID: <CAJN5wHV-qyOcEw5spQc74nT7_b29WMiDTmi4Jj0ri_rGCQz2ng@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=089e01537b229213f8051d9c0b46
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an
experimental hardfork?
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 20:48:51 -0000
--089e01537b229213f8051d9c0b46
Content-Type: text/plain; charset=UTF-8
Deploying experimental code onto the "live" bitcoin blockchain seems
unnecessarily risky. Why not deploy a blocksize limit experiment for long
term trials using testnet instead?
On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e01537b229213f8051d9c0b46
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Deploying experimental code onto the "live" bitc=
oin blockchain seems unnecessarily risky.=C2=A0 Why not deploy a blocksize =
limit experiment for long term trials using testnet instead?</div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 18, 2015 at 2:=
54 AM, jl2012 via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I=
understand, there is already a consensus among core dev that block size sh=
ould/could be raised. The remaining questions are how, when, how much, and =
how fast. These are the questions for the coming Bitcoin Scalability Worksh=
ops but immediate consensus in these issues are not guaranteed.<br>
<br>
Could we just stop the debate for a moment, and agree to a scheduled experi=
mental hardfork?<br>
<br>
Objectives (by order of importance):<br>
<br>
1. The most important objective is to show the world that reaching consensu=
s for a Bitcoin hardfork is possible. If we could have a successful one, we=
would have more in the future<br>
<br>
2. With a slight increase in block size, to collect data for future hardfor=
ks<br>
<br>
3. To slightly relieve the pressure of full block, without minimal adverse =
effects on network performance<br>
<br>
With the objectives 1 and 2 in mind, this is to NOT intended to be a kick-t=
he-can-down-the-road solution. The third objective is more like a side effe=
ct of this experiment.<br>
<br>
<br>
Proposal (parameters in ** are my recommendations but negotiable):<br>
<br>
1. Today, we all agree that some kind of block size hardfork will happen on=
t1=3D*1 June 2016*<br>
<br>
2. If no other consensus could be reached before t2=3D*1 Feb 2016*, we will=
adopt the backup plan<br>
<br>
3. The backup plan is: t3=3D*30 days* after m=3D*80%* of miner approval, bu=
t not before t1=3D*1 June 2016*, the block size is increased to s=3D*1.5MB*=
<br>
<br>
4. If the backup plan is adopted, we all agree that a better solution shoul=
d be found before t4=3D*31 Dec 2017*.<br>
<br>
Rationale:<br>
<br>
t1 =3D 1 June 2016 is chosen to make sure everyone have enough time to prep=
are for a hardfork. Although we do not know what actually will happen but w=
e know something must happen around that moment.<br>
<br>
t2 =3D 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2 m=
onths after the workshops). If it is successful, we don't need to activ=
ate the backup plan<br>
<br>
t3 =3D 30 days is chosen to make sure every full nodes have enough time to =
upgrade after the actual hardfork date is confirmed<br>
<br>
t4 =3D 31 Dec 2017 is chosen, with 1.5 year of data and further debate, hop=
efully we would find a better solution. It is important to acknowledge that=
the backup plan is not a final solution<br>
<br>
m =3D 80%: We don't want a very small portion of miners to have the pow=
er to veto a hardfork, while it is important to make sure the new fork is s=
ecured by enough mining power. 80% is just a compromise.<br>
<br>
s =3D 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.<br>
<br>
--------------------<br>
<br>
If the community as a whole could agree with this experimental hardfork, we=
could announce the plan on <a href=3D"http://bitcoin.org" rel=3D"noreferre=
r" target=3D"_blank">bitcoin.org</a> and start coding of the patch immediat=
ely. At the same time, exploration for a better solution continues. If no f=
urther consensus could be reached, a new version of Bitcoin Core with the p=
atch will be released on or before 1 Feb 2016 and everyone will be asked to=
upgrade immediately.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
--089e01537b229213f8051d9c0b46--
|