public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2015-09-16 15:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-13 18:56 [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay Rusty Russell
2015-09-16 15:53 ` Btc Drak [this message]
2015-09-16 17:53 ` Tier Nolan
2015-09-16 20:19   ` Rusty Russell
2015-09-16 20:27     ` Jorge Timón
2015-09-16 20:32       ` Tier Nolan
2015-09-16 20:38         ` Jorge Timón
2015-09-16 20:48           ` Tier Nolan
2015-09-16 20:54             ` Jorge Timón
2015-09-16 20:57               ` Tier Nolan
2015-09-16 21:03                 ` Jorge Timón
2015-09-16 22:52                   ` Eric Lombrozo
2015-09-17 10:38                     ` Tier Nolan
2015-09-17 13:59                       ` Jorge Timón
2015-09-17 21:57                       ` Rusty Russell
2015-09-17 22:00           ` Rusty Russell
2015-09-19  5:04             ` Jorge Timón
2015-09-20  3:56               ` Rusty Russell
2015-09-21  8:24                 ` Jorge Timón
2015-09-21 10:34                   ` Rusty Russell
2015-09-16 20:30     ` Tier Nolan
2015-09-18  1:19       ` Rusty Russell
2015-09-23 18:33 ` Tom Harding
2015-09-23 19:01   ` Gavin Andresen
2015-09-30  2:05   ` Rusty Russell
2015-09-30 23:41     ` Tom Harding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADJgMztpJ2+GHMoHdP0Zt27BWBhVX1LaKO+CEP=q0rvoimgNSw@mail.gmail.com' \
    --to=btcdrak@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=greg@xiph.org \
    --cc=pieter.wuille@gmail.com \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox