MIME-Version: 1.0
Sender: rgrant@rgrant.org
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Fri, 14 Apr 2017 15:12:34 -0500
Message-ID: <CAMnpzfr5hLFqRm0_KWb6=N8YsD4dfQBtRBPFwfjz-EHA31d34A@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
Subject: [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes
Precedence: list

Segwit has proven more contentious to activate than anticipated
(although my read has long been that the technical consensus is clear,
despite noisy objections).  No matter which method is used to
eventually activate segwit, or on what timeline, it would be
beneficial if validating nodes already capable of supporting segwit
could, without further upgrades, eventually participate to their
fullest capacity.

BIP9 assignments should reserve a backward compatibility bit which all
yet-unknown segwit-compatible proposals may utilize.  These future
proposals must be consensus compatible with BIPs 141, 143, & 147,
except that they may use different deployment logic.

The motivation is so that any validating node software released after
this BIP9 assignment can eventually understand if segwit is activated
by alternate means, even when the node is itself a legacy version.
This is important because the realities of system administration on
the Bitcoin network are that upgrades occur slowly (which is inherent
in the security choice of not presenting an auto-upgrade feature).
Even though segwit in particular is backwards compatible with old
validating nodes, there are still distinct advantages to validating
and generating segregated witness transactions.

For example, future BIP9-compatible deployment attempts might
additionally include a date-dependent UASF fallback.  If, either
during or after activation, deployment rules also require signaling
for segwit using the backwards-compatible bit here proposed, then
(after 95% of recent blocks signal for the alternate segwit
deployment) more legacy nodes would understand and validate
transactions using segregated witnesses.

An expiration time of five years seems conservative:

  // Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147)
  consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].bit = 2;
  consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nStartTime
= 1510704000; // November 15th, 2017.
  consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nTimeout =
1668470400; // November 15th, 2022.

Segwit deployment logic would then look like:

  bool IsWitnessEnabled(const CBlockIndex* pindexPrev,
                        const Consensus::Params& params)
  {
      LOCK(cs_main);
      return    (VersionBitsState(pindexPrev,
                                  params,
                                  Consensus::DEPLOYMENT_SEGWIT,
                                  versionbitscache)
                 == THRESHOLD_ACTIVE)
             || (VersionBitsState(pindexPrev,
                                  params,
                                  Consensus::DEPLOYMENT_SEGWIT_ALT1,
                                  versionbitscache)
                 == THRESHOLD_ACTIVE);
  }