path: root/f5/9b489f25dbede29cdc2d53f1a9ec89ebfd3080

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 2CBB67AA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 21:39:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com
	[209.85.218.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E41E117B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 21:39:02 +0000 (UTC)
Received: by oio137 with SMTP id 137so109699220oio.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 18 Aug 2015 14:39:02 -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=c6RHV/QaDO/O7o314gSVkPpNGHAlGBCiQnrNxv7UrDk=;
	b=PtFwYaTxdF4qBUC0wWijEGli/ZMgMkAXAv3enQSaiPijMF1WRVXV9grAS+njnBn5A/
	wpoA8r9LTlvEz13d9cqxz0FoRdGyhJdzz6kgEj6dngqwuPTrUWvGROTQtfwMupsFZDnR
	3C5w52q/akqBVCAfJ5/Npklu0Lfop8sbhdxcdXPKIwo8T4xMDvmWwUnE0FhV/ymRYga3
	ANroeTDhCK1SvqFJgZWnc+Ec9Fwz5UwnuugLxor8vqVWNPX+/jkd6FTROfhidYhHdVg9
	V504X+yFafaPCEjcLjLU2viLU1F4Oq/LoeCgBJNFqWSqr8s4HgOVdB9o8QYMHSTIqTJj
	eGJA==
MIME-Version: 1.0
X-Received: by 10.202.194.9 with SMTP id s9mr7591481oif.39.1439933942252; Tue,
	18 Aug 2015 14:39:02 -0700 (PDT)
Received: by 10.202.134.78 with HTTP; Tue, 18 Aug 2015 14:39:02 -0700 (PDT)
In-Reply-To: <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>
	<B221AEB4-BEAD-4D50-B029-C98EB5514197@gmail.com>
Date: Tue, 18 Aug 2015 14:39:02 -0700
Message-ID: <CAJN5wHX+_xQsdoZjZ7ASUBaV1WN1aA8ZZu8LPUFOSQcvzP4wtw@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a113dc33420cc10051d9cbf7b
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:39:04 -0000

--001a113dc33420cc10051d9cbf7b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Again, I'm not suggesting further testing in sterile environments.  I'm
suggesting testing on the public global testnet network, so that real-world
hazards such as network lag, bandwidth constraints, traffic bottlenecks,
etc can wreak what havoc they can on the proposed implementation.  Also, a
test deployment would give more people an opportunity to see how the
proposed implementation works and "kick the tires", which might help to
reduce some degree of angst about the proposals.

Your point appears to be that the biggest challenge facing Bitcoin is not
technical, but political. Sadly, you may be right.

On Tue, Aug 18, 2015 at 2:17 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:

> 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:
>
> 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.
>
> And when I refer to testnet, I mean the public global testnet blockchain,
> not in-house isolated networks like testnet-in-a-box.
>
> On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <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 deploym=
ent
>> amounts to =E2=80=9Chey guys, let=E2=80=99s install the new version=E2=
=80=9D
>>
>> On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Deploying experimental code onto the "live" bitcoin blockchain seems
>> unnecessarily risky.  Why not deploy a blocksize limit experiment for lo=
ng
>> 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 succes=
sful
>>> 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 happe=
n
>>> on t1=3D*1 June 2016*
>>>
>>> 2. If no other consensus could be reached before t2=3D*1 Feb 2016*, we
>>> will adopt the backup plan
>>>
>>> 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.5M=
B*
>>>
>>> 4. If the backup plan is adopted, we all agree that a better solution
>>> should be found before t4=3D*31 Dec 2017*.
>>>
>>> Rationale:
>>>
>>> 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 happ=
en
>>> but we know something must happen around that moment.
>>>
>>> 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 acti=
vate
>>> the backup plan
>>>
>>> t3 =3D 30 days is chosen to make sure every full nodes have enough time=
 to
>>> upgrade after the actual hardfork date is confirmed
>>>
>>> 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 acknowled=
ge
>>> that the backup plan is not a final solution
>>>
>>> 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
>>> secured by enough mining power. 80% is just a compromise.
>>>
>>> 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.
>>>
>>> --------------------
>>>
>>> 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 contin=
ues.
>>> 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 wi=
ll
>>> be asked to upgrade immediately.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>
>

--001a113dc33420cc10051d9cbf7b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Again, I&#39;m not suggesting further testing in sterile e=
nvironments.=C2=A0 I&#39;m suggesting testing on the public global testnet =
network, so that real-world hazards such as network lag, bandwidth constrai=
nts, traffic bottlenecks, etc can wreak what havoc they can on the proposed=
 implementation.=C2=A0 Also, a test deployment would give more people an op=
portunity to see how the proposed implementation works and &quot;kick the t=
ires&quot;, which might help to reduce some degree of angst about the propo=
sals.<div><br></div><div>Your point appears to be that the biggest challeng=
e facing Bitcoin is not technical, but political. Sadly, you may be right.<=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue=
, Aug 18, 2015 at 2:17 PM, Eric Lombrozo <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:elombrozo@gmail.com" target=3D"_blank">elombrozo@gmail.com</a>&gt;</s=
pan> wrote:<br><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">People have already been testing big blocks on testnets.<div><br></d=
iv><div>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><br></div><div>1) Pissing off the other=
 side enough to the point where regardless of who wins the other side refus=
es to cooperate</div><div>2) Screwing up the incentive model, allowing peop=
le to sabotage the process somehow</div><div>3) Setting a precedent enablin=
g hostile entities to destroy the network from within in the future</div><d=
iv>etc=E2=80=A6</div><div><br></div><div>These kinds of things seem very ha=
rd to test on a testnet.</div><div><div class=3D"h5"><div><br><div><blockqu=
ote type=3D"cite"><div>On Aug 18, 2015, at 2:06 PM, Danny Thorpe &lt;<a hre=
f=3D"mailto:danny.thorpe@gmail.com" target=3D"_blank">danny.thorpe@gmail.co=
m</a>&gt; wrote:</div><br><div><div dir=3D"ltr"><div dir=3D"ltr" style=3D"f=
ont-size:12.8px">Ya, so?=C2=A0 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><br></div><div>And when I refer to te=
stnet, I mean the public global testnet blockchain, not in-house isolated n=
etworks like testnet-in-a-box.</div></div><div style=3D"font-size:12.8px"><=
div><img src=3D"https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gi=
f"></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:elombrozo@gmail.com" target=3D"_blank">elombrozo@gmail.com<=
/a>&gt;</span> wrote:<br><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">Problem is if you know most of the people running the test=
net 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><div><div><br><div><blockquote type=3D"cite"><div>On =
Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:</div><br><div><div dir=3D"ltr">Deployi=
ng experimental code onto the &quot;live&quot; bitcoin blockchain seems unn=
ecessarily risky.=C2=A0 Why not deploy a blocksize limit experiment for lon=
g term trials using testnet instead?</div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoi=
n-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">As I understand, there is al=
ready a consensus among core dev that block size should/could be raised. Th=
e remaining questions are how, when, how much, and how fast. These are the =
questions for the coming Bitcoin Scalability Workshops but immediate consen=
sus 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"noreferr=
er" target=3D"_blank">bitcoin.org</a> and start coding of the patch immedia=
tely. 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 t=
o 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>
_______________________________________________<br>bitcoin-dev mailing list=
<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"https://lists.l=
inuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://=
lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></block=
quote></div><br></div></div></div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br=
></div>

--001a113dc33420cc10051d9cbf7b--