Taproot[1], a proposed protocol upgrade that would improve Bitcoin’s privacy and flexibility, is in its late stages of development. Bitcoin Core contributors agree that the upgrade would benefit Bitcoin, and so far it generally appears to be welcomed by the wider Bitcoin ecosystem as well. It’s therefore likely that Taproot will make its way into a Bitcoin Core release, with other Bitcoin implementations possibly to follow.
But one question remains: how should the Bitcoin network itself upgrade? Taproot is a consensus protocol change, which means that Bitcoin nodes must somehow switch from the old rules to the new rules without splitting the network into factions enforcing different rules. For various reasons, this has in the past sometimes proven to be a challenge.
Improved strategies to activate protocol upgrades are now being contemplated.
Previous Soft Forks and BIP 9
The good news is that Taproot will be a soft fork. This type of upgrade adds or tightens rules — as opposed to a hard fork which removes or loosens rules. The nice thing about adding or tightening rules is that anything that an upgraded node considers valid, a non-upgraded node considers valid, too. (If an old node accepts both transaction types A and B, but new rules only allow transaction type A, the old node would remain compatible on a network enforcing the new rules.)
Bitcoin’s earliest soft forks were activated though flag days. Developers (in particular, Satoshi Nakamoto[2]) embedded a future date in the code of a new Bitcoin software client release, specifying a point in time where upgraded nodes would enforce the new rules. Miners and users were encouraged to upgrade before that date to avoid network splits. (As an aside, in those days, miners and users were in these days more often than
