versionbits: the BIP. #207

rustyrussell commented at 12:37 AM on September 24, 2015: contributor

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010998.html

Signed-off-by: Rusty Russell rusty@rustcorp.com.au

versionbits: the BIP.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

be86444b88

btcdrak commented at 9:30 AM on September 24, 2015: contributor

Needs copyright attribution.

Formatting feedback & copyright from btcdrak.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

fecfe5bfac

in bip-wuille-todd-maxwell-russell.mediawiki:None in be86444b88 outdated

 118 | +
 119 | +If the soft fork still not ''locked-in'' and the
 120 | +GetMedianTimePast() of a block following a retarget period is at or
 121 | +past this timeout, miners should cease setting this bit.
 122 | +
 123 | + <nowiki>if (NextBlockHeight % 2016 == 0) {

btcdrak commented at 9:47 AM on September 24, 2015:

You dont need this tag if you indent the code block 4 spaces in

gmaxwell commented at 1:52 AM on September 25, 2015: contributor

BIP 009

Bip number assigned: 9.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

f278c02cbc

More btcdrak feedback.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

602e721256

in bip-0009.mediawiki:None in f278c02cbc outdated

   7 | +  Created: 2015-10-04
   8 | +</pre>
   9 | +
  10 | +==Abstract==
  11 | +
  12 | +This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.

btcdrak commented at 9:11 AM on September 25, 2015:

allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel

allowing multiple backward-compatible changes (further called called "soft forks") to be deployed in parallel

s/being/to be/

rustyrussell commented at 6:34 AM on September 27, 2015:

฿tcDrak notifications@github.com writes:

@@ -0,0 +1,167 @@ +<pre>

BIP: 9

Title: Version bits with timeout and delay

Author: Pieter Wuille pieter.wuille@gmail.com, Peter Todd pete@petertodd.org, Greg Maxwell greg@xiph.org, Rusty Russell rusty@rustcorp.com.au

Status: Draft

Type: Informational Track

Created: 2015-10-04 +</pre> + +==Abstract== + +This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.

allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel

allowing multiple backward-compatible changes (further called called "soft forks") to be deployed in parallel

s/being/to be/

And s/called called/called/ :)

Thanks, Rusty.

in bip-0009.mediawiki:None in f278c02cbc outdated

  11 | +
  12 | +This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called called "soft forks") being deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.
  13 | +
  14 | +==Motivation==
  15 | +
  16 | +BIP 34 introduced a mechanism for doing soft-forking changes without predefined flag timestamp (or flag block height), instead relying on measuring miner support indicated by a higher version number in block headers. As it relies on comparing version numbers as integers however, it only supports one single change being rolled out at once, requiring coordination between proposals, and does not allow for permanent rejection: as long as one soft fork is not fully rolled out, no future one can be scheduled.

btcdrak commented at 9:16 AM on September 25, 2015:

s/without predefined flag/without a predefined flag/

rustyrussell commented at 6:34 AM on September 27, 2015:

฿tcDrak notifications@github.com writes:

s/without predefined flag/without a predefined flag/

Applied, with the others. Thanks.

Cheers, Rusty.

in bip-0009.mediawiki:None in f278c02cbc outdated

 143 | +
 144 | +'''Modified thresholds'''
 145 | +The 95% threshold (based on in BIP 34) does not have to be maintained for eternity, but changes should take the effect on the warning system into account. In particular, having a lock-in threshold that is incompatible with the one used for the warning system may have long-term effects, as the warning system cannot rely on a permanently detectable condition anymore.
 146 | +
 147 | +'''Conflicting soft forks'''
 148 | +At some point, two mutually exclusive soft forks may be proposed. The naive way to deal with this is to never create software that implements both, but that is a making a bet that at least one side is guaranteed to lose. Better would be to encode "soft fork X cannot be locked-in" as consensus rule for the conflicting soft fork - allowing software that supports both, but can never trigger conflicting changes.

btcdrak commented at 9:20 AM on September 25, 2015:

s/is a making a bet/is making a bet/

in bip-0009.mediawiki:None in f278c02cbc outdated

  66 | +     }
  67 | +
  68 | +'''Failure: Timeout'''
  69 | +A soft fork proposal should include a ''timeout''.  This is measured
  70 | +as the beginning of a calendar year as per this table (suggested
  71 | +three years from drafting the soft fork proposal):

btcdrak commented at 9:23 AM on September 25, 2015:

three years seems a bit long. 2 maybe, but not more imo. Were there any calculations or data this was based on?

rustyrussell commented at 6:34 AM on September 27, 2015:

฿tcDrak notifications@github.com writes:

+'''Success: Activation Delay''' +The consensus rules related to ''locked-in'' soft fork will be enforced in +the second retarget period; ie. there is a one retarget period in +which the remaining 5% can upgrade. At the that activation block and +after, the bit B may be reused for a different soft fork. +
if (BState == locked-in && NextBlockHeight == BActiveHeight) {
   BState = activated;
   ApplyRulesForBFromNextBlock();
   /\* B can be reused, immediately */
}
+'''Failure: Timeout''' +A soft fork proposal should include a ''timeout''. This is measured +as the beginning of a calendar year as per this table (suggested +three years from drafting the soft fork proposal):
three years seems a bit long. 2 maybe, but not more imo.

The proposal is to add 3 to the calendar year, thus 2-3 years. I clarified this as:

A soft fork proposal should include a ''timeout''. This is measured as the beginning of a calendar year as per this table (suggest adding three to the current calendar year when drafting the soft fork proposal):

It can take a year to actually get from first drafting of a BIP to actual deployed code. For example, the versionbits bip is 9 months old already, and still doesn't have code.

Looking at BIP66, the code was released 16 February. It was activated on 4 July, about 5 months later.

Cheers, Rusty.

luke-jr referenced this in commit 0299e466e3 on Sep 27, 2015

luke-jr merged this on Sep 27, 2015

luke-jr closed this on Sep 27, 2015