Explaining Segwit2X and BIP 148 (UASF) compatibility

Explaining compatibility between the Segwit activation of the current Segwit2X code and BIP 148 UASF.

Please note — the Hard Fork element of Segwit2X is not compatible with UASF or with any Core release. This explains the activation of Segwit (BIP 141 via BIP 9 activation) primarily.

Background

Segwit (BIP 141) was released under the activation method of BIP 9.

Bip 9 requires that 95% of blocks be produced with a flag set to signal that miners are ready for it in order to activate BIP 141. Currently about 30% of blocks mined are signalling for Segwit like this.

Bitcoin Core nodes v0.13.1 or later are Segwit-ready and are waiting for BIP 9 to trigger and activate it. So the majority of Bitcoin nodes are now ready and waiting but the miners are not signalling in great enough numbers to actually activate it.

If 95% of the blocks produced signalled Sewgit before the end of its activation period (November 16th 2017) it would activate on all Segwit ready nodes after a short lock in period. Bitcoin would have Segwit. As direct miner activation through BIP 9 signalling is not going to happen looking at the current state of play there are two other ways proposed to activate it…

Both still use BIP 9 (so that the existing nodes out there see it) but with a few changes to bring about how that 95% is achieved.

UASF (BIP 148)

As of August 1st (and if Segwit is not already either locked-in or activated) nodes that run BIP 148 will not accept any blocks that don’t signal Segwit. This will cause a chain split if there are still blocks being mined that do not signal Segwit.

Non-148 nodes will extend the chain that includes non-Segwit signalling blocks as well as those signalling for it. BIP 148 nodes will only extend the chain with blocks that signal Segwit. Worth noting that they will only accept blocks built on top of their chain and not the same Segwit signalling blocks the other chain accepts… but that discussion is beyond the scope of this article.

With every block on its chain signalling Segwit the BIP 148 (UASF) chain will have 100% of blocks signalling BIP 9 activation of Segwit — over the 95% needed by the BIP 9 rules and so Segwit activates on the BIP 148 chain if there is enough hash power behind it to reach the activation threshold before November 16th.

Segwit2X

This tries a similar trick but first relies on 80% of miners saying they are ready and support it.

Here another signalling bit is used first (bit 4) before the actual Segwit BIP 9 bit 1 comes into play. The Segwit2X code run by miners sets out that once 80% of blocks that they mine are signalling using bit 4 they (the 80+%) will then orphan any blocks that don’t signal Segwit on bit 1 under the BIP 9 rule.

The net result is that 100% of blocks they mine are then signalling Segwit on bit 1 and BIP 9’s 95% activation threshold is triggered. Because this activates Segwit under BIP 9 all existing Segwit ready nodes then get Segwit.

If Segwit is activated on the main chain like this then all existing Segwit ready nodes will see that Segwit has been enabled — not just the nodes running Segwit2X. You do not have to change your node from your Core or UASF node to benefit from this.

BIP 148 (UASF) and Segwit2X compatibility

When people talk about Segwit2X being BIP 148 (UASF) compatible it means that they expect Segwit2X to have already triggered the ‘everyone must mine Segwit signalling blocks’ rule so that either:

(1) Segwit is either locked-in or already active (and bip 148 won’t trigger the orphaning of non-Segwit signalling blocks at all) or

(2) Every block is already signalling Segwit and preparing for its lock in period to finish and make Segwit live — and so BIP 148 may well activate but because every block is already signalling Segwit the lack of non-Segwit-signalling blocks being mined does not lead to a chain split.

Point (1) is highly dependant on when miners start running Segwit2X on July 21st as stated here: https://segwit2x.github.io/… as is point (2) but it is less urgent.

Segwit2X Hard Fork

This is defined (here and here) as happening about 3 months after the activation of Segwit.

It will only be enforced by the nodes running Segwit2X. If the miners who have agreed to run Segwit2X keep running it that will include them… and anyone else who then makes the choice to follow the Hard Fork. If you do not change your node from Core or UASF you will not follow the Segwit2X activated Hard Fork.

Segwit2X doesn’t mean UASF is no longer needed

Segwit2X is yet to be run by any miners on the main network. They might not run it at all or might start running it too late to avoid a chain split. They might not signal in sufficient numbers to trigger the 80% Segwit2X bit 4 threshold. There are likely other scenarios.

UASF support is still needed to make sure that Segwit2X delivers what the UASF is focused upon. If you are a UASF supporter you should not stop supporting UASF until Segwit has been activated on Bitcoin.

Summary

• The UASF efforts must continue to make sure that Segwit2X sticks to its current aims. If it doesn’t then the mining of non-Segwit signalling blocks after August 1st will split the network.
• You don’t need to change your node (Core of UASF) to benefit from Segwit if Segwit2X activates it.
• Segwit2X will be run by miners once is has come out of the ‘Apha Milestone’ testing phase. It is planned to be ready to be run live on July 21st. You will only need to run a variant of it at a later date if you support a hard fork 3 months after Segwit has activated.