From: Kekcoin <kekcoin@protonmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
Date: Tue, 18 Apr 2017 08:37:29 -0400 [thread overview]
Message-ID: <2-jKiz9wfXGoBTSXrvj0BeqBuylt_wvu-hmzeUi3yFH-4xK_8X9AGYzBqi7sbPDwIvDpR_CA4HUukFyZzKUL-Vm2ZeabHzZSSNPPZmLa_Ck=@protonmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 1220 bytes --]
next reply other threads:[~2017-04-18 12:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-18 12:37 Kekcoin [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-04-06 21:25 shaolinfry
2017-04-07 8:38 ` praxeology_guy
2017-04-07 13:55 ` Ryan Grant
2017-04-07 17:56 ` praxeology_guy
2017-04-08 4:48 ` Ryan Grant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='2-jKiz9wfXGoBTSXrvj0BeqBuylt_wvu-hmzeUi3yFH-4xK_8X9AGYzBqi7sbPDwIvDpR_CA4HUukFyZzKUL-Vm2ZeabHzZSSNPPZmLa_Ck=@protonmail.com' \
--to=kekcoin@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox