Without at least a majority hashrate validating blocks, it is possible just a single invalid block could split the chain such that the majority continue building a most-work on that invalid block.
This failure to validate a softfork is similar in some respects to a hardfork, but with one critical difference: the default behaviour of old nodes will be to follow the chain with the most-work that was valid under the pre-softfork rules. This actually *inverts* the benefit of the softfork over a hardfork, and makes a softfork deployed in such a manner de facto behave as if it had been a hardfork, IF someone ever mines a single malicious block. For this reason, I think a minority-hashrate softfork requires a much higher degree of social support than merely the widespread agreement typical of softforks. It might perhaps require less than the full ~100% consensus hardforks require, but it likely comes somewhat close. Once it gets over 50% hashrate enforcement, however, the situation improves a lot more: a malicious block may split obsolete miners off the valid chain, but it will eventually resolve on its own given enough time. Due to natural fluctuations in block finding, however, automatic measurement may need to look for >75%. So I would suggest that instead of a simple flag day activation, this proposal would be improved by changing the flag day to merely reduce the hashrate requirement from 95% to 75%. (In addition to the above concerns, if >50% of miners are hostile to the network, we likely have other problems.) Luke _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
