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 3926640C for ; Fri, 17 Jul 2015 19:06:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 71F4714F for ; Fri, 17 Jul 2015 19:06:34 +0000 (UTC) Received: by ykay190 with SMTP id y190so96979134yka.3 for ; Fri, 17 Jul 2015 12:06:33 -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 :content-type; bh=zMq1lxlHLzYb9RcHqFrZpjaLEtAuEyWFElReZXAytqA=; b=KEx/72Ku6bgapesbWTCwao/XhTMes0LAIgLeZfGmGJw4m/H2wyAA7j7n+Aa8o6DG51 Iizrkh5VkHo5OH8k5srN+cW4J3k132YksZ3rBd9HPZMtxWmP21pms4fYUyVJ+b6n83Jn kOGMVQGlTxxsVIOs99FEv9NFZaQ2N3+s2WKJX8/52re6G8//1lla6DnztdEBZHIoYmqx hS319HN3cWWA/e1uUnYSuIHrRhDKvRkV9sQGgMYSLEdsL+3MBcKzQMDLm2Vk0KnpRqXM UuGQATBjX6lXz0/ebKrOdjAqmkL/6u9Cw3ZzNYdQ8impB6DjTbEBk0em8enQ9+ZDMmFn WWSw== MIME-Version: 1.0 X-Received: by 10.170.143.213 with SMTP id k204mr16629363ykc.91.1437159993717; Fri, 17 Jul 2015 12:06:33 -0700 (PDT) Received: by 10.37.76.135 with HTTP; Fri, 17 Jul 2015 12:06:33 -0700 (PDT) In-Reply-To: <55A9421B.6040605@jrn.me.uk> References: <55A9421B.6040605@jrn.me.uk> Date: Fri, 17 Jul 2015 15:06:33 -0400 Message-ID: From: Chris Wardell To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1139909ce93d58051b16e29d 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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB 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: Fri, 17 Jul 2015 19:06:35 -0000 --001a1139909ce93d58051b16e29d Content-Type: text/plain; charset=UTF-8 I would prefer a dynamic solution that did not necessitate a second hard fork down the road. I propose doubling the block size every 100k blocks (~2 years) block 400,000 = 2MB (2016) block 500,000 = 4MB (2017) block 600,000 = 8MB (2018) Chris On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'd back this if we can't find a permanent solution - 2MB gives us a lot > more wiggle room in the interim at least; one of my concerns with block > size is 3 transactions per second is absolutely tiny, and we need space for > the network to search for an equilibrium between volume and pricing without > risk of an adoption spike rendering it essentially unusable. > > I'd favour switching over by block height rather than time, and I'd > suggest that given virtually every wallet/node out there will require > testing (even if many do not currently enforce a limit and therefore do not > need changing), 6 months should be considered a minimum target. I'd open > with a suggestion of block 390k as a target. > > Ross > > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: > > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan > to my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits > some added growth, while the community & market gathers data on how an > increased block size impacts privacy, security, centralization, transaction > throughput and other metrics. 2MB seems to be a Least Common Denominator > on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > > _______________________________________________ > bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1139909ce93d58051b16e29d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would prefer a dynamic solution= that did not necessitate a second hard fork down the road.

I = propose doubling the block size every 100k blocks (~2 years)

b= lock 400,000 =3D 2MB (2016)
block 500,000 =3D 4MB (2017)
= block 600,000 =3D 8MB (2018)

Chris


On Fri, J= ul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundation.org> wrote:
=20 =20 =20
I'd back this if we can't find a permanent solution - 2MB gives= us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable.

I'd favour switching over by block height rather than time, and I&#= 39;d suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target.

Ross


On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
Opening a mailing list thread on this BIP:

BIP PR:=C2=A0https://github.com/bitcoin/bips/pull/173

The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100).

If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity.=C2=A0 A good backup plan.

Benefits: =C2=A0conservative increase. =C2=A0proves network ca= n upgrade. =C2=A0permits some added growth, while the community &am= p; market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. =C2=A02MB seems to be a Least Common Denominator o= n an increase.

Costs: =C2=A0requires a hard fork. =C2=A0requires another hard= fork down the road.




___________________________________=
____________
bitcoin-dev mailing list
=
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a1139909ce93d58051b16e29d--