rich1.0npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwhttps://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kwnjumphttps://nostr.ae📅 Original date posted:2015-06-22 📝 Original message:On Mon, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum <kalle at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/adbbace4/attachment-0001.html>