path: root/7e/c28ccab2ec31e79ae48124b47a8ca5f13c2374

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 &quot;live&quot; 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">&lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt;</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&#39;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&#39;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 &gt;50%. I don&#39;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--