Why Any Contentious Change Will Become a Permanent Fork

Forks are all the rage these days and there’s been a lot of news recently about what companies, individuals and developers will do in the event of one. Though I believe forks in Bitcoin are neither likely nor good, I will map out in this article what is likely to happen.

On Temporary and Permanent Forks

The prevailing distinction we tend to make is between Hard Forks and Soft Forks. While a useful way to look at software upgrades, this distinction tends to obscure the more important distinction between Temporary Forks and Permanent Forks.

Temporary Forks are Forks which have a chance of resolving. We have Temporary Forks all the time in Bitcoin in the form of orphan blocks. These were the start of a Fork, but no one built blocks on top of it and they were orphaned away. Soft Forks can be Temporary because the rules are Tightened. That is, blocks in the Upgraded Branch of a Soft Fork are always valid in the Static Branch, but not vice-versa. Two chains that diverge after a Soft Fork have a chance of coming back to one chain again, provided the Upgraded Branch (the Tighter Branch) is longer. An example of a Soft Fork is Segwit.

Similarly, some Hard Forks can be Temporary because the rules are Loosened. That is, blocks in the Static Branch of a Hard Fork are always still valid in the Upgraded Branch, but not vice-versa. The chains that diverge after a Hard Fork have a chance of coming back to one chain again, provided the Static Branch (again, the Tighter Branch) is longer. An example of a Hard Fork that can be Temporary is BU, which I’ll call a Loosening Fork, to distinguish between this and a Permanent Fork.

A Permanent Fork is a Hard Fork where the Upgraded and Static Branches have no chance of being on one chain. This can be the result of a change like a different algorithm for Proof-of-Work.

On Contentious and Agreeable Changes

I will define Contentious Change here as a situation where there are two competing chains for more than 1 day. In a Tightening Fork, the Static Branch would have to be longer than the Upgraded Branch for more than 1 day. In a Loosening Fork, the Upgraded Branch would have to be longer than the Static Branch for more than 1 day.

An Agreeable Change, on the other hand, has the possibility of forking, but doesn’t because all parties that can split the network don’t. As a result, a single branch emerges in less than a day.

The Catalyzing Event

There are two possible changes that have the possibility of being Contentious Changes in Bitcoin today. The first is Bitcoin Unlimited activation. The second is Segwit via User-Activated Soft Fork (UASF for short). The catalyzing event for a fork with Bitcoin Unlimited would be the first block that is over 1MB. For Segwit UASF, the catalyzing event for a fork would be a bit more subtle since no fork will actually happen until a particular type of transaction is mined.

Specifically, the transaction would have to be valid under current rules, but invalid under Segwit. We call this transaction a Forking Transaction. Given that Segwit repurposes the ANYONECANPAY sighash type, this wouldn’t be a difficult transaction to create. However, the Forking Transaction is not a standard transaction and won’t be relayed by a typical node. So how would a Forking Transaction get into a block?

Many mining pools allow direct entry of valid transactions for inclusion into blocks. To prevent a fork, every mining pool would have to be hyper-vigilant about Forking Transactions and reject them pro-actively. On the other hand, a single mining pool can create a fork that may become a Contentious Change by including a forking transaction in a block. If at this point, the Looser Branch has more mining power, this would like be the start of a Contentious Change.

Good and Bad of Block Reorganization

When there is a Temporary Fork and a bunch of blocks are orphaned away, this is called a Block Reorganization. Block Reorganization is what allows Bitcoin to stay on a single branch.

Block Reorganization is perhaps one of the greatest properties of Bitcoin. We have an objective record of what transactions took place as the blockchain with the most Proof-of-Work constitutes the standard.

Unfortunately, this Block Reorganization property also constitutes a major risk for all involved in a Contentious Change. As the rest of this article will show, the possibility of a Block Reorganization and Replay Attacks is what will ultimately lead to a Permanent Fork.

Lack of Price Signals

There’s a lot of information that will matter during a Contentious Change, but perhaps the most important is the price of coins on each Branch. The price not only determines miner profitability, but more importantly, user demand. This is why exchanges are so important to the Bitcoin economy as they keep Bitcoin liquid.

