Return-Path: <gavinandresen@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C8242305 for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; Mon, 22 Jun 2015 20:46:53 +0000 (UTC) Received: by lagi2 with SMTP id i2so27925983lag.2 for <bitcoin-dev@lists.linuxfoundation.org>; 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: <CAPswA9wVEs6oH8CxafLvLy78bpC937HZccjXHwyq8JVMV7qiQA@mail.gmail.com> References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com> <CAPswA9wVEs6oH8CxafLvLy78bpC937HZccjXHwyq8JVMV7qiQA@mail.gmail.com> Date: Mon, 22 Jun 2015 16:46:51 -0400 Message-ID: <CABsx9T1KsOHF2u+Sk0c1d1U11ff-FJH9EjC4XNZP4-puWKE_Lg@mail.gmail.com> From: Gavin Andresen <gavinandresen@gmail.com> To: Kalle Rosenbaum <kalle@rosenbaum.se> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <kalle@rosenbaum.se> 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 <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M= on, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum <span dir=3D"ltr"><<a href= =3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se</a>>= </span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">* In the specification, yo= u refer to "t_start". I guess you mean "time_start"?<br= ></blockquote><div><br></div><div>Thanks, I'll fix.</div><div>=C2=A0</d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> * Miners can, especially when close to a block doubling or shortly<br> after activation, to some extent manipulate max block size by<br> manipulating the time stamp in the block header within valid limits.<br> According to the pseudo code in the specification, the first and a<br> handful of subsequent blocks after activation could actually have<br> negative max block sizes due to this (depending on how you define the<br> % operator of the pseudo code). I haven't checked the reference<br> implementation, but I do think that the specification section should<br> explicitly handle this.<br></blockquote><div><br></div><div>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.</div><div>=C2= =A0</div></div><div><br></div>-- <br><div class=3D"gmail_signature">--<br>G= avin Andresen<br></div> </div></div> --001a11c2588e95ff050519215fb2--