[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bitcoin-dev
Subject:    [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
From:       kekcoin () protonmail ! com (Kekcoin)
Date:       2017-04-18 12:37:29
Message-ID: 2-jKiz9wfXGoBTSXrvj0BeqBuylt_wvu-hmzeUi3yFH-4xK_8X9AGYzBqi7sbPDwIvDpR_CA4HUukFyZzKUL-Vm2ZeabHzZSSNPPZmLa_Ck= () protonmail ! com
[Download RAW message or body]

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/7599c704/attachment.html>



[prev in list] [next in list] [prev in thread] [next in thread]