On Fri, Jan 29, 2016 at 5:39 PM, Gavin Andresen via bitcoin-dev <[email protected]> wrote: > On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev > <[email protected]> wrote: > It doesn't matter much where in the difficulty period the fork happens; if > it happens in the middle, the lower-power fork's difficulty will adjust a > little quicker.
The reason why BIP9 (versionbits) only checks for new activations during difficulty retargettings is a simple optimization to only check 1/2016 of the blocks. I suspect the check itself is not that costly for Bitcoin Core, which has all the block headers in memory anyway, but I don't think we should assume that will be the case for all implementations. <BIP99 aside comment> As an aside, BIP99 never recommends a 75% mining signaling activation threshold: it recommends 95% for uncontroversial rule changes and no miner signaling at all for controversial hardforks. I still have to update BIP99 with some later changes I commented at Scaling Bitcoin HK like signaling hardfork activation with the "negative int32_t bit" so that old clients are forced to upgrade/decide. We could start deploying better ways to inform users about a hardfork event, but of course those changes cannot be applied to older software that is already deployed (but hopefully they will still notice something is weird is happening if the longest chain that keeps growing is invalid because it contained a block with a negative version in it). But I'm yet to see a single hardfork proposal that follows BIP99's recommendations besides the hardfork proposed in BIP99 itself, which should consist on a manageable list of very simple to deploy fixes like the timewarp fix forward-ported from Freicoin 0.8 for the BIP. I haven't seen much interest in growing that little list of "a few fixes nobody disagrees are bugs or sub-optimal design decisions, plus the changes are easy to implement both separately and as a whole" either. I cannot say I have seen any opposition at all to BIP99 as a hardfork either, but I naively expected people would ask me to implement more things for BIP99 besides https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11 or even contribute the patches themselves. For all that, I don't consider BIP99 a priority to work on and I plan to complete it at some point later, unless there's a time limit for a BIP to be in the "draft" state or something. If someone else considers completing BIP99 a priority, I'm happy to review and integrate things, though. Thanks again to all the reviewers and contributors to the BIP at this time and I'm sorry that it has been stuck for some time. Maybe the classification/recommendations should have been a BIP without code and the hardfork proposal itself should have been another one and that would have been clearer. I just wanted to have some code on my first BIP (and as said the plan is still to put more code at some point). </BIP99 aside comment> _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
