Discussion within the Bitcoin community is starting to shift from the activation of Segwit to focusing on the potential likelihood of future hard forks.

There are two main hard fork proposals that attract attention—The New York Agreement’s Segwit2x and Bitmain’s own UAHF.

We’ll take a look at each in turn, examining the activation logic and the challenges each one has to overcome in order to meet their sponsor’s goals. When looking at each proposal we will work on the basis that the criteria needed to bring about each hard fork will play out in line with their initialisation logic. This will be done in order to keep the subject as simple as possible.

We won’t look at the activation of Segwit itself as I covered last week in ‘The Road to Segwit Activation — UASF, Segwit2x and Segwit Signalling Explained’. Neither will we look at the compatibility of the UASF and Segwit2x which has also been covered in “Explaining Segwit2X and BIP 148 (UASF) compatibility”. Knowledge of the subject matter within those articles is not necessary in order to follow along but they do provide some background to the triggers that will be used to initiate each hard fork.

The Segwit2x Hard Fork

Segwit2x was created as a way for the supporters of the ‘New York Agreement’ to realise their combined objectives of activating Segwit and then shortly afterwards bringing about a base block size increase by way of a hard fork. Segwit2x has a scheduled hard fork date set to occur about 90 days after Segwit activates on Bitcoin.

As it currently stands — any miners running the Segwit2x code 90 days after Segwit activates on the Bitcoin network can mine and accept blocks that have a base block size over 1 MB, thus breaking existing consensus rules and causing a hard fork of the protocol. The hard fork logic itself is inherited from BIP 102.

The logic that governs when the hard fork will actually occur is more specifically: 144 * 90 (which is 12,960) blocks after Segwit activation. The average number of blocks produced each day being 144 (1 every 10 minutes) and 90 being the number of days after Segwit activates that they have chosen to hard fork on.

It is worth noting that it doesn’t matter to the Segwit2x code how Segwit has been activated, it will start the 12,960 block countdown regardless. Changes to ensure that this logic is tied to the actual activation of Segwit2x itself have been submitted to the Segwit2x code repository but were rejected as they were deemed to be “outside the scope of Segwit2x group”.

Approximately 90 days after Segwit has activated a group of miners will agree to try and mine a specific block that is over 1 MB in size. They will have to make a deliberate effort to do this and if there are not enough pending transactions to make a block greater than 1 MB in size the miners will collude to manufacture enough to ensure that a block can be made of sufficient size to cause a hard fork. The lack of a sufficient quantity of transactions to make a block over 1 MB in size seems unlikely when looking at the size of current blocks but remember that the hard fork is set to come about 90 days after the activation of Segwit, which itself increases the capacity of blocks.

It would be ironic if transactions had to be manufactured by miners in order to push the block size over 1 MB and bring about a hard fork after Segwit activates on the Bitcoin network. The justification for the hard fork itself would be further questioned.

The logic within the Segwit2x code will look for the presence of that specific ‘bigger than 1 MB’ block in order to validate and protect the chain from being wiped out in the future. If the block 12,960 blocks after Segwit activates does not have a base block size greater than 1 MB in size the Segwit2x code rejects it as an invalid block. In this sense the block can be referred to as a ‘magic block’ as it is bestowed special meaning by the code, much like a ‘magic number’ is in programming.

Segwit2x code to reject the block 12,960 after Segwit activates if it is less than or equal to the legacy (1 MB) block size

This ‘magic block’ check is needed because although the mining of a block that is greater than 1 MB in size will create a hard forked chain, nodes that follow that chain’s consensus rules will still sees blocks under 1 MB in size as valid. If at some point the legacy (1 MB max base block size) chain were extended to be the more worked-on chain* the nodes that initially accepted the hard forked chain would re-organise their history of the blockchain to respect the greater worked on chain. If this happened then the hard fork chain would be wiped out by the legacy chain. The check for the magic blocks presence prevents this. No ‘replay protection’ has yet been added to the Segwit2x code to prevent the possibility of transactions appearing on both chains. * Sometimes ‘longest’ is used to refer to the most worked on chain.

