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-
consented-to hardfork.

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to