On Friday, December 02, 2016 1:42:46 AM Jorge Timón via bitcoin-dev wrote:
> 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).
The difference is that right now, full nodes will happily follow a shorter
best-valid chain. This BIP would require them to hold back at the best-common
block between the best-valid chain and the invalid chain, forcing the user to
make a decision whether to reject the invalid chain permanently, or upgrade to
a version which can understand that chain as valid.
> 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).
Note: a malicious "SHF" is not a SHF at all, but an "evil fork".
> 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.
Nodes implementing this BIP will see it as a simple hardfork, but will
intentionally provide equivalent behaviour as older nodes which see it as a
soft-hardfork. In other words, all [compatible] hardforks will now behave like
a soft-hardfork without any special DMMS design.
If Bitcoin's eventual hardfork is far enough down the road (such that no nodes
remain from before this BIP are adopted), the SHF design could be safely done
away with entirely. And either way, it makes it easier to resist an un-
bitcoin-dev mailing list