consensus: adjust bip9 periods

[fdoving]

10x the default counting periods.
Previous period was 2016 blocks or about 1.4 day.
Proposed period is 20160 blocks or about 14 days.

• The LOCKED_IN period is extended from 1.4 to 14 days, during which non upgraded nodes will be warned of the upcoming fork.
• 10 times as expensive to potentially try to force activation with rented hashpower.
• Slower activation. Previous minimum activation time from counting starts, about 3 days, with this proposal about 30 days.

[fdoving]

I suggest to change the confirmation window, not only for P2SH assets, as an override, but as a feature for all changes to mainnet.

[hans-schmidt]

Approval is pending a realistic choice of nOverrideRuleChangeActivationThreshold

[TronBlack]

You can't change the defaults. They need to stay the same because otherwise as the code is syncing it will be expecting different times for all previous hardforks (DGW, etc). Just do the overrides. The code would work for anyone just upgrading, but break for new users that sync the chain from scratch.

[fdoving]

You can't change the defaults. They need to stay the same because otherwise as the code is syncing it will be expecting different times for all previous hardforks (DGW, etc). Just do the overrides. The code would work for anyone just upgrading, but break for new users that sync the chain from scratch.

Fixed.

[hans-schmidt]

Tron, thanks for the clear explanation. Last year we adopted a policy that PRs which touch consensus can't get PR approvals until after explicit testing including sync from zero (which showed that the P2SH code needed tweaking). I was unsure about changing the defaults but wasn't worried since the test would definitely catch such a problem before PR approval. This PR is a good reminder why we have that policy. Again, thanks for the assist. Your expertise is very much needed and appreciated.

I do want to get a dicussion going about nOverrideRuleChangeActivationThreshold, which is why I focused on that. Given the importance of P2SH, the difficulty identifying miners, and the long time constants we have chosen, I think we shouldn't set it too high. What are your thoughts?

[TronBlack]

Approved as modified to just the overrides.

It would make sense to run this change against the main chain before and after BIP9 activation.

A force of the BIP9 activation (in code) could be done, then a full chain sync. It should continue to run as long as no P2SH (or other BIP9 wrapped transactions are published).

I think it makes sense to have a longer activation threshold this time around. If we've agreed that all future ones should also be longer, then a comment around where the activation threshold override gets set should suffice, so that future threshold overrides are also set to 10x.