{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-22\n📝 Original message:On Mon, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum \u003ckalle at rosenbaum.se\u003e wrote:\n\n\u003e * In the specification, you refer to \"t_start\". I guess you mean\n\u003e \"time_start\"?\n\u003e\n\nThanks, I'll fix.\n\n\n\u003e * Miners can, especially when close to a block doubling or shortly\n\u003e after activation, to some extent manipulate max block size by\n\u003e manipulating the time stamp in the block header within valid limits.\n\u003e According to the pseudo code in the specification, the first and a\n\u003e handful of subsequent blocks after activation could actually have\n\u003e negative max block sizes due to this (depending on how you define the\n\u003e % operator of the pseudo code). I haven't checked the reference\n\u003e implementation, but I do think that the specification section should\n\u003e explicitly handle this.\n\u003e\n\nExcellent point. That could only happen if activation happened on 11 Jan\n2016; instead of complicating the code and spec with another condition, I\nthink it would be better to specify that the activation date is the later\nof the miner supermajority and 11 Jan, with the first big block two weeks\nlater.\n\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/adbbace4/attachment-0001.html\u003e"}