Concept ACK. I've been talking about adding this to BIP99 since before scaling bitcoin Hong Kong, so it will be nice to have a BIP to just point to. Also I hadn't thought about concurrent deployment of 2 hardforks, nice.

On Feb 4, 2016 23:30, "Gavin Andresen via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:

> If the worry is full nodes that are not upgraded, then a block with a negative version number will, indeed, fork them off the the chain, in exactly the same way a block with new hard-forking consensus rules would. And with the same consequences (if there is any hashpower not paying attention, then a worthless minority chain might continue on with the old rules).

Additionally, a warning or special error could be thrown when a block is rejected due to the hardfork bit being activated.

> I think a much better idea than this proposed BIP would be a BIP that recommends that SPV clients to pay attention to block version numbers in the headers that they download, and warn if there is a soft OR hard fork that they don't know about.

Although I agree this PR should include such warning/error recommendations, SPV nodes can't tell whether a change is a hardfork or a softfork just by looking at the version bits, even in the case of uncontroversial hardforks deployed with bip9 as recommended by bip99. For controversial hardforks where bip9 should NOT be used for deployment, setting the hardfork bit is even more important.

> It is also a very good idea for SPV clients to pay attention to timestamps in the block headers that the receive, and to warn if blocks were generated either much slower or faster than statistically likely. Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in general.

This seems out of the scope of this PR.