Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C0C17279 for ; Sun, 19 Jul 2015 22:51:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a7.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0802FE9 for ; Sun, 19 Jul 2015 22:51:09 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 61B2125C072 for ; Sun, 19 Jul 2015 15:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to :references:from:message-id:date:mime-version:in-reply-to: content-type; s=jrn.me.uk; bh=YS2dfpktmsvp9zIH1fXDVGX0M3A=; b=sL gGDs8h7TvS1R9cmWoLgdb8zAY+xDBHjk0LcpgOm7Q+2jcdwPpmjX9ul4jkPtcDL1 AccI/oa6lezRoZbNFqJaT/+RL+rHILcgR//PWEOWF9DveVErfl5UU2tAE6pNJMil uAvABgybtPAlLvYb2LlemAVhRjaGnIaGYozc5L54E= Received: from [192.168.0.4] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net [86.30.131.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id D9B7B25C075 for ; Sun, 19 Jul 2015 15:51:08 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <55A9421B.6040605@jrn.me.uk> From: Ross Nicoll Message-ID: <55AC29DB.4060800@jrn.me.uk> Date: Sun, 19 Jul 2015 23:51:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55A9421B.6040605@jrn.me.uk> Content-Type: multipart/alternative; boundary="------------090007010103030407090103" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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: Sun, 19 Jul 2015 22:51:10 -0000 This is a multi-part message in MIME format. --------------090007010103030407090103 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Further to that - please disregard what I said about using block height. Had failed to realise that in using contextual information (block height) it complicates block validation (i.e. it would be impossible to tell if a block is too big, without having all previous blocks first). Block time is in fact the better option. Ross On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev 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 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 --------------090007010103030407090103 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Further to that - please disregard what I said about using block height. Had failed to realise that in using contextual information (block height) it complicates block validation (i.e. it would be impossible to tell if a block is too big, without having all previous blocks first). Block time is in fact the better option.

Ross

On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev 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:=A0https://git= hub.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.=A0 A good backup plan.

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

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




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfounda=
tion.org
https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev




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

--------------090007010103030407090103--