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 B289583D for ; Mon, 22 Jun 2015 21:32:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2B11B153 for ; Mon, 22 Jun 2015 21:32:13 +0000 (UTC) Received: from homiemail-a4.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by hapkido.dreamhost.com (Postfix) with ESMTP id 8E6BF9E7C4 for ; Mon, 22 Jun 2015 14:32:12 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id B4F2C51C080 for ; Mon, 22 Jun 2015 14:32:11 -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=bBmJ+nJ56Bw5visETpTUhgbb/UM=; b=fn nid7ofgyvMWKutuP0tr6RGOaktVq4giOs+nqJy7tRpsWzZPwsqTynWeH9jxV2wr4 pzBu+RnB8vO7+TqyWlDZswga7D14ZeRtDQXdD5RcCScSMOijigOMRZfnPHwABITE It2D1vJy5jccnt0O0N9vk/zdJpG1HitoVDSX+s+n8= Received: from [192.168.0.6] (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-a4.g.dreamhost.com (Postfix) with ESMTPSA id 54A1051C074 for ; Mon, 22 Jun 2015 14:32:11 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <20150622205420.GA8892@savin.petertodd.org> From: Ross Nicoll Message-ID: <55887EDF.3070505@jrn.me.uk> Date: Mon, 22 Jun 2015 22:32:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070401020302090605090002" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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] Draft BIP : fixed-schedule block size increase 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: Mon, 22 Jun 2015 21:32:13 -0000 This is a multi-part message in MIME format. --------------070401020302090605090002 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Potentially daft question, why not use a minimum height? Yes, it's imprecise, but over an extended period of time they're good enough IMHO. I'd have to do more careful calculations to confirm, but block 388,000 should be about right as a minimum. Ross On 22/06/2015 22:04, Stephen Morse wrote: > > In the nVersion bits proposal that I co-authored we solved that > issue by > comparing the timestamp against the median time, which is > guaranteed by > the protocol rules to monotonically advance. > > > I'm also a fan of using the median time to ensure that there is a > clear point where the protocol change starts. Something like "blocks > only allow the larger block size if the associate pindex has > pindex->GetMedianTimePast() after midnight 11 Jan 2016 and where a > supermajority showing support for the fork has previously been reached". > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------070401020302090605090002 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Potentially daft question, why not use a minimum height? Yes, it's imprecise, but over an extended period of time they're good enough IMHO.

I'd have to do more careful calculations to confirm, but block 388,000 should be about right as a minimum.

Ross

On 22/06/2015 22:04, Stephen Morse wrote:

In = the nVersion bits proposal that I co-authored we solved that issue by
comparing the timestamp against the median time, which is guaranteed by
the protocol rules to monotonically advance.

I'm also a fan of using the median time to ensure that there is a clear point where the protocol change starts. Something like "blocks only allow the larger block size if the associate=A0pindex<= /font>=A0has=A0pindex->GetMedianTimePas= t() after=A0midnight 11 Jan 2016 and where a supermajority showing support for the fork has previously been reached".=A0


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

--------------070401020302090605090002--