Softfork
A softfork occurs if the new protocol rules consider the old rules as invalid. But according to the old rules, blocks following the new rules are still valid. That way, the softfork is backward compatible. This can be achieved by making the rules stricter – e.g. reducing the max. size of a transaction.
Again, we assume that the majority of the miners have updated their software.
A miner following the new rules creates block C (blue) after the protocol update and appends it to block B.
After that, a miner following the old rules finds a block (yellow). He will choose block C as the tip of the chain as we said that the new rules are stricter and valid under the old rules.
If a new miner finds another block, it has to choose block C as the tip of the chain. Block D is invalid according to the new rules he follows. Since the majority of miners updated their software it is likely that two or more miners find consecutive blocks. Block D orphans.
If another old miner finds a block in this situation, it will add it to block E, since this is the longest valid chain.
A new miner again has to choose block E’ and again the old block (F) orphans. The longest chain is A-B-C-D’-E’-F’-G’.
In the end, new miners always build the longest chain, and old miners will be puzzled that their blocks always become orphans. Old miners don’t earn any mining rewards while spending resources on energy and hardware. Thus they have an incentive to update their clients.
You can find a detailed explanation of softforks here: https://en.bitcoin.it/wiki/Softfork
It can be a rational design choice of new features to make sure that they are introduced as a softfork since this creates some pressure on old nodes to update their software while it prevents a permanent split of the chain. Softforks can be further divided into miner-activated softforks (MASF) and user-activated softforks (UASF).
Miner activated softforks
Activating a softfork means setting a date where miners, exchanges, wallets, and network users start applying the new rules.
A common date is necessary to prevent confusion and possible splits. The most common way to activate a softfork is to propose a mining power threshold that supports the new rules. Miners can signal their support by setting a particular version number. If the mining power supporting the new rules exceeds the threshold at a predefined date or block height, the (willing) miners automatically activate the new rules. That way, it is made sure that the majority of miners agree to the protocol update.
User activated softforks
In some cases, however, miners are somewhat reluctant to accept new rules. Maybe because they cause a profit setback, or they think another update is more beneficial.
In such a situation, the “other users” of the network like wallets, exchanges, and full nodes could initiate a softfork. They could start creating transactions that follow the new rules and decline transactions following the old rules. If enough users buy coins on the UASF-chain its value rises above the old chain. Besides, miners would not find any transaction which is valid from their (old) point of view. And this would create economic pressure to update their software. It is important to notice that an overwhelming majority of the “other users” need to follow the UASF.
Despite being called “user-activated”, the actual fork still is triggered by a miner. At least one miner needs to be upgraded to the new rules.
A UASF was suggested in BIP148 to activate SegWit. While this UASF was not successful by directly forcing the miners to update their software, it led to talks between industry representatives and finally to the activation of SegWit.
