path: root/27/905f9a7fa598ec674907dea97cf54fb2dfea06

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C5AF486
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 21:17:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com
	[209.85.220.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 60162191
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 21:17:50 +0000 (UTC)
Received: by pabyb7 with SMTP id yb7so140781185pab.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 14:17:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=LjyBsC1nXEw85L+LiDps6ba8bksAw1uTNfRHAFFSDxs=;
	b=ksMpjnocWpoEd425jZV0FENGWOKBUwt6+aW2uJxE9BW5JburXmViWLog08gSJNOYd3
	l7v1luKpVx5Z6qq3tdE/C0+QhzD96rzDqBsqZLmlos++AxhPpdZlzFVB+r4NQ1WEjARH
	RkBp3dGCRBBeQQ301azZm48+ykTbyKr1o3Y7Yyhpr10RbaHLItW+9uwwWmtzqhiRw5tj
	g1L8ooVU1XjGMBfyoJe061lKBh14REN/Te+NUGGWxTV5vHaYS71PT6x87A6CAWB++jtj
	96rvYGx5e/+BALR+WUg0X9IJrPN4euojPkGeQWEsx98AOoUCx53sYMoKxImWfztX28mv
	2TRA==
X-Received: by 10.66.255.67 with SMTP id ao3mr17325717pad.60.1439932670033;
	Tue, 18 Aug 2015 14:17:50 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	em1sm19090906pbd.42.2015.08.18.14.17.42
	(version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 18 Aug 2015 14:17:45 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_FAE48236-1DCA-472D-A354-7D6AC9F84CD9";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAJN5wHXRwQZ6YmiZiCE9Gx4d-3FTzy1Zv7i2noia0mwtRwVL+w@mail.gmail.com>
Date: Tue, 18 Aug 2015 14:17:41 -0700
Message-Id: <B221AEB4-BEAD-4D50-B029-C98EB5514197@gmail.com>
References: <d17549688c0c747b2077c1f6f96b6445@xbt.hk>
	<CAJN5wHV-qyOcEw5spQc74nT7_b29WMiDTmi4Jj0ri_rGCQz2ng@mail.gmail.com>
	<E9543641-9D73-4A00-9CB3-FAB62BFB490E@gmail.com>
	<CAJN5wHXRwQZ6YmiZiCE9Gx4d-3FTzy1Zv7i2noia0mwtRwVL+w@mail.gmail.com>
To: Danny Thorpe <danny.thorpe@gmail.com>
X-Mailer: Apple Mail (2.2098)
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 21:17:51 -0000


--Apple-Mail=_FAE48236-1DCA-472D-A354-7D6AC9F84CD9
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_12049635-2E54-4CE0-A667-82FB3EE19DFE"


--Apple-Mail=_12049635-2E54-4CE0-A667-82FB3EE19DFE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

People have already been testing big blocks on testnets.

The biggest problem here isn=E2=80=99t whether we can test the code in a =
fairly sterile environment. The biggest problem is convincing enough =
people to switch without:

1) Pissing off the other side enough to the point where regardless of =
who wins the other side refuses to cooperate
2) Screwing up the incentive model, allowing people to sabotage the =
process somehow
3) Setting a precedent enabling hostile entities to destroy the network =
from within in the future
etc=E2=80=A6

These kinds of things seem very hard to test on a testnet.

