Although I agree that how safe a pre-hardfork upgrade period is depends on the complexity of the changes (we should assume everyone may need time to reimplementat it themselves in their own implementations, not just upgrade bitcoin core) and bip102 is indeed a very simple hardfork, I think less than 6 months for a hardfork is starting to push it too much. For a more complex hardfork (say, a SW hardfork or a collection of many little fixes) I believe 1 year or more would make more sense.
BIP99 recommends a time threshold (height or median time) + 95% miner upgrade confirmation with BIP9 (version bits). So how about the following plan? 1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade confirmation 2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9. Note that both "when it's ready" depend on something we are not paying a lot of attention to: bip9's implementation (just like bip113, bip68-112, bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork, etc). Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already equivalent to the 2-4-8 "compromise" proposal (which by the way I never liked, because I don't think anybody should be in a position to "compromise" anything and because I don't see how "let's avoid an unavoidable economic change for a little bit longer" arguments can reasoably claim that "we need to kick the can down the road exactly 3 more times" or whatever is the reasoning behind it).
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
