BIP 9 (VersionBits)

BIP-9 introduced VersionBits, the miner-signaling mechanism used to coordinate Bitcoin soft-fork activation. The premise: encode candidate soft-fork proposals into specific bits of the block header's version field, and let miners set those bits to indicate readiness.

The mechanism:

1. A new BIP is assigned one of the version bits and a deployment window (a start time and an end time).
2. During the window, miners can set the bit in their blocks to signal support.
3. If 95% of blocks in a 2,016-block retarget period signal, the soft fork "locks in" for the next retarget period and then activates.
4. If the deployment window ends without reaching threshold, the proposal expires.

This worked cleanly for its first deployment, the CSV soft fork of 2016 (BIP-68, BIP-112 and BIP-113). It famously broke down during the SegWit activation in 2017. Signaling opened on November 15, 2016, but in May and early June 2017 only about 30 percent of blocks signaled for SegWit, far short of the 95 percent it needed. That deadlock led to alternative activation methods: the BIP-8 proposal of February 2017, BIP-148 (UASF) and BIP-91. Taproot in 2021 used neither BIP-8 nor a flag day. It used Speedy Trial, a modified BIP-9 deployment with a 90 percent threshold, a short signaling window and a minimum activation height, which would simply have failed if miners had not signaled.

BIP-148's supporters took a lesson from the SegWit fight: miners signal readiness, but they don't decide the rules. The SegWit2x organizers gave the credit to their own deal instead. Either way, BIP-9 worked smoothly for upgrades nobody opposed and had no clean answer for contested ones. BIP-8 adds an option to make signaling mandatory at the end of a deployment. Speedy Trial took a different path for Taproot: miners could still have stalled it, but only for about three months.

See The BIP Process for how version bits fit the wider upgrade machinery.