> On Aug 18, 2015, at 2:06 PM, Danny Thorpe <danny.thorpe@gmail.com> =
wrote:
>=20
> Ya, so?  All that means is that the experiment might reach the hard =
fork tipping point faster than mainnet would. Verifying that the network =
can handle such transitions, and how larger blocks affect the network, =
is the point of testing.
>=20
> And when I refer to testnet, I mean the public global testnet =
blockchain, not in-house isolated networks like testnet-in-a-box.
>=20
>=20
> On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <elombrozo@gmail.com =
<mailto:elombrozo@gmail.com>> wrote:
> Problem is if you know most of the people running the testnet =
personally (as is pretty much the case with many current testnets) then =
the deployment amounts to =E2=80=9Chey guys, let=E2=80=99s install the =
new version=E2=80=9D
>=20
>> On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>=20
>> 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?
>>=20
>> On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto: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.
>>=20
>> Could we just stop the debate for a moment, and agree to a scheduled =
experimental hardfork?
>>=20
>> Objectives (by order of importance):
>>=20
>> 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
>>=20
>> 2. With a slight increase in block size, to collect data for future =
hardforks
>>=20
>> 3. To slightly relieve the pressure of full block, without minimal =
adverse effects on network performance
>>=20
>> 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.
>>=20
>>=20
>> Proposal (parameters in ** are my recommendations but negotiable):
>>=20
>> 1. Today, we all agree that some kind of block size hardfork will =
happen on t1=3D*1 June 2016*
>>=20
>> 2. If no other consensus could be reached before t2=3D*1 Feb 2016*, =
we will adopt the backup plan
>>=20
>> 3. The backup plan is: t3=3D*30 days* after m=3D*80%* of miner =
approval, but not before t1=3D*1 June 2016*, the block size is increased =
to s=3D*1.5MB*
>>=20
>> 4. If the backup plan is adopted, we all agree that a better solution =
should be found before t4=3D*31 Dec 2017*.
>>=20
>> Rationale:
>>=20
>> t1 =3D 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.
>>=20
>> t2 =3D 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
>>=20
>> t3 =3D 30 days is chosen to make sure every full nodes have enough =
time to upgrade after the actual hardfork date is confirmed
>>=20
>> t4 =3D 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
>>=20
>> m =3D 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.
>>=20
>> 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.
>>=20
>> --------------------
>>=20
>> If the community as a whole could agree with this experimental =
hardfork, we could announce the plan on bitcoin.org =
<http://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 =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20


--Apple-Mail=_12049635-2E54-4CE0-A667-82FB3EE19DFE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">People have already been testing big blocks on testnets.<div =
class=3D""><br class=3D""></div><div class=3D"">The biggest problem here =
isn=E2=80=99t whether we can test the code in a fairly sterile =
environment. The biggest problem is convincing enough people to switch =
without:</div><div class=3D""><br class=3D""></div><div class=3D"">1) =
Pissing off the other side enough to the point where regardless of who =
wins the other side refuses to cooperate</div><div class=3D"">2) =
Screwing up the incentive model, allowing people to sabotage the process =
somehow</div><div class=3D"">3) Setting a precedent enabling hostile =
entities to destroy the network from within in the future</div><div =
class=3D"">etc=E2=80=A6</div><div class=3D""><br class=3D""></div><div =
class=3D"">These kinds of things seem very hard to test on a =
testnet.</div><div class=3D""><br class=3D""><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Aug 18, 2015, at 2:06 PM, =
Danny Thorpe &lt;<a href=3D"mailto:danny.thorpe@gmail.com" =
class=3D"">danny.thorpe@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div dir=3D"ltr" style=3D"font-size:12.8px" class=3D"">Ya, =
so?&nbsp; All that means is that the experiment might reach the hard =
fork tipping point faster than mainnet would. Verifying that the network =
can handle such transitions, and how larger blocks affect the network, =
is the point of testing.<div class=3D""><br class=3D""></div><div =
class=3D"">And when I refer to testnet, I mean the public global testnet =
blockchain, not in-house isolated networks like =
testnet-in-a-box.</div></div><div class=3D"yj6qo ajU" =
style=3D"font-size:12.8px"><div id=3D":of" class=3D"ajR" =
tabindex=3D"0"><img class=3D"ajT" =
src=3D"https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" =
style=3D"opacity: 0.3;"></div></div></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Tue, Aug 18, 2015 at 1:51 PM, =
Eric Lombrozo <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:elombrozo@gmail.com" target=3D"_blank" =
class=3D"">elombrozo@gmail.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D"">Problem is if you know most of =
the people running the testnet personally (as is pretty much the case =
with many current testnets) then the deployment amounts to =E2=80=9Chey =
guys, let=E2=80=99s install the new version=E2=80=9D<div class=3D""><div =
class=3D"h5"><div class=3D""><br class=3D""><div class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Aug 18, 2015, at 1:48 PM, =
Danny Thorpe via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">Deploying =
experimental code onto the "live" bitcoin blockchain seems unnecessarily =
risky.&nbsp; Why not deploy a blocksize limit experiment for long term =
trials using testnet instead?</div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Tue, Aug 18, 2015 at 2:54 AM, =
jl2012 via bitcoin-dev <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=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 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.<br =
class=3D"">
<br class=3D"">
Could we just stop the debate for a moment, and agree to a scheduled =
experimental hardfork?<br class=3D"">
<br class=3D"">
Objectives (by order of importance):<br class=3D"">
<br class=3D"">
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<br class=3D"">
<br class=3D"">
2. With a slight increase in block size, to collect data for future =
hardforks<br class=3D"">
<br class=3D"">
3. To slightly relieve the pressure of full block, without minimal =
adverse effects on network performance<br class=3D"">
<br class=3D"">
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.<br class=3D"">
<br class=3D"">
<br class=3D"">
Proposal (parameters in ** are my recommendations but negotiable):<br =
class=3D"">
<br class=3D"">
1. Today, we all agree that some kind of block size hardfork will happen =
on t1=3D*1 June 2016*<br class=3D"">
<br class=3D"">
2. If no other consensus could be reached before t2=3D*1 Feb 2016*, we =
will adopt the backup plan<br class=3D"">
<br class=3D"">
3. The backup plan is: t3=3D*30 days* after m=3D*80%* of miner approval, =
but not before t1=3D*1 June 2016*, the block size is increased to =
s=3D*1.5MB*<br class=3D"">
<br class=3D"">
4. If the backup plan is adopted, we all agree that a better solution =
should be found before t4=3D*31 Dec 2017*.<br class=3D"">
<br class=3D"">
Rationale:<br class=3D"">
<br class=3D"">
t1 =3D 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.<br =
class=3D"">
<br class=3D"">
t2 =3D 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<br class=3D"">
<br class=3D"">
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 class=3D"">
<br class=3D"">
t4 =3D 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<br class=3D"">
<br class=3D"">
m =3D 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.<br =
class=3D"">
<br class=3D"">
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'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 class=3D"">
<br class=3D"">
--------------------<br class=3D"">
<br class=3D"">
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"noreferrer" target=3D"_blank" class=3D"">bitcoin.org</a> 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.<br =
class=3D"">
_______________________________________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
 class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
