extended BIP9 activation of segwit, for legacy nodes

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);
  }

You might be interested in my bip-uaversionbits proposal https://github.com/shaolinfry/bips/blob/bip-uavb/bip-uaversionbits.mediawiki

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);
}

This[1] idea from April would assist in a BIP149-like segwit activation on November 16th.

Its goal is to be incredibly easy to test and deploy, right now, even before a decision on revisions to BIP149 is made, and well before such "BIP149ish" testing is itself complete.

UASFs don't need time for most legacy nodes to upgrade - that's the point of a soft fork. UASFs simply need to have inevitability, which is provided by some nodes more than others. But for the node less instrumental in that inevitability, and more relaxed about scheduling upgrade work, being moved to a miner-protected consensus ruleset is not as desirable a position as the opportunity to participate fully. As a courtesy, the plan for soft forks has always been to allow legacy nodes time to upgrade to full participation. How much time should rollouts allow for this courtesy?

Extended BIP9 activation of segwit (for legacy nodes) separates concerns between intending to activate segwit and its method of deployment, allowing "semi-legacy" nodes that have upgraded to include this proposal to participate immediately in a successful segwit activation, without needing any courtesy time to upgrade to the particular deployment logic.

Code for deployment is included in the original email[1]. There's nothing missing from the logic shown. The whole intent of the proposal is that other deployment specifics are left to be defined by future proposals. In the same block that THRESHOLD_ACTIVE is reached for segwit, require Consensus::DEPLOYMENT_SEGWIT_ALT1 to also reach THRESHOLD_ACTIVE, and the burden of the future proposal is fulfilled.

If the idea proves broken or of no benefit, when actually implementing and testing future deployments, then we can avoid using DEPLOYMENT_SEGWIT_ALT1 until it expires, and zero nodes get hurt.

Let's look at how this affects options for how to deploy segwit...

/ BIP149ish UASF, without this proposal /

roadmap:
  - BIP149ish debated (handles BIP141 success, unlike BIP149)
  - BIP149ish tested
  - BIP149ish courtesy timeout debated
  - BIP148    fails
  - BIP149ish released
  - BIP141    fails
  - BIP149ish courtesy timeout expires
  - BIP149ish activates
  - segwit activates
  - legacy nodes must upgrade before recognizing BIP149 activation

If we try to restrict ourselves to only the original service bit, we see a tension between activating soon and leaving legacy nodes on a miner-protected consensus. We also see a tension between *planning* how long it will take to debate and test UASF logic, and setting expectations for when a reasonable activation date is.

These seemingly small tensions complicate the solution, and push it out of developer's visions of what is feasible. It's not clear how soon it can happen, so it doesn't get started in an urgent manner. It doesn't get started in an urgent manner, so it's not clear how soon it can happen.

/ BIP149ish UASF, with this proposal /

roadmap:
  - this proposal debated
  - this proposal tested
  - this proposal released (courtesy begins)
  - BIP149ish     debated  (handles BIP141 success, unlike BIP149)
  - BIP149ish     tested
  - BIP148        fails
  - BIP149ish     released
  - BIP141        fails
  - BIP149ish     activates
  - segwit activates
  - semi-legacy nodes *immediately* use segwit, via this proposal

We can remove the courtesy timeout problem, because the courtesy begins as soon as this proposal goes live. This simplifies debate on how BIP149ish should deploy, and helps make reasonable a much quicker segwit activation should BIP141 fail.

With a clear route to quick activation for semi-legacy nodes, the UASF can be planned for activation in as short a window as the key nodes can upgrade. Not even all the key nodes need to upgrade: it's still a soft fork, and UASFs simply need to have inevitability.

These differences can help us aim for activating segwit on November 16th, if BIP141 and BIP148 do not succeed earlier. Since BIP149 as originally conceived is slow as molasses, BIP149ish still needs debate, BIP141 has steadfast enemies, and the community is slow to adapt to BIP148's complicated commitment requirements, it is prudent to take this intermediate step allowing quicker BIP149ish activation.

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014160.html