All roads lead to Segwit

There are currently three proposals for activating Segwit on Bitcoin — Segwit2x, BIP 91 "Segsignal," and BIP 148 "UASF." The first two are intended only for use by miners and the third is primarily being run by users.

We’ll take a look at each one in turn and show they all use a very similar approach to achieving their shared goal. We’ll also look at the differences between them and see what effects they can have on one another.

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 solution goes about trying to hit the historically elusive target of activating Segwit on Bitcoin.

Activating Segwit

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 nVersionfield 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 or not.

Segwit’s BIP 9 deployment consists of 26 periods of 2016 blocks. These periods are aligned with Bitcoin’s difficulty re-targeting periods. As blocks are produced on average at the rate of 1 every 10 minutes the periods should each be around 2 weeks long. We are currently in period 19.

Regardless of how many blocks signal for Segwit activation during the period that we are currently in there are not enough blocks left to reach 95% signaling. The next possible period for it to reach 95% is period 20 — which spans from block 477792 to block 479808.

If signaling reaches 95% in period 20 Segwit will move to the LOCKED_IN status at the start of period 21. From this point on — and as we move through the 2016 block ‘locked in’ period — the activation of Segwit on the Bitcoin network would be inevitable.

There is nothing Segwit2x, Segsignal or UASF can do to change the rules of Segwit’s BIP 9 deployment 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.

The BIP 148 UASF approach

The UASF (BIP 148) approach to achieving a chain where 100% of blocks signal support for Segwit is relatively straight forward.

On August 1st and 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 chain — with its mix of Segwit signaling and non-signaling blocks — will diverge from the UASF’s ‘Segwit signaling only’ chain.

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.

It is because of the fact that non-mining nodes largely 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 activation.

As things currently stand UASF nodes will activate on August 1st and there will not be a chain split. The UASF nodes will start enforcing their ‘all blocks must signal Segwit’ rule. As the existing main chain is currently conforming to this rule UASF nodes will follow it without incident.

Should the signaling we are currently seeing stop for whatever reason the risk of a chain split on August 1st becomes a possibility again.

The Segwit2x approach

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 that Segwit2x is activated. In the UASF code a simple activation date is used. With Segwit2x a more complex method is used.

In order to activate, Segwit2x relied on miner signaling in a similar fashion to the BIP 9 signaling for the activation of Segwit itself.

Segwit2x itself is already active on the Bitcoin network and is being run exclusively by miners. There is no need, and no point, in users running it.

Segwit2x required that at least 80% of blocks over a short 336 block period signalled bit 4. Signaling was due to start on July 21st as per the Segwit2x Working Group’s charter. Miners actually began signaling on bit 4 several days in advance of this date — likely compelled to do so by the existence of the UASF’s ‘set in stone’ August 1st activation date and the desire to avoid a potential chain split. From the point at which bit 4 lock in was reached, miners have been able to stop signalling bit 4. Everything is now Dependant on the production of blocks that signal for the activation of Segwit on bit 1. Bit 4 itself is now redundant.

Today — and as of block number 477120 — any miner running Segwit2x will signal bit 1 and reject blocks that do not signal using that bit. Other miners that are signalling bit 1 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 isn’t just trying to activate Segwit though.

Segwit2x is the name given to the proposal created to accomplish the goals of the New York Agreement. The code itself is held in the ‘btc1’ repository and had been developed under the stewardship of Jeff Garzik.

The Segwit2x project has two stated goals:

1. To activate Segwit (which we have covered above).
2. To bring about a hard fork that increases the base block size to 2 MB three months after the activation of Segwit.

In order to meet these objectives two existing BIPs have been applied on top of the Core Reference client base code of btc1 — James Hilliard’s BIP 91 ‘Segsignal’ and Jeff Garzik’s own BIP 102 hard fork proposal. The first of these is responsible for the activation of Segwit and the latter controls the mechanisms of the planned hard fork. Neither of these BIPs are present in any release of the Core reference client.

It is relatively trivial to apply the BIP 91 Segsignal code to an existing node in order to achieve the first goal without requiring code to follow through and action the second. It is this approach of patching a Core node with BIP 91 in order to activate Segwit that we will look at next.

The BIP 91 Segsignal approach

The path towards Segwit activation BIP 91 had not being widely spoken about within the general community until recently. Since bit 4 signaling locked in and then activated, BIP 91 has been referenced as much as, if not more than, Segwit2x itself.

So why is BIP 91 itself the focus of so much attention? Whilst it makes good political sense for those who oppose Segwit2x’s proposed hard fork to talk of BIP 91 in isolation, there are some sound reasons as to why breaking Segwit2x down into the two stages of its constituent parts makes sense.

As we have seen — the Segsignal code has itself been implemented within Segwit2x in order to achieve a chain with 100% of blocks signaling for Segwit. It should therefore come as no surprise to learn that when it comes to Segwit activation Segwit2x and Segsignal are indistinguishable from each other.

The bit 4 signalling we have seen has led to the orphaning of blocks by potentially two different proposals — Segwit2x and BIP 91 Segsignal.

There is no publicly verifiable way to tell if any given miner is running the full ‘Segwit + hard fork’ Segwit2x proposal or just BIP 91 Segsignal.

Herein lies a problem for the signatories of the New York Agreement.

False signalling for the Segwit2x Hard Fork?

Whether a miner runs either Segwit2x or Segsignal isn’t that important when it comes down to the activation of Segwit (as they both do the same thing) but it has wider implications when you consider support for the proposed Segwit2x hard fork.

BIP 91 does nothing to enforce a hard fork — that part of Segwit2x is handled by its BIP 102 implementation, which currently emits no publicly detectable deployment data and so its support is impossible to measure.

The activation of Segwit looks like a safe bet at this current point in time, whereas the potentially false signalling by some miners for Segwit2x and their implied support for the hard fork element (by using bit 4 and Segsignal) throws doubt upon the commitment of some miners to actually follow through with the hard fork.

Obviously this is more of a concern to those supporting Segwit2x for its hard fork feature than to those preferring Segwit activation alone.

Whats next?

If miners stick to the New York Agreement it is likely that we will see Segwit activating in accordance with the original BIP 9 deployment criteria towards the end of August… albeit in a very round about manner.

This isn’t the way every subsequent soft fork will work. The activation of Segwit has become a tale of politics and complicated signalling processes over what should have been a simple method of activation.

There is little doubt that future soft forks will use a different deployment method than BIP 9.

We can be sure that this will not be the last battle that is fought over protocol changes to Bitcoin.

In many ways resistance to change is one of Bitcoin’s strongest features and the debates surrounding the activation of Segwit are testament to its resilience to base layer changes.

With Segwit comes a fix to the transaction malleability bug and with that the enabling of ‘second layer’ solutions like the much talked-about Lightning Network.

These layer two solutions open the path for ‘off chain’ scaling and features that all build on top of a stable base protocol layer.

The proposed Segwit2x hard fork three months after Segwit activates is already a matter of some contention and it remains to be seen if the miners that support it follow through with it.

The hard fork’s close proximity to the activation of Segwit will not provide much time to observe the effects of Segwit’s own capacity increase before the proposed second capacity increase is scheduled to be introduced to the network.

Time will tell but the task of convincing the majority of the community to update their nodes to a non-Core implementation within three months of Segwit in order to follow a hard fork that may not even be required is significant.