MIME-Version: 1.0
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

--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">&lt;<a href=
=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se</a>&gt;=
</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 &quot;t_start&quot;. I guess you mean &quot;time_start&quot;?<br=
></blockquote><div><br></div><div>Thanks, I&#39;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&#39;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--