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 toeventually activate segwit, or on what timeline, it would bebeneficial if validating nodes already capable of supporting segwitcould, without further upgrades, eventually participate to theirfullest capacity.

BIP9 assignments should reserve a backward compatibility bit which allyet-unknown segwit-compatible proposals may utilize. These futureproposals 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 afterthis BIP9 assignment can eventually understand if segwit is activatedby alternate means, even when the node is itself a legacy version.This is important because the realities of system administration onthe Bitcoin network are that upgrades occur slowly (which is inherentin the security choice of not presenting an auto-upgrade feature).Even though segwit in particular is backwards compatible with oldvalidating nodes, there are still distinct advantages to validatingand generating segregated witness transactions.

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

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 toeventually activate segwit, or on what timeline, it would bebeneficial if validating nodes already capable of supporting segwitcould, without further upgrades, eventually participate to theirfullest capacity.

BIP9 assignments should reserve a backward compatibility bit which allyet-unknown segwit-compatible proposals may utilize. These futureproposals 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 afterthis BIP9 assignment can eventually understand if segwit is activatedby alternate means, even when the node is itself a legacy version.This is important because the realities of system administration onthe Bitcoin network are that upgrades occur slowly (which is inherentin the security choice of not presenting an auto-upgrade feature).Even though segwit in particular is backwards compatible with oldvalidating nodes, there are still distinct advantages to validatingand generating segregated witness transactions.

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

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

Its goal is to be incredibly easy to test and deploy, right now, evenbefore 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 thepoint of a soft fork. UASFs simply need to have inevitability,which is provided by some nodes more than others. But for the nodeless instrumental in that inevitability, and more relaxed aboutscheduling upgrade work, being moved to a miner-protected consensusruleset is not as desirable a position as the opportunity toparticipate fully. As a courtesy, the plan for soft forks hasalways been to allow legacy nodes time to upgrade to fullparticipation. How much time should rollouts allow for thiscourtesy?

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

Code for deployment is included in the original email[1]. There'snothing missing from the logic shown. The whole intent of theproposal is that other deployment specifics are left to be definedby future proposals. In the same block that THRESHOLD_ACTIVE isreached for segwit, require Consensus::DEPLOYMENT_SEGWIT_ALT1 toalso reach THRESHOLD_ACTIVE, and the burden of the future proposalis fulfilled.

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

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

These seemingly small tensions complicate the solution, and push itout of developer's visions of what is feasible. It's not clear howsoon 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 howsoon it can happen.

We can remove the courtesy timeout problem, because the courtesybegins as soon as this proposal goes live. This simplifies debate onhow BIP149ish should deploy, and helps make reasonable a much quickersegwit activation should BIP141 fail.

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

These differences can help us aim for activating segwit on November16th, if BIP141 and BIP148 do not succeed earlier. Since BIP149 asoriginally conceived is slow as molasses, BIP149ish still needsdebate, BIP141 has steadfast enemies, and the community is slow toadapt to BIP148's complicated commitment requirements, it is prudentto take this intermediate step allowing quicker BIP149ish activation.