Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C5AF486 for ; 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 ; Tue, 18 Aug 2015 21:17:50 +0000 (UTC) Received: by pabyb7 with SMTP id yb7so140781185pab.0 for ; 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 In-Reply-To: Date: Tue, 18 Aug 2015 14:17:41 -0700 Message-Id: References: To: Danny Thorpe 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 > 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 = > 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 = > 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 = 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 = >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org = >> 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 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 deployment 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 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=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.5MB*

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 = happen 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 = activate 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 = acknowledge 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 = 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 =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 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<= /a>

_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>



= --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--