I think its useful to think of soft forks in 3 categories
- Feature soft forks
- Security soft forks
- Both Security and Feature Soft Forks
Feature soft forks
Here are examples of feature soft forks.
When people mention risk associated with soft forks. They usually mean chainsplit risk associated with deploying a new feature. Potentially non-upgraded node and an upgraded node could disagree with the validity of a given transaction mined in a block. We don’t want chainsplits - thus we require widespread consensus for deploying feature soft forks
Security soft forks
Here are some examples of what I call “security soft forks”
- BIP42
- BIP143
- Worst case block validation time (part of GCC)
- 64 byte txs (part of GCC)
- Time warp attacks (part of GCC).
Both security and feature enhancement soft forks
These BIPs were used to fix some sighash vulnerabilities that existed before bitcoin. To fix these security issues, we required allocating a new witness version. This introduced deployment risk because we were enabling new features (v0,v1 segwit).
The takeaway
Security soft forks do not have much chainsplit risk as feature and bundled (‘Both security and feature’) soft forks.
If someone was to try to trigger a chainsplit while a security soft fork is being deployed, by definition they are participating in behavior that is hostile to the network. The key insight here is we want to fork people exploiting the protocol off the network
Lets look at the Timewarp attack. This means the miner is attempting to increase block velocity and claim more rewards for themselves. If someone is actively attempting to exploit this, we want to fork them off the network via soft fork. If no one is exploiting the timewarp vuln, then we wont have a chain split. I.e. there is no risk to deploying this.
The only deployment risk I can think of related to security soft forks is implementation risk (i.e. a bug in the implementation).
Maybe this is self evident to other developers, but it was a realization I had this morning when reading through the Great Consensus Cleanup.
I think we should encourage deploying security soft forks independent of feature soft forks whenever possible to encourage deployment of security fixes as soon as the fix can properly be reviewed.
Am I missing something?