<p>Most past soft forks have been deployed with miner activated soft forks, and we know this because the deployment mechanisms used only allowed for miner activated soft forks. For a user activated soft fork to happen, the deployment mechanism would have to have some form of activation that is not reliant on miners. Thus far, the activation methods used have all deployed based on miner behavior and not a flag day.</p>
<p>There are two exceptions to this where it could be argued that those soft forks were user activated and not miner activated. The first is BIP 16 which ostensibly activated via a flag day (i.e. all blocks after a certain time must support BIP 16). However the flag day was determined only after a certain threshold of miners signaled support for BIP 16 in their blocks. So while the code was a flag day, the process was still a miner activated soft fork, just done manually rather than through code.</p>
<p>The second exception is segwit. However segwit used BIP 9 as its activation mechanism and that is entirely dependent on miner signaling. So technically, it is strictly a miner activated soft fork. But you could argue that it was user activated because users were running software that would have activated on a flag day, but miners began signaling readiness before that day. So the exact mechanism was through miner signaling, but perhaps it was user activated because users threatened miners by running software that had a user activated mechanism.</p>
<p>For future soft forks, it is likely that a combination of BIP 9 (MASF) and BIP 8 (both MASF and UASF) will be used. You can then determine whether it was miner activated or user activated. For both, miners can signal in their blocks to activate the fork. For BIP 8 only, after a certain time, the fork will activate via a flag day, so if that occurs, then it is a user activated soft fork.</p>
<p>The only soft fork that should be classified as a UASF is BIP 30. This was activated by a flag day and miner signaling was not officially part of the activation.</p>

CC BY-SA 4.0
2020-11-05T04:53:20.543Z
Thanks Andrew. This was exactly what I was looking for. I was not entirely sure which type of soft-fork to classify BIP30 as, This is where I got stuck. I never really thought about BIP16 deployment as being different in code and practice. I will have to think about this a bit.
Aman Saggu
CC BY-SA 4.0
2020-11-06T05:24:06.393Z
I think the SourceForge soft forks may also have been UASF, particularly 1MB Block Size.
Aman Saggu
CC BY-SA 4.0
2020-11-04T16:32:13.297Z
2020-11-04T18:40:19.317Z
2020-11-04T18:40:19.317Z
Ava Chow
<p>This seems to be the most common definition</p>
<ul>
<li><em>When a majority of miners upgrade to enforce new rules, it is called a miner-activated soft fork (MASF). When full nodes coordinate to
enforce new rules, without the support from miners, it is called a
user-activated soft fork (UASF).</em></li>
</ul>
<p>How do we know which soft-forks were implemented by full nodes upgrading clients or miners upgrading clients? Is there any way of knowing, or do we just guess?</p>
<p><a href="https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md" rel="noreferrer">https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md</a></p>

<terminology><soft-fork><activation-mechanism>
How do we know which soft-forks were implemented using User-Activated Soft Fork or Miner-Activated Soft Fork?
Aman Saggu
# How do we know which soft-forks were implemented using User-Activated Soft Fork or Miner-Activated Soft Fork?

(Asked by: username_0 on 2020-11-04)

This seems to be the most common definition

* *When a majority of miners upgrade to enforce new rules, it is called a miner-activated soft fork (MASF). When full nodes coordinate to
  enforce new rules, without the support from miners, it is called a
  user-activated soft fork (UASF).*

How do we know which soft-forks were implemented by full nodes upgrading clients or miners upgrading clients? Is there any way of knowing, or do we just guess?

<https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md>

**Tags:** terminology, soft-fork, activation-mechanism


---

## 1 answers

### Answer by username_1 on 2020-11-04. Score: 4 | Accepted answer

Most past soft forks have been deployed with miner activated soft forks, and we know this because the deployment mechanisms used only allowed for miner activated soft forks. For a user activated soft fork to happen, the deployment mechanism would have to have some form of activation that is not reliant on miners. Thus far, the activation methods used have all deployed based on miner behavior and not a flag day.

There are two exceptions to this where it could be argued that those soft forks were user activated and not miner activated. The first is BIP 16 which ostensibly activated via a flag day (i.e. all blocks after a certain time must support BIP 16). However the flag day was determined only after a certain threshold of miners signaled support for BIP 16 in their blocks. So while the code was a flag day, the process was still a miner activated soft fork, just done manually rather than through code.

The second exception is segwit. However segwit used BIP 9 as its activation mechanism and that is entirely dependent on miner signaling. So technically, it is strictly a miner activated soft fork. But you could argue that it was user activated because users were running software that would have activated on a flag day, but miners began signaling readiness before that day. So the exact mechanism was through miner signaling, but perhaps it was user activated because users threatened miners by running software that had a user activated mechanism.

For future soft forks, it is likely that a combination of BIP 9 (MASF) and BIP 8 (both MASF and UASF) will be used. You can then determine whether it was miner activated or user activated. For both, miners can signal in their blocks to activate the fork. For BIP 8 only, after a certain time, the fork will activate via a flag day, so if that occurs, then it is a user activated soft fork.

The only soft fork that should be classified as a UASF is BIP 30. This was activated by a flag day and miner signaling was not officially part of the activation.

> **Comments:**
> **username_0**: Thanks Andrew. This was exactly what I was looking for. I was not entirely sure which type of soft-fork to classify BIP30 as, This is where I got stuck. I never really thought about BIP16 deployment as being different in code and practice. I will have to think about this a bit.  
> **username_0**: I think the SourceForge soft forks may also have been UASF, particularly 1MB Block Size.  

---

