> 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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
