, 2022-05-16 17:30:00,
One of the most contentious questions in Bitcoin over the last five years has been how to activate soft forks. There have been many different mechanisms used in the history of Bitcoin to activate new features on the network, the iteration of which has generally evolved with the goal of making feature deployment as safe and non-disruptive as was possible. Until 2017, there was general consensus and not much disagreement as activation mechanisms changed, but during the deployment of Segregated Witness (SegWit), this changed.
SegWit became the issue that drove disagreement and contention over how features should be activated on Bitcoin for the first time. After the initial BIP9 deployment, dependent on miner signaling to lock in enforcement rules, a large majority of miners and mining pools refused to signal for activation with their blocks. At the time, many users became furious that miners were delaying the activation of a new feature and holding it hostage with demands for a hard fork to increase the block size (when, I might add, SegWit accomplished a block size increase through a soft fork), and the entire ecosystem was filled with completely inaccurate information about SegWit in an attempt to drive opposition to the feature itself based on outright lies.
BIP148 and the user-activated soft fork (UASF) wound up pushing miners to activate SegWit, and one of the big block pushes was called off, leaving the other to fork and eventually crash into irrelevance. But since then, Bitcoiners have generally avoided having the conversation about how new features should be deployed and activated. The topic has become contentious to the point of almost being a taboo.
I think it’s worth going through a high-level tour of some of the past activation mechanisms proposed and used…
To read the original article, go to Click here