From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A59B8279 for ; 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 ; Tue, 18 Aug 2015 20:48:50 +0000 (UTC) Received: by obbop1 with SMTP id op1so152402795obb.2 for ; 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: References: Date: Tue, 18 Aug 2015 13:48:49 -0700 Message-ID: From: Danny Thorpe 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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?

On Tue, Aug 18, 2015 at 2:= 54 AM, jl2012 via bitcoin-dev <bitcoin-dev@lists.linux= foundation.org> wrote:
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.

Could we just stop the debate for a moment, and agree to a scheduled experi= mental hardfork?

Objectives (by order of importance):

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

2. With a slight increase in block size, to collect data for future hardfor= ks

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-t= he-can-down-the-road solution. The third objective is more like a side effe= ct 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, bu= t 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 shoul= d be found before t4=3D*31 Dec 2017*.

Rationale:

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.

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

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, hop= efully 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 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.

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 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.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e01537b229213f8051d9c0b46--