UASF (User Activated Soft Fork) Explained
A User Activated Soft Fork, or UASF, is a mechanism by which a network such as Bitcoin, can transition to a new set of consensus rules. Understanding that a soft fork itself is simply a backwards-compatible method of making changes to consensus rules, UASF is the mechanism by which such changes are actually implemented. A UASF requires that the soft fork occur at a specified date (flag day) and time, with Bitcoin full nodes enforcing the changes by upgrading their software and thus rejecting any blocks that do not adhere to the new set of consensus rules.
BIP-16, a Bitcoin Improvement Proposal which allowed for multi-signature addresses through the implementation of Pay-to-ScriptHash (P2SH), was the first proposed soft fork to be activated via the mechanism of a UASF. The proposal required that miners upgrade their software and indicate support for the changes by including the text, “/P2SH/”, in the input of the coinbase transaction of their created blocks. On February 1st 2012, the blockchain was then examined to determine the number of blocks supporting P2SH. Of the 1,000 blocks created in a week, more than 550, or 55%, were required to have the necessary “/P2SH/” in the input of the coinbase transaction for the proposal to be implemented. If successful, after February 15th 2012, all blocks with the P2SH transaction format would be validated by Bitcoin full nodes, however if not, they would be rejected.
MASF (Miner Activated Soft Fork)
Similar to how a UASF is a mechanism by which a network can transition to a new set of consensus rules, a MASF is also another mechanism that achieves the same outcome, but instead, requires miners to signal their readiness for such rule changes using their hashing power.
BIP-34 is a Bitcoin Improvement Proposal that provided a mechanism for miners to signal readiness for a consensus rule change by changing the version number in produced blocks to a value greater than 1, as well as requiring that the input of the coinbase transaction contain the block height.
For example, to signal the activation of BIP-34, miners were required to set the block version number from “1”, to “2”. The activation occurred in two stages:
- In stage one of the activation, when 750 out of the 1,000 most recently mined blocks had the version number “2”, they were also required to contain the block height in the input of the coinbase transaction. However, miners who still produced blocks with a version number “1”, were still accepted by the network.
- In stage 2 of the activation, when 950 out of the 1,000 blocks most recently mined blocks had the version number “2”, version number “1” blocks were no longer accepted by the network. Blocks with version “2” and the block height in the input of the coinbase transaction were considered to be the only valid blocks.
After successfully activating BIP-34, the MASF method was used a further two times in the signalling and activation of BIP-66 and BIP-65. Miners signalled support for BIP-66 by changing the block version number from “2” to “3”, thus invalidating all blocks with version “2” when the 950 of the 1000 most recent blocks had complied. Furthermore, miners signalled support for BIP-65 by changing their produced block version number from “3” to “4”, thus once again invalidating all blocks with version number “3” when 950 of the 1000 most recent blocks had made this change.
However, with the introduction of BIP-9, this method of miners signalling for readiness of a consensus change via increasing the block version number by 1 was changed to version bits instead. This change offered the advantage of being able to propose and activate a maximum of 29 soft forks simultaneously as opposed to one at a time as with the previous version.
Conclusion
To conclude, a soft fork is a backwards-compatible method of making changes to a set of consensus rules. UASF and MASF are simply two mechanisms of implementing such changes.
A UASF requires that a soft fork occur at a particular flag date, with the changes then being enforced by full nodes. Full nodes will accept or reject a miner’s block based on the new set of consensus rules, and as such, miners will have an incentive to adhere to the new rules or risk producing invalid blocks and thus wasting resources.
Conversely, a MASF requires that miners signal their readiness for rule changes using their hash power. Miners accomplish this by changing the version bit numbers in the blocks that they produce. When a certain percentage of produced blocks have signalled acceptance, full nodes can then enforce rule changes accordingly.
