The Bitcoin community is abuzz with discussion about shaolinfry's proposal of a UASF to activate SegWit as an alternative to the Version Bits activation. I've seen frequent and extensive discussion of the proposal and especially questions about the risks and advantages of it compared to other methods of softfork activation and hardforks.
- What does the UASF proposal entail?
The UASF proposal is an extension of BIP9 that allows soft-forks to specify a mandatory activation time. If miners have not started signaling support by this time, they must start to signal. Any blocks not signaling support for the soft-fork after this time are rejected.
BIP148 is an instance of the UASF proposal that implements a UASF for SegWit. The idea is to have the economic majority, users and businesses, run software that forces miners to activate SegWit. If miners do not start signaling for SegWit by the proposed time, their blocks and the bitcoins mined within will be invalid. In this sense, it is a hard-fork for miners, but a soft-fork for most full-node operators.
A soft-fork usually undergoes the IsSuperMajority process, where miners do not start to enforce the new rules until 95% of the last 1000 blocks signal readiness to enforce. This is usually just for coordination, so that miners are in agreement about exactly when the new rules become enforced. Of late, however, miners have been using this process to block the SegWit soft-fork from being enforced at all. Many believe that miners should not be able to block soft-forks, so the UASF was created to remove that ability from miners.
- How do its risks compare to other methods of upgrading the protocol?
A UASF may transition to be enforced before miners have updated their software to support it (typically this would be intentional on a miner's part, as the activation date would be chosen very far in advance). In this case, that miner may be mining invalid blocks, according to the rest of the upgraded network. If a large portion of the network has upgraded their software to enforce the signalling for the soft-fork, but a large portion of the miners do not agree to signal for the support of the soft-fork, then a chain fork may occur. Non-mining nodes would see very slow block generation times and the transaction backlog could grow. Mining nodes would produce blocks, and bitcoins within, that are not acknowledged as valid by exchanges and users, rendering their mined bitcoins worthless if they do not upgrade.
This situation would create a stand-off between economic stake-holders and miners. For upgraded nodes, the longer the stand-off continues, the more transactions build up in the backlog without miners mining them. For miners, a chain-split means they are creating bitcoins that exchanges and users will not accept as payment, which is essentially losing money. It is undetermined which group would give-in first and support the other's chain just for the sake of restoring consensus and clearing the transaction backlog. Users and exchanges already cope with low transaction throughput and high block solve times due to normal variance, whereas miners currently have nearly 100% of their blocks accepted by the network. So I suspect the miners would be the first to give in and start signalling support for the soft-fork they don't like.
However, a miner may produce a block which signals support for a soft-fork without actually enforcing the new rules imposed by the soft fork. This may conceal the lack of consensus temporarily, for as long as the produced blocks follow all the rules of the new soft-fork. As soon as a block is produced that does not satisfy the new soft-fork rules but is still valid according to the old pre-soft-fork rules, there would be a chain split with the same stand-off dynamics mentioned before.
UASFs also rely on getting a large portion of the network, especially large economic actors such as exchanges, to upgrade. If this does not happen, and the miners do not start signalling support for the new soft-fork on their own, then the minority of nodes that did upgrade risk forking onto their own chain with no miners on it. This may cause outages of some bitcoin services, but since the bulk of nodes and miners are supporting the growing chain, there would at least be consensus on which chain is valid. Upgraded users would have to downgrade their software to return to consensus with the main chain. In this case, the UASF fails.
But who decides whether a soft-fork has enough consensus to warrant a mandatory activation time? Shaolinfry has this to say on this topic:
There is an implicit assumption in my text, that the decision to deploy a soft fork (regardless of the activation method) is based on a reasonable expectation that users will make use of the new feature. Hashrate signalling is not a vote, but a coordination trigger. Soft forks are backwards compatible and opt-in; so long as they are well written and bug free, users should at worst, be agnostic towards them because they have a choice whether to safely use the new feature or not, without preventing others' enjoyment of the feature. A controversial or unreasonable soft fork would not gain traction and I believe it would be fairly self evident. [Source]
So UASFs could be used to attempt to force controversial or potentially harmful updates, but enforcing the UASF activation time would require the majority of the network to upgrade, so this may be seen as a relatively small risk factor.
In short, UASFs are more risky, but may be deemed necessary when miners refuse to support soft-forks that have the backing of the economic majority.
I would refine (in square brackets) StephenM's answer above as follows:
"For [UASF] upgraded nodes, the longer the stand-off continues, the more transactions build up in the backlog without miners mining them.
For miners, a chain-split means they are creating bitcoins that exchanges and users [ON THE UPGRADED NODES ONLY] will not accept as payment, which is essentially losing money. It is undetermined which group would give-in first and support the other's chain just for the sake of restoring consensus and clearing the transaction backlog."
