We can already warn users of a hardfork when a block is invalid (at least) because of the highest bit in nVersion (as you say, because it is forbidden since bip34 was deployed). It seems the softfork serves only to warn about soft-hardforks, assuming it chooses to use this mechanism (which a malicious soft hardfork may not do). In fact, you could reuse another of the prohibited bits to signal a soft-hardfork while distinguishing it from a regular hardfork. And this will also serve for old nodes that have not upgraded to the softfork. But, wait, if you signal a soft-hardfork with an invalid bit, it's not a soft-hardfork anymore, is it? It's simply a hardfork. Your softfork would result in soft hardforks being hardforks for nodes that upgraded to this softfork, but softforks for older nodes. Is this the intended behaviour? if so, why?
I would rather have a simpler BIP that doesn't require a softfork (whether it recommends soft-hardforks to use one of the currently invalid bits, but a different one than from hardforks or not, but I also don't see the reason why soft-hardforks should appear as invalid blocks for older nodes instead of using regular softfork warning [besides, in this case, after the "unkown softfork" warning you will get only empty blocks, which may make you suspicious]). _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev