# Security soft fork deployments arent risky **URL:** \ **Category:** Philosophy\ **Created:** [December 18, 2024, 5:43pm UTC](https://delvingbitcoin.org/t/security-soft-fork-deployments-arent-risky/1328 "2024-12-18T17:43:35Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![Chris\_Stewart\_5](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/chris_stewart_5/32/296_2.png) [@Chris\_Stewart\_5](https://delvingbitcoin.org/u/Chris_Stewart_5)\ **Post date:** [December 23, 2024, 2:55pm UTC](https://delvingbitcoin.org/t/security-soft-fork-deployments-arent-risky/1328/6 "2024-12-23T14:55:04Z")
> [@harding](#): > > Additionally, I think it’s important to remember that all soft forks work by making the rules more strict, so they all have a risk of confiscation. That confiscation risk can be subtle and can apply even to forks that seem to only affect miners. For example, there’s the widely held belief (that I share) that Bitmain resisted segwit because they were privately using covert asicboost to increase their hardware’s effectiveness; blocks containing segwit transactions would not allow them to use that capability and (arguably) “confiscated” part of their capabilities. After reading this passage, it seems like there are 2 phases to softfork development - Design - Deployment I would put analyzing confiscation risk under the design phase. I agree there can be subtleties to (potentially) confiscatory soft forks. However I believe that risk is isolated in the design phase rather than the deployment phase. **If consensus is reached during the design phase** – for instance if there are certain Scripts could many nodes on the network – that risk is already baked into the cake in the deployment phase. We are disallowing something that is harmful to network operation. We should use this fact to our advantage when deploying a security soft fork. --- _[View the full topic](https://delvingbitcoin.org/t/security-soft-fork-deployments-arent-risky/1328)._