Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.

From: Btc Drak <btcdrak@gmail•com>
To: Rusty Russell <rusty@rustcorp•com.au>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail•com>,
	Greg Maxwell <greg@xiph•org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
Date: Wed, 16 Sep 2015 16:53:08 +0100	[thread overview]
Message-ID: <CADJgMztpJ2+GHMoHdP0Zt27BWBhVX1LaKO+CEP=q0rvoimgNSw@mail.gmail.com> (raw)
In-Reply-To: <87mvwqb132.fsf@rustcorp.com.au>

[-- Attachment #1: Type: text/plain, Size: 9000 bytes --]

Rusty,

I think you've covered all the issues discussed now. +1 for submitting to
BIPs repo to get an official number.

Are you planning to write the implementation?

On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Hi all,
>
> Those who've seen the original versionbits bip, this adds:
>    1) Percentage checking only on retarget period boundaries.
>    2) 1 retarget period between 95% and activation.
>    3) A stronger suggestion for timeout value selection.
>
> https://gist.github.com/rustyrussell/47eb08093373f71f87de
>
> And pasted below, de-formatted a little.
>
> Thanks,
> Rusty.
>
>   BIP: ??
>   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
>
> ==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.
>
> ==Motivation==
>
> 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.
>
> In addition, BIP 34 made the integer comparison (nVersion >= 2) a
> consensus rule after its 95% threshold was reached, removing 2^31 +2 values
> from the set of valid version numbers (all negative numbers, as nVersion is
> interpreted as a signed integer, as well as 0 and 1). This indicates
> another downside this approach: every upgrade permanently restricts the set
> of allowed nVersion field values. This approach was later reused in BIP 66,
> which further removed nVersion = 2 as valid option. As will be shown
> further, this is unnecessary.
>
> ==Specification==
>
> ===Mechanism===
>
> '''Bit flags'''
> We are permitting several independent soft forks to be deployed in
> parallel. For each, a bit B is chosen from the set {0,1,2,...,28}, which is
> not currently in use for any other ongoing soft fork. Miners signal intent
> to enforce the new rules associated with the proposed soft fork by setting
> bit 1<sup>B</sup> in nVersion to 1 in their blocks.
>
> '''High bits'''
> The highest 3 bits are set to 001, so the range of actually possible
> nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two
> future upgrades for different mechanisms (top bits 010 and 011), while
> complying to the constraints set by BIP34 and BIP66. Having more than 29
> available bits for parallel soft forks does not add anything anyway, as the
> (nVersion >= 3) requirement already makes that impossible.
>
> '''States'''
> With every softfork proposal we associate a state BState, which begins
> at ''defined'', and can be ''locked-in'', ''activated'',
> or ''failed''.  Transitions are considered after each
> retarget period.
>
> '''Soft Fork Support'''
> Software which supports the change should begin by setting B in all blocks
> mined until it is resolved.
>
>  if (BState == defined) {
>      SetBInBlock();
>  }
>
> '''Success: Lock-in Threshold'''
> If bit B is set in 1916 (1512 on testnet) or more of the 2016 blocks
> within a retarget period, it is considered ''locked-in''.  Miners should
> stop setting bit B.
>
>  if (NextBlockHeight % 2016 == 0) {
>     if (BState == defined && Previous2016BlocksCountB() >= 1916) {
>         BState = locked-in;
>         BActiveHeight = NextBlockHeight + 2016;
>     }
>  }
>
> '''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):
>
> Timeout Year    >= Seconds              Timeout Year    >= Seconds
> 2018            1514764800              2026            1767225600
> 2019            1546300800              2027            1798761600
> 2020            1577836800              2028            1830297600
> 2021            1609459200              2029            1861920000
> 2022            1640995200              2030            1893456000
> 2023            1672531200              2031            1924992000
> 2024            1704067200              2032            1956528000
> 2025            1735689600              2033            1988150400
>
> If the soft fork still not ''locked-in'' and the
> GetMedianTimePast() of a block following a retarget period is at or
> past this timeout, miners should cease setting this bit.
>
>  if (NextBlockHeight % 2016 == 0) {
>     if (BState == defined && GetMedianTimePast(nextblock) >= BFinalYear) {
>          BState = failed;
>     }
>  }
>
> After another retarget period (to allow detection of buggy miners),
> the bit may be reused.
>
> '''Warning system'''
> To support upgrade warnings, an extra "unknown upgrade" is tracked, using
> the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask
> will be non-zero whenever an unexpected bit is set in nVersion.  Whenever
> lock-in for the unknown upgrade is detected, the software should warn
> loudly about the upcoming soft fork.  It should warn even more loudly after
> the next retarget period.
>
> '''Forks'''
> It should be noted that the states are maintained along block chain
> branches, but may need recomputation when a reorganization happens.
>
> ===Support for future changes===
>
> The mechanism described above is very generic, and variations are possible
> for future soft forks. Here are some ideas that can be taken into account.
>
> '''Modified thresholds'''
> 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.
>
> '''Conflicting soft forks'''
> 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.
>
> '''Multi-stage soft forks'''
> Soft forks right now are typically treated as booleans: they go from an
> inactive to an active state in blocks. Perhaps at some point there is
> demand for a change that has a larger number of stages, with additional
> validation rules that get enabled one by one. The above mechanism can be
> adapted to support this, by interpreting a combination of bits as an
> integer, rather than as isolated bits. The warning system is compatible
> with this, as (nVersion & ~nExpectedVersion) will always be non-zero for
> increasing integers.
>
> == Rationale ==
>
> The failure timeout allows eventual reuse of bits even if a soft fork was
> never activated, so it's clear that the new use of the bit refers to a
> new BIP.  It's deliberately very course grained, to take into account
> reasonable development and deployment delays.  There are unlikely to be
> enough failed proposals to cause a bit shortage.
>
> The fallow period at the conclusion of a soft fork attempt allows some
> detection of buggy clients, and allows time for warnings and software
> upgrades for successful soft forks.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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