In order for any hard fork to be considered ‘activated’ it must be accepted as valid by nodes on the Bitcoin network. Without this validation a hard fork chain is effectively a privately mined chain which miners alone accept as valid.

Unless every block created thereafter follows the Segwit2x consensus rules the creation of the ‘magic’ block will bring about the existence of two incompatible chains. Nodes that do not alter their consensus rules to allow for the Segwit2x hard fork will remain on the legacy Bitcoin chain — which by then will have Segwit.

The task of first persuading every exchange, wallet provider and private node to update to Segwit2x compatibility and then ensuring this happens within 90 days is a huge and surely insurmountable challenge for advocates of Segwit2x. A chain split between the two incompatible versions of the protocol is inevitable.

The Segwit2x hard fork timeline

Bitmain’s UAHF

On June 14th the mining company Bitmain announced in a blog post what that they refer to as a “contingency plan against BIP 148 (UASF)”. It involves hard forking the Bitcoin protocol to create a ‘big block’ chain that is unaffected by wipe out risk from the UASF chain.

If by August 1st Segwit2x has not already activated and miners are still mining blocks that do not signal for the activation of Segwit then UASF nodes will begin orphaning such blocks and a chain split will occur.

Despite Bitmain outlining many times in their post why they believe the UASF will be unsuccessful they also go on to state that “the chain reorg risk is more significant than imaged”. As such they have declared that 12 hours and 20 minutes after the UASF supporting nodes activate they will force a hard fork of the chain. They then intend to privately mine on this chain (using an unspecified percentage of their hash power) until the UASF chain “gains significant support from the mining industry”. If that is the case then Bitmain intend to “ignore short-term economic incentives” and publicly release their hard fork chain onto the network whilst continuing to mine upon it.

To clarify —one of the conditions under which Bitmain’s privately mined hard fork chain will be made public is if the UASF chain *has* significant support from other miners.

The privately mined chain will initially allow blocks of up to 8 MB in size, although they claim this will be self-limited to 2 MB upon activation. The road map for the UAHF targets a block size of 16 MB two years after activation. As with Segwit2x, the code that handles this fork will also include a ‘magic block’ check that ensures there is no wipe-out risk should the UASF chain extend beyond the hard fork chain.

The UAHF proposal has a reference client that they have made available for exchange and wallet operators so that they may implement the code should they wish to follow the Bitmain chain once it is released to the network.

As with Segwit2x — in order for any hard fork to be activated it must be accepted as valid by nodes on the Bitcoin network.

Having one company with control over the production of the majority of mining hardware, hash rate and also the client needed to transact on a chain that was initially privately mined has sparked strong reactions among many community members.

Of course all this is irrelevant if Segwit2x is already orphaning blocks that do not signal Segwit by August 1st when UASF activates.

If Bitmain and other miners sincerely plan to activate Segwit via Segwit2x signalling — as they have implied with their support of the ‘New York Agreement’ — the need for their aggressive ‘UASF contingency plan’ seems obsolete upon inception. Its publication has therefore drawn many to assume that Bitmain may not follow through with Segwit2x as stated.

The UAHF timeline

The Role of Nodes in a Hard Fork

For either hard fork to succeed the proposing sponsors must convince those who currently run Core compatible nodes to abandon their existing client and to switch to running a consensus breaking version that they have developed outside of the Core repository and without the support of the majority of currently active Core contributors.

If they fail to do this they will create a chain that does not have the support and backing of the majority of Bitcoin’s users. It is those users that bring value to Bitcoin as they exchange their FIAT currency for Bitcoin and pay for their transactions to be processed and time-stamped by miners by including fees.

If the legacy chain continues to be mined upon by some miners and is supported by the majority of nodes and users then either hard fork attempt will simply result in the creation of an ‘alt-coin’.

The supporters of the hard fork may well try and refer to their alt-coin as Bitcoin but ultimately it will be the community that judge, label and place a value on it by their decision to follow the hard fork or not.