> After some thought I managed to simplify the original uaversionbits proposal introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment by the timeout. This seems to be the simplest form combining optional flag day activation with BIP9. This brings the best of both worlds allowing user activated soft forks that can be activated early by the hash power.

After mulling over this proposal I think it is quite elegant; however there is one big "regression" in functionality in regards to BIP9 which it extends upon; a lack of back-out procedure. That is to say, if a protocol change is deployed using this BIP9-with-lock-in-on-timeout method, it is no longer possible to abstain from activating it if it is shown to contain a critical flaw.

I suggest that a second version bit can be used as an abandonment vote; with sufficient hashpower (50% might be enough since it is no longer about safe coordination of protocol change deployment) the proposed protocol change is abandoned. This changes the dynamic from BIP9's "opt-in" to an "opt-out" system, still governed by hashpower, but far less susceptible to minority miner veto.