The Road to Segwit Activation — UASF, Segwit2x and Segwit Signalling Explained
As opposed as the supporters of each solution may be, UASF BIP 148 and Segwit2x are essentially trying to do the same thing — activate Segwit BIP 141 on Bitcoin in accordance with its BIP 9 deployment.
Edit: I have subsequently published an article that also examines BIP 91 ‘Segsignal’ in this context and contains updates since bit 4 activated. It is perhaps more relevant than this one is now.
We’ll ignore the hard fork aspect of Segwit2x in this article and focus on the common goal of activating Segwit, taking a look at the two fundamentally similar approaches.
Let’s take a look at the activation method of Segwit itself first so we know exactly what they are hoping to achieve. Then we’ll take a look at how each activation solution goes about trying to hit that historically elusive target.
The shared goal — Segwit activation under BIP 9
Segwit (BIP 141) was deployed on October 27th 2016 with the release of Bitcoin Core version 0.13.1.
Segwit activation falls under the control of BIP 9 — a method of deploying multiple backwards compatible soft forks in parallel. Segwit’s BIP 9 deployment demands that 95% or more of blocks signal readiness for Segwit in a 2016 block period. In order to signal readiness for Segwit a miner sets bit 1 in the nVersion field of each block that they mine. These bit 1 ‘flags’ are what BIP 9 looks for when it calculates if 95% of the blocks in any given period are signalling readiness for Segwit.
Segwit has 26 of these periods during which it can move to the status of LOCKED_IN. Each period is defined as the 2016 block Bitcoin difficulty re-target period. We are currently in period 17 so neither solution we’ll look at has time on its side.
If LOCKED_IN is reached within that time frame then 2016 blocks later it will move to a status of ACTIVE and every Bitcoin Core node since 0.13.1 (and other witness capable clients) will see Segwit as activated.
If LOCKED_IN is not reached within that time frame it will move to a status of FAILED and it will then be eligible for redeployment.
There is nothing either solution can do to change this but there is a clever, and fairly coercive, way that they can try and ensure that there is a chain where 100% of the blocks signal for Segwit. This can be achieved even though miner support for Segwit has traditionally hovered around the 30% mark since its deployment.
UASF chain — 100% of blocks signalling for Segwit
The UASF (BIP 148) approach to achieving a chain where 100% of blocks signal support for Segwit is relatively simple.
On August 1st if Segwit itself is not already at the status of locked-in or activated, any node running the BIP 148 code will begin orphaning blocks that do not signal for Segwit using bit 1. The first block to not signal using bit 1 after the UASF code activates will cause a chain split. The non-UASF (or ‘legacy’) chain — with its mix of Segwit signalling and non-signalling blocks — will diverge from the UASF ‘Segwit signalling only’ chain.
It is because of the fact that nodes enforce the BIP 148 consensus rules that the solution is named ‘User Activated Soft Fork’. BIP 148 essentially puts the users of the Bitcoin network in control of its activation.
Miners running BIP 148 will add to the chain, extending it with blocks that all count towards BIP 9’s 95% activation threshold. It will have created a chain where 100% of the blocks signal readiness for Segwit.
Segwit2x chain — 100% blocks signalling for Segwit
Segwit2x attempts to create the very same type of chain as the UASF solution by doing the exact same thing — orphaning blocks that do not signal for Segwit using bit 1. The differences come about in the way the solution itself is activated.
In the UASF code a simple activation date is used. With Segwit2x a more complex method is used. Miners initially show their intent to support the solution (as is occurring at the present time) and then on July 21st they need to actually begin signalling for its activation.
Miners show their intent to support the ‘New York Agreement’ — the meeting where Segwit2x was conceived — by adding ‘NYA’ in the coinbase text of any blocks that they mine. This in itself does nothing to trigger anything within the Segwit2x code and is intended purely to be a publicly visible show of intended support.
The actual signalling for the activation of Segwit2x is due to begin on July 21st. In a similar fashion to the BIP 9 signalling for the activation of Segwit itself, a version bit is used to activate Segwit2x. In order for Segwit2x to activate it requires that at least 80% of blocks over a short 336 block period signal bit 4. There should be between 3 and 4 of these short periods between July 21st and August 1st. As the last period needs to be the LOCKED_IN period, there will be 2–3 actual periods where the 80% threshold can be met. The very existence of the UASF and its ‘set in stone’ activation date has undoubtedly been the driving force behind Segwit2x’s recent reduced confirmation window update.
It is worth noting that Segwit2x itself does not set bit 4 — this will be done independently by the miners as part of their mining workflow in line with existing guidelines. Coordinating the design, implementation, build, testing and deployment of Segwit2x in accordance with its aggressive project timeline is a sizeable task in itself and falls under the remit of the Segwit2x Working Group.
Once miners start running Segwit2x on the main chain it will look for the bit 4 ‘flag’, measure signalling against the 80% threshold and respond accordingly.
Once activated, the Segwit2x code will follow the exact same logic as the UASF code, in that it will start orphaning blocks that do not signal for Segwit using bit 1.
Because the signalling is done purely by miners in the blocks they create, users and nodes will simply follow the longest valid chain as normal. Users do not need to run the Segwit2x code.
Miners running Segwit2x will add to the chain, extending it with blocks that all count towards BIP 9’s 95% activation threshold. It will have created a chain where 100% of the blocks signal readiness for Segwit.
Comparing the two approaches
There are many scenarios that play out as we get closer to August 1st, and many more after that, but for the purpose of this article we have shown how both the UASF and Segwit2x solutions take largely the same approach to activating Segwit.
Once certain criteria are met, be that an activation date or a threshold being reached, they both enforce the orphaning of blocks that do not signal Segwit readiness by setting bit 1. This creates a chain with 100% bit 1 signalling, exceeding the goal of BIP 9’s 95% and activating Segwit.
Last week I published an article Explaining Segwit2x and BIP 148 (UASF) compatibility that explained how both solutions can be compatible. I’d suggest reading that for an in depth view but in essence — if Segwit2x is already orphaning non-Segwit signalling blocks by the time the UASF activates on August 1st there will be no chain split. Both solutions can happily follow the same ‘Segwit signalling only’ chain.
So will we soon see Segwit on Bitcoin?
It appears that the Bitcoin community has accepted the activation of Segwit as inevitable now. Whether it gets activated by Segwit2x or the UASF remains to be seen. Although Segwit2x has recently hit its ‘Alpha Milestone’ phase nothing is guaranteed and so UASF supporters remain cautious and will continue to support their solution until Segwit is active on Bitcoin.
It has also been suggested that it is possible that the signalling of Segwit via bit 1 alone may reach 95% as miners ready themselves for the avoidance of a chain split. However, as Segwit2x will also include code that enforces a hard fork to a larger block size (3 months after the activation of Segwit), it seems unlikely that Segwit prior to Segwit2x activation — and without the bundled hard fork contingency — will be permitted. Time will tell.
From the point of view of the thousands of existing Segwit ready nodes out there it won’t matter which solution’s supporters get to claim credit for its activation. They will simply see that Segwit BIP 141 has been activated by meeting the threshold set out by BIP 9. For the Bitcoin community itself, the debate and power plays that have plagued the activation of Segwit have already changed the landscape and will likely redefine how deployments are approached in the future.
I have subsequently published an article that also examines BIP 91 ‘Segsignal’ and contains updates since bit 4 activated.
