For software to validate correctly, it is not opt-in. The continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening. This situation applies to soft forks as well. After activation, it depends on people running it, most notably miners, otherwise the soft-fork is no longer enforced leading to a hard fork. Awareness alone does not ensure full validation capability is retained during a soft fork. Therefore, these differences seem insignificant enough to merit treating soft and hard forks equal in terms of the coordination features afforded through the versionbits. Witness the long preparation time ahead of SegWit deployment for wallet providers, miners etc. to coordinate to support it on their systems.Miners are irrelevant when it comes to hardforks as they cannot make the process any smoother. While BIP9 can indicate censorship in a soft fork, a hard fork always requires nodes to upgrade to the version increasing the degrees of freedom of the system. Signaling is less useful here since the change is not opt-in and will require coordination, and the continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening. Miners became a convenient way to activate soft-forks but they can't ameliorate a HF transition in the way they can censor transactions without permission.In a post on the bitcoin-dev mailing list, Luke Dashjr discussed how BIP 9 provides a mechanism for miners to coordinate softforks, but not hardforks. He explained that miners are essentially irrelevant to hardforks and cannot make the process any smoother. Tom Zander asked for an explanation of how miners are irrelevant to non-soft fork upgrades.BIP 9 is a mechanism for coordinating softforks among miners in order to make the upgrade process smoother. It does not apply to hardforks as miners are essentially irrelevant to them and cannot make the process any smoother. However, there is no fundamental distinction between the role of miners in softforks and hardforks when it comes to proper coordination with the rest of the users in the system. BIP 9 can be used as a coordination mechanism for both softforks and hardforks, allowing miners to use versionbits to make the process smoother. BIP 9 is a useful tool that allows a determination of how much hashing power supports a particular fork proposal. Both soft and hard forks without support from the majority of miners place themselves at high risk. In general, every soft fork can result in a counter hardfork by those who are not aligned with its objectives, just like every hardfork can result in a counter softfork for the same reason by those opposed to it. This balances out the advantages and disadvantages of each type of fork and effectively puts them on a similar footing. Developers must still choose whether their feature is best deployed by softfork or hardfork, but introducing more flexibility into the signaling framework of BIP9 means it will be more useful for further developments - including a potential hardfork. Softforks are not required to use BIP 9, and even if they do, they are not required to use the recommended thresholds.On April 3, 2017, a Bitcoin developer named Sancho Panza wrote about the shortcomings of BIP 9 in an email to the bitcoin-dev mailing list. He noted that BIP 9 limits itself to backward-compatible changes, making it unsuitable for hard forks. However, others have pointed out that this is not a limitation of BIP 9 but rather an inherent feature of soft forks. BIP 9 provides a mechanism for miners to coordinate soft forks, but it is not useful for deploying hard forks.Additionally, Panza argued that the fixed 95% threshold in BIP 9 is not flexible enough to account for a "spectrum of contentiousness" and can allow small minorities to veto proposed changes, leading to stagnation. However, it should be noted that soft forks are not required to use BIP 9, and even if they do, they are not obligated to adhere to the recommended thresholds.In summary, while Panza identified certain issues with BIP 9, some argue that these problems are not unique to BIP 9 and that the limitations of soft forks are simply inherent to the technology. Additionally, soft forks are not bound to use the recommended thresholds in BIP 9.The email thread discusses a proposal that aims to add flexibility to the tallying window size of BIP9. The author plans to post a link to a more refined proposal on GitHub once elaboration is complete. The discussion revolves around the idea of retaining full compatibility with BIP9 for a certain version bit if users wish to do so. One participant suggests that it might not be possible to have a state machine without the variables in the