</blockquote></div><br class=3D""></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D""></div></blockquote></div><br =
class=3D""></div></div></div></div></blockquote></div><br =
class=3D""></div>
</div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_12049635-2E54-4CE0-A667-82FB3EE19DFE--

--Apple-Mail=_FAE48236-1DCA-472D-A354-7D6AC9F84CD9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV06D1AAoJEJNAI64YFENUyZcQALLEqR6vbCzaZKMRN0Lby1tB
vf1KDMoS6tJOlRh41oY14FKufw9u3W8kHJjKQiWUP4LpLdAdcZ4eMN9hMF/Qb+L+
Ppqcoku1RTQGFcTuZJLX+3TebDPb0trBxnnDRYG0HtHrBHBP3o5+2eDleg3eyscO
R5yJVnTsr9Y4sVkdMaIds05Ei/0Xpa3zXXR4oJuIQDKxnJ95uv6PoPINQB6rVl6f
a5LFqyoEYCJRcN2w5O1lLMBQSulgJoaSMCdY4dIbDbDlZLgJSNNxHrHaW4Wjt+k9
efmZhHkPZ2AIJO9fkG4gjYnqb3u2v9Elpt4R406UrRo6Dw17gufaeikRjyzItSmC
dmja9panMSErjzZLVoAfTCqnyxapr3uZhfK/rgJPwry2chnwxUyMB1OOEESFTOjm
c7U3I0jif7afbtrdKPZS2DWwfPomM4oRjG3GQgg2ndL7zj/Uhq97yRMgaacvuw16
2kwgRA01eVQlTfCeGaseGslTuj7dTCM/WeNdXqG2xbN9P5tCgn0ovCUv4/uv+wun
hjoSXNFCyaa9nHXaYjC+XeS1ynz9+/dyvPyCXbTWUsOxGUpjQUwDZcIa0sRV0rUN
q81m8DzTBNDqgvSAfs5qvjUYonIqOIOjMeVfaZPosBxKuFEi0wwAA7A9CDzeyamW
PnJau26VFYuA2lLFKFE0
=YG4R
-----END PGP SIGNATURE-----

--Apple-Mail=_FAE48236-1DCA-472D-A354-7D6AC9F84CD9--