Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 290CF3C8 for ; Tue, 21 Jul 2015 22:05:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a60.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id F1BF4112 for ; Tue, 21 Jul 2015 22:05:15 +0000 (UTC) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 48B4F3BC078; Tue, 21 Jul 2015 15:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to :references:cc:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=jrn.me.uk; bh=Vj+bjNa 9wVW+MP0VgMS2umS8Ers=; b=1ehMldXj71+aT1K1AqHxtuNSy9guFjZkQwHHOns qJOWmyhmQ5VziHWtT6iZwymeNt084TPPe91Li9Skz046QRJvlg95F6V5Mlns1Bz/ ab4XKmm548hmAD6BVtitvpOq/AyAO3kVCpF1EcMYyOJE4RMN4IgMaIC/bQ08jOe2 I0jk= 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-a60.g.dreamhost.com (Postfix) with ESMTPSA id A9DC53BC073; Tue, 21 Jul 2015 15:05:14 -0700 (PDT) To: =?UTF-8?Q?Jorge_Tim=c3=b3n?= References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> From: Ross Nicoll Message-ID: <55AEC21A.3090302@jrn.me.uk> Date: Tue, 21 Jul 2015 23:05:14 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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] 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: Tue, 21 Jul 2015 22:05:17 -0000 Not so much that the implementation is difficult, as it requires context=20 to validate a block size, rather than being able to validate it without=20 requiring the preceeding blocks. Yes, time on different machines may=20 vary, but block time is safe to use for this, because it's a=20 straight-forward test of "if block time is acceptable and block time is=20 after then maximum block size allowed is n MB otherwise m MB". Ross On 21/07/2015 10:26, Jorge Tim=C3=B3n wrote: > I still disagree. Using height instead of time may make the > implementation more complex by requiring some additional preparations > but using height is in fact a simpler design. Why relay on clocks that > we know will differ in different computers and places when we have a > universal tick with every block? > > Btw, BIP16 and BIP34 could be changed to height-based activation > already. BIP16 simply should have used height instead of time from the > beginning. > > On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev > wrote: >> Further to that - please disregard what I said about using block heigh= t. 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 i= n 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 l= ot >> more wiggle room in the interim at least; one of my concerns with bloc= k 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 withou= t risk >> of an adoption spike rendering it essentially unusable. >> >> I'd favour switching over by block height rather than time, and I'd su= ggest >> 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 wi= th 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 thi= s >> solution is at least available and a known quantity. A good backup pl= an. >> >> Benefits: conservative increase. proves network can upgrade. permit= s some >> added growth, while the community & market gathers data on how an incr= eased >> block size impacts privacy, security, centralization, transaction thro= ughput >> 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 roa= d. >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>