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 C8242305 for ; Mon, 22 Jun 2015 20:46:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E9EDF144 for ; Mon, 22 Jun 2015 20:46:53 +0000 (UTC) Received: by lagi2 with SMTP id i2so27925983lag.2 for ; Mon, 22 Jun 2015 13:46:52 -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=w7HrZVMnB/Gh6CxXWXk75waoiK7GSFqAwbqzVEHo8v0=; b=YAAM+PcJOxL0ga7Nxqhi7Gh0yJqTjCp+Hkr5qFVvQjD5LTZoQrHzdYMabR6hDdLqJ/ FGfOzd2EgL9VWT1hiNGzXHFrJ2PFEDv0C9/FwsnLS9OCZcOayGq/eq41AX2J1YDBM0nh EDDe18gAYcd+kWSHDH4/fbgXwz3ksdMg1WOx+BdhvxcYgAUjDLe5RXFK955iShK1iZFk rYKG2G/sJ3HrXz5eeM+xDHnfwqunBVqpAcwmNiOlDAaWHKba97b7Y0BtKhMdM9ot6PZN ocYApDtoEhQqCpXNdCRmMDDLsPi5f+0PvVmvac0YW4jh+79BLXRQzrZR0RcZ3VE5UM06 0Fgg== MIME-Version: 1.0 X-Received: by 10.152.115.199 with SMTP id jq7mr3950933lab.113.1435006011832; Mon, 22 Jun 2015 13:46:51 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Mon, 22 Jun 2015 13:46:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Jun 2015 16:46:51 -0400 Message-ID: From: Gavin Andresen To: Kalle Rosenbaum Content-Type: multipart/alternative; boundary=001a11c2588e95ff050519215fb2 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] 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 20:46:54 -0000 --001a11c2588e95ff050519215fb2 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum wrote: > * In the specification, you refer to "t_start". I guess you mean > "time_start"? > Thanks, I'll fix. > * Miners can, especially when close to a block doubling or shortly > after activation, to some extent manipulate max block size by > manipulating the time stamp in the block header within valid limits. > According to the pseudo code in the specification, the first and a > handful of subsequent blocks after activation could actually have > negative max block sizes due to this (depending on how you define the > % operator of the pseudo code). I haven't checked the reference > implementation, but I do think that the specification section should > explicitly handle this. > Excellent point. That could only happen if activation happened on 11 Jan 2016; instead of complicating the code and spec with another condition, I think it would be better to specify that the activation date is the later of the miner supermajority and 11 Jan, with the first big block two weeks later. -- -- Gavin Andresen --001a11c2588e95ff050519215fb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum <kalle@rosenbaum.se>= wrote:
* In the specification, yo= u refer to "t_start". I guess you mean "time_start"?

Thanks, I'll fix.
=C2=A0
* Miners can, especially when close to a block doubling or shortly
after activation, to some extent manipulate max block size by
manipulating the time stamp in the block header within valid limits.
According to the pseudo code in the specification, the first and a
handful of subsequent blocks after activation could actually have
negative max block sizes due to this (depending on how you define the
% operator of the pseudo code). I haven't checked the reference
implementation, but I do think that the specification section should
explicitly handle this.

Excellent point= . That could only happen if activation happened on 11 Jan 2016; instead of = complicating the code and spec with another condition, I think it would be = better to specify that the activation date is the later of the miner superm= ajority and 11 Jan, with the first big block two weeks later.
=C2= =A0

--
--
G= avin Andresen
--001a11c2588e95ff050519215fb2--