Bitcoin has no CEO, no board, no central authority that can push an update. Changing the protocol requires broad consensus — and one of the most established ways to achieve that is through miner signalling, where the people who produce Bitcoin's blocks indicate whether they're ready to enforce new rules.
A soft fork is a backward-compatible rule change. Nodes that haven't upgraded still accept blocks produced under the new rules — they just don't enforce them. This means the network doesn't split as long as a majority of miners adopt the new rules. Hard forks, by contrast, require everyone to upgrade or the chain diverges.
Each Bitcoin block contains a version field in its header. Under BIP9 and BIP8, individual bits in that field are assigned to specific upgrades. When miners set a bit to 1, they're telling the network: "my software supports this change and I'm ready to enforce it." Every 2,016 blocks (~two weeks), the network counts how many blocks signalled. If the threshold is met, the upgrade locks in.
A simple majority isn't enough — if 49% of miners haven't upgraded, they could produce blocks that are valid under the old rules but invalid under the new ones, causing orphaned blocks and instability. The 90% threshold used for Taproot (via Speedy Trial) gives strong confidence that the new rules are being enforced by enough of the network to make non-signalling blocks economically irrelevant.
These are two separate events. Lock-in happens when the threshold is crossed — the upgrade is committed and cannot be stopped regardless of what miners do next. Activation happens later (for Taproot, ~6 months after lock-in) when the new rules actually come into effect. This delay gives everyone time to upgrade their nodes.
Taproot is actually three Bitcoin Improvement Proposals shipped together — BIP 340, 341, and 342. Together they introduce a new signature scheme, a new way to structure spending conditions, and a new scripting language. The result: more privacy, lower fees, and significantly more flexibility for Bitcoin smart contracts.
Bitcoin originally used ECDSA signatures. Taproot replaces these with Schnorr signatures — a mathematically simpler scheme with several advantages. Schnorr signatures are smaller (saving block space), support key aggregation (multiple parties can produce a single signature indistinguishable from a regular one), and allow batch verification, making validation faster for nodes.
Taproot introduces a new output type (P2TR — Pay to Taproot). Every Taproot output commits to both a key path (a single public key for the happy path) and a script path (a Merkle tree of alternative spending conditions). If all parties cooperate, the output spends via the key path and looks identical to any other simple payment — revealing nothing about the smart contract behind it.
Complex Bitcoin contracts often have many possible spending conditions — timelocks, multisig arrangements, hash preimages. Before Taproot, all of those conditions had to be revealed on-chain when spending. With MAST, conditions are arranged in a Merkle tree. Only the condition actually used needs to be revealed; the rest remain private. This reduces transaction size and improves privacy significantly.
Tapscript is a revised version of Bitcoin's scripting language, used exclusively within Taproot script paths. It makes it easier to add new opcodes in future upgrades, fixes several long-standing limitations of the original Script language, and introduces per-input signature hashing that prevents a class of transaction malleability issues. It's designed to be extensible — future soft forks can build on top of it cleanly.