Unfortunately, the price of coins on each Branch will be hard to determine in the aftermath of a fork. This is because exchanges will likely not allow trading of both coins until there’s some certainty that one Branch won’t disappear due to a Block Reorganization. That is, if blocks, and thus, transactions can be invalidated, it’s extremely risky for anyone, especially an exchange, to accept deposits from the Looser Branch.

Furthermore, even if a Block Reorganization seems very unlikely (say the Looser Branch has much more hashing power), there’s always the possibility of a Replay Attack. A Replay Attack is where a transaction on one Branch is included as valid in the other. This is due to the fact that the rules are tightened, and by definition, a more lenient application of the rules will also find some transactions valid. As shown here, this is a concern for most exchanges.

Price is pretty fundamental to any coin, including the resulting two coins of a fork, so there will be a large demand to trade these coins, yet exchanges won’t accept these coins without some guarantee that there won’t be a Block Reorganization and that Replay Attacks won’t be possible.

The Point of No Return

It is at this point that the Looser Branch, which has the Block Reorganization risk, will have to make a change in the form of a Permanent Fork. That is, some way of making blocks valid on the Looser Branch invalid on the other, Tighter Branch. There could be many technical mechanisms for this but the easiest one is a block marker in the software that specifies that a particular block number X has to have hash Y.

Preventing Replay Attacks necessarily means that transactions from one Branch won’t be accepted by the other. This means the Tighter Branch will now have transactions, and thus blocks, which the Looser Branch won’t accept, creating a Permanent Fork. In other words, any mechanism to prevent Replay Attacks requires a Permanent Fork.

Once we have a successful Permanent Fork, and assuming this is an Agreeable Change and there’s not a third coin created, exchanges can then accept deposits, users can transfer coins from both branches without any fear of Replay Attacks and price discovery can resume.

Notice that at this point, we’ve already passed the point of no return. There’s been a Permanent Fork and there’s no possibility that one Branch will be reorganized back to the other Branch. Each will now exist as long as someone is willing to mine it (and given that there will be some positive price for each coin, somebody will).

What’s more, we have to pass the point of no return with opaque price signals. Due to Block Reorganization and Replay Attack risk, the price discovery would be largely hidden before a Permanent Fork.

I will note here that BitFinex has enabled futures markets for a possible BU Hard Fork which will aid in price discovery. However, note that after a Fork, but before a Permanent Fork, exchanges won’t accept deposits due to the risk factors. This means that a large contingent of the community won’t be able to participate in these markets, rendering this an interesting, but by no means clear market signal.

Pre-knowledge

Of course, knowing that this is going to be a problem beforehand, there will also be moves prepared by both sides of a potential Contentious Change. If, for example, there’s a flag-day for a UASF Segwit (a Tightening Fork), there may very well be software developed ahead of time to protect against Block Reorganization and Replay Attacks (that is, a Permanent Fork) by its opponents.

On flag day, those opposing Segwit can then upgrade their software to avoid all the risks of a Block Reorganization and Replay Attacks. This has the effect of making a Tightening Fork into a Permanent Fork immediately.

Similarly, Bitcoin Unlimited may simply opt to make their Loosening Fork a Permanent Fork to avoid the Block Reorganization and Replay Attack risks.

What This Means

So what does this all mean?

First, the distinction between Tightening or Loosening Forks doesn’t matter that much compared to Contentious or Agreeable Changes. Contentious Changes will very likely end up as Permanent Forks no matter what the mechanism, whereas Agreeable Changes simply won’t fork at all.

Second, given that the endgame is most likely a Permanent Fork, we should not entertain Contentious Changes. A permanent split might eventually be unavoidable, but Contentious Changes and Bitcoin as we know it are incompatible. Market-based, permission-less alternatives should be embraced instead.

Third, no technical mechanism makes a Contentious Change “safer”. Bitcoin is governed by consensus and if there are enough opponents to a change, there’s always a way for the opponents to trigger a split and thus guarantee some form of mutually assured destruction.

Conclusion

I’ve previously stated that the consensus governance of Bitcoin is a feature, not a bug. My hope is that we start turning the conversation to more Agreeable Changes instead of the Contentious Changes.

The game theory implications of a Contentious Change mean that we’re going to be facing the consequences of not following the consensus model. In other words, subverting consensus will likely end with changes far bigger than we bargained for.