Bitcoin Upgrades: SegWit, Taproot & Soft Forks

Why Bitcoin Changes Slowly

Bitcoin has no company, release manager or vote that can change its rules. Every full node, meaning a computer that checks each block against the rules itself, enforces them, so a change only works if enough of the network adopts it. The gentlest kind is a soft fork: a change that makes the rules stricter, so blocks built by upgraded software are still accepted by older software. The Taproot specification (BIP-341) says that older software continues to operate without modification. A hard fork, by contrast, allows blocks that older software would reject, so everyone must upgrade or the network can split in two. SegWit and Taproot were both soft forks.

SegWit: Moving the Signatures

SegWit (Segregated Witness, BIP-141) separates a transaction's signatures, called the witness, from the data that determines its identifier, the txid. Before it, a third party could change how a signature was encoded and so change the txid without changing what the transaction did, a flaw called malleability. BIP-141 describes the new design as making nonintentional malleability impossible. Miners switched it on by signalling during a window that BIP-141 set on mainnet from 15 November 2016 to 15 November 2017. Native SegWit addresses of the first version begin with 'bc1q', as the examples in BIP-173 show.

Taproot: Cheaper, More Private Spending

Taproot is three specifications deployed together: BIP-340 (Schnorr signatures, a scheme whose signatures can be combined), BIP-341 (the spending rules) and BIP-342 (script validation). Its central idea is that one output can be spent either by a single key or, optionally, by a script, and the two look alike on-chain unless the script route is used. A group of signers can combine their keys into one, so a shared wallet can spend in a way that is indistinguishable from an ordinary single-key payment. Taproot activated at block 709,632, which carries a timestamp of 14 November 2021 (UTC). Its addresses begin with 'bc1p'.

• What each changed: SegWit moved signatures out of the txid and set a new block weight limit; Taproot added Schnorr signatures and key-or-script outputs.
• What a user sees: bc1q addresses for SegWit's original script version, bc1p addresses for Taproot, which uses the Bech32m encoding from BIP-350.
• How both were introduced: as soft forks, so nodes that had not upgraded kept following the chain.

How a Soft Fork Is Switched On

A soft fork needs a way to say when the new rules begin. BIP-9 turns the version field of the block header into a set of bits, one per separate change, so several deployments can run in parallel. Each deployment moves through the states DEFINED, STARTED, LOCKED_IN, ACTIVE or FAILED, decided once per retarget period. Miners set the deployment's bit to signal readiness. As of October 2026, BIP-9 defines that period as 2,016 blocks, sets lock-in at 1,916 of them (95%) and suggests a timeout one year after the start time. SegWit used this design with bit 1, as BIP-141 specifies.

Two Contrasting Activation Paths

SegWit's BIP-9 window ran from 15 November 2016 to 15 November 2017, and lock-in needed 95% of blocks in a 2,016-block period to signal, the BIP-9 threshold. BIP-148 proposed a different lever: a flag-day rule under which, between 1 August 2017 and 15 November 2017, nodes running it would reject any block that did not signal for SegWit, unless SegWit had already locked in. That moved the pressure from miners alone onto the nodes that enforce the rules. BIP-141 itself carries the status Deployed as of October 2026.

By contrast, Taproot used a third route. The Bitcoin Core 0.21.1 release notes describe a variation of BIP-9 called Speedy Trial: the start date was 24 April 2021, with signals counted from the first retarget period after it; lock-in needed 90% of a 2,016-block period (1,815 blocks), and BIP-341 gives 11 August 2021 as the timeout. The activation could not occur before block 709,632, a height reached on 14 November 2021 (UTC), so that operators had time to upgrade once the change locked in. The notes added that, if Speedy Trial failed, a follow-up mechanism was expected. As of October 2026, BIP-341 records that the deployment did activate at that height.

What Taproot Added Under the Hood

BIP-340 specifies 64-byte Schnorr signatures over the secp256k1 curve, a fixed size where the older DER-encoded ECDSA signatures run up to 72 bytes, with 32-byte public keys in place of 33-byte ones. Schnorr signatures are linear, so several parties can produce one signature that is valid for the sum of their public keys, the building block for compact multisignatures. BIP-341 adds Merkle branches: a tree of scripts whose root is committed in the output, so a spender reveals only the branch that actually runs. Spending by key alone reveals nothing about whether a script route existed.

Covenants: Proposals That Have Not Activated

A covenant is a rule attached to a coin that restricts how it can be spent later, beyond which key signs. Two proposals in the BIPs repository add covenant-like power. BIP-119 (OP_CHECKTEMPLATEVERIFY, assigned on 6 January 2020) lets an output commit to a hash of the transaction that must spend it, covering fields such as the version, locktime, sequences, outputs and input index; its stated motivation is to reduce the trust, interactivity and storage requirements of pre-signed transactions. BIP-347 (OP_CAT in Tapscript) would redefine the unused Tapscript opcode OP_SUCCESS126 as the joining of two stack items, with each result capped at 520 bytes.

Draft and Complete Are Not the Same as Active

Each BIP header carries a status. As of October 2026, BIP-141, BIP-340 and BIP-341 are marked Deployed, BIP-119 is marked Draft, and BIP-347 is marked Complete, a label added by a changelog entry dated 1 March 2026. BIP-347's own text, as read in October 2026, still says OP_CAT 'would be activated via a soft fork', so the label describes the maturity of the document and not a switch on the network. The header evidence available in October 2026 therefore shows no activation for either covenant proposal. BIP-347 also recalls that OP_CAT was disabled in 2010 and notes that Tapscript's 520-byte stack element limit removes the memory-growth concern attributed to that removal.

How Witness Space Made Inscriptions Cheap

As of October 2026, BIP-141 defines block weight as the non-witness size times three plus the total size, with a limit of 4,000,000, so a witness byte uses one weight unit where other bytes use four. The Ordinals handbook says inscription content is stored in taproot script-path spend scripts, which receive the witness discount, and that single data pushes may not exceed 520 bytes, so large files are split across pushes. Because script spends need an existing Taproot output, an inscription takes two steps, a commit transaction and a reveal transaction. BIP-341 states its aims as privacy, efficiency and flexibility of scripting, and inscriptions are not among them.

Scope, Trade-offs and the Quantum Question

Each upgrade chose a narrow scope. BIP-341 explains that combining every known idea into one proposal would be hard to review and could miss discoveries, so it left cross-input signature aggregation out because its interaction with upgrade mechanisms was still unsettled. It also argues that hiding a key behind a hash gives only weak protection against quantum computers, because spending transactions reveal the key while waiting for confirmation and a large share of coins is not protected that way regardless. BIP-347 adds that a sufficiently powerful quantum attacker could bypass a Taproot script route through the key route.