public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
@ 2017-04-18 12:37 Kekcoin
  0 siblings, 0 replies; 6+ messages in thread
From: Kekcoin @ 2017-04-18 12:37 UTC (permalink / raw)
  To: bitcoin-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread
* [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
@ 2017-04-06 21:25 shaolinfry
  2017-04-07  8:38 ` praxeology_guy
  0 siblings, 1 reply; 6+ messages in thread
From: shaolinfry @ 2017-04-06 21:25 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2801 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.

Specification: https://github.com/shaolinfry/bips/blob/bip-uavb/bip-uaversionbits.mediawiki
Previous discussion: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html

<pre>
BIP: ?
Title: Version bits extension with guaranteed lock-in
Author: Shaolin Fry <shaolinfry@protonmail.ch>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
Status: Draft
Type: Informational
Created: 2017-02-01
License: BSD-3-Clause
CC0-1.0
</pre>

==Abstract==

This document specifies an extension to BIP9 that introduces an additional activation parameter to guarantee activation of backward-compatible changes (further called "soft forks").

==Motivation==

BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate.

This specification provides a way to optionally guarantee lock-in at the end of the BIP9 timeout, and therefore activation.

==Specification==

This specification adds a new per-chain deployment parameter to the existing BIP9 specification as follows:

# The '''lockinontimeout''' boolean if set to true, will transition state to LOCKED_IN at timeout if not already ACTIVE.

===State transitions===

<img src="bip-uaversionbits/states.png" align="middle"></img>

The state transition workflow is exactly the same as in BIP9 with an additional rule: During the STARTED state if the '''lockinontimeout''' is set to true, the state will transition to LOCKED_IN when '''timeout''' is reached.

case STARTED:
// BIP9 specification follows
if (GetMedianTimePast(block.parent) >= timeout) {
return (fLockInOnTimeout == true) ? THRESHOLD_LOCKED_IN : THRESHOLD_FAILED
}
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
walk = walk.parent;
if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
count++;
}
}
if (count >= threshold) {
return LOCKED_IN;
}
return STARTED;

=== Reference implementation ===

https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits

==Deployments==

A living list of deployment proposals can be found [[bip-0009/assignments.mediawiki|here]].

==Copyright==

This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.

[-- Attachment #2: Type: text/html, Size: 8340 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-04-18 12:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-18 12:37 [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in Kekcoin
  -- 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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox