Recently, the idea of a user-activated soft fork (UASF) has gained some attention as a possible alternative to the current, miner-focused activation method for Segregated Witness (SegWit). Thus far, opinions on the original proposal from the pseudonymous shaolinfry are split, and official endorsements of the proposal from important players in the bitcoin ecosystem are sparse.
Some have pointed to a potential chain split caused by miners as a potential downfall of this proposal, while others still see it as preferable over a hard fork.
Let’s take a closer look at what a UASF could mean for Segregated Witness’s activation prospects, which currently has roughly 25 percent of miners signaling preparedness for it.
What is a User-Activated Soft Fork?
A UASF fork is a soft fork where activation is set by a flag day rather than signaling from miners on the network. If there is sufficient support from the economy for a particular soft-forking change to bitcoin, the change can be implemented by developers and supported by those operating bitcoin full nodes.
In the early days of bitcoin, creator Satoshi Nakamoto implemented multiple changes via these kinds of time-based soft forks with flag day activation.
One of the key components of UASFs is that they’re intended to be optional for miners and users. As long as a majority of miners decide to reject blocks that are invalid under the new rules, those who wish to use new features implemented via a soft fork can do so and those who do not wish to use those features can stick with the old version of the protocol.
Having said that, things can get a bit dangerous when miners are not interested in allowing users to opt into a new, soft-fork enabled feature set.
What are the Risks of a User-Activated Soft Fork?
The worst case scenario of a UASF is the same as the best case scenario for a hard fork. If a majority of miners decide they do not like the new features implemented via a UASF, they can essentially force a split of the bitcoin network into two chains. This is the same thing that happens by default when a hard fork is attempted.
For most people, the point of preferring a soft fork over a hard fork is to prevent these sorts of chain splits. While soft forks also have their potential downsides, such as security degradation for non-upgraded nodes, the fact that a chain split can be prevented with this upgrade mechanism is what makes it preferable over other options in the minds of the most active Bitcoin Core contributors.
So how could a chain split happen in the case of a user-activate soft fork?
As long as a majority of miners are playing nice, nothing should go wrong. Users will be able to opt into the new features and everyone will remain on the same chain. However, things can get problematic rather quickly if a single miner decides to mine a block that is valid under the old rules but invalid under the new rules. If a majority of miners have not adopted the soft fork or are not at least rejecting blocks that are invalid under the new rules, then a chain split could result from a single miner’s inclusion of a transaction invalid under the new rules in a block.
The point about miners having the option to simply reject blocks that are invalid under the new rules is key; they don’t have to actually adopt the rules of the soft fork for it to activate. In this way, miners are essentially just making sure the change is backwards compatible and helping to ensure there is not a chain split where non-upgraded users are left behind on the wrong chain.
In the chain split scenario, nodes that adopted the soft fork and nodes that did not adopt the soft fork would essentially find themselves on two different blockchains and currency networks.
Should Segregated Witness Be Implemented via a User-Activated Soft Fork?
It’s difficult to say whether a soft-forking or hard-forking change should be adopted by Bitcoin because it’s not easy to get useful data related to the level of support these sorts of changes actually have among speculators and users. As mentioned above, soft forks are generally better at preventing chain splits than hard forks because they’re backwards compatible, but things get trickier when miners are not on board with the requested change.
In this sense, it may be true that UASFs are more of a safer alternative to a hard fork than anything else. This doesn’t necessarily mean they’re safe – just safer than a hard fork (in terms of preventing a chain split).
If it’s clear that 95 percent or more of the network are in favor of a soft fork, then it may be a useful alternative to a hard fork. It would essentially be a way for users to force miners to implement the requested change while also avoiding a hard fork (and therefore a chain split).
The incentives of a UASF with proper support from the economy are such that the profit motive should incentivize miners to adopt the changes users would like to see on the network (or at least reject blocks that are invalid under the new rules). If the change has near universal support from the economy, then miners will not want to mine on top of blocks that are invalid under the new rules. If they do that, they’re basically mining a chain that will be less profitable for them. If 90 percent of the economy is following the new rules, then 90 percent of the hashrate should ignore blocks invalid under the new rules and not mine them – at least in theory. This would keep everyone on the same chain and avoid a chain split.
Of course, it if was a seriously contentious UASF, then non-upgraded users may decide to fork to a new chain anyway. It should be remembered that UASFs are not a useful way to implement contentious changes to Bitcoin. Contentious changes to the protocol will often lead to the creation of two separate chains rather than an upgrade for the original chain no matter how they are implemented. The UASF is simply a useful option in a situation where the economy has consensus on a change but the miners have not implemented it for whatever reason.
A UASF may still be a somewhat risky endeavor, so it’s unclear if users will make a serious push for it anytime soon. It’s possible that users will force the issue in a situation where the risks of doing nothing outweigh the risks of implementing Segregated Witness via a UASF.