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.wui...@gmail.com>, Peter Todd < > p...@petertodd.org>, Greg Maxwell <g...@xiph.org>, Rusty Russell < > ru...@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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
