public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

             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 [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in 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.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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