From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 752B81125 for ; Sun, 13 Sep 2015 18:57:29 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [103.22.144.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A30D618A for ; Sun, 13 Sep 2015 18:57:25 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 94B9C14076C; Mon, 14 Sep 2015 04:57:22 +1000 (AEST) From: Rusty Russell To: "Bitcoin Dev" User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 14 Sep 2015 04:26:01 +0930 Message-ID: <87mvwqb132.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Greg Maxwell , Pieter Wuille Subject: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2015 18:57:29 -0000 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 , Peter Todd , Greg Maxwell , Rusty Russell 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 1B 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.