Bitcoin (BTC) Taproot Upgrade at Block 709,632 Left Wallet Support Optional

Wallets and Exchanges Face the bc1p Question

Bitcoin (BTC) wallets that now show a Taproot option, and the exchanges and hardware signers that have to accept the bc1p addresses it produces, are the parties that decide whether the upgrade's benefits reach ordinary users. Taproot is a soft fork of the Bitcoin (BTC) protocol, activated on the Bitcoin mainnet at block height 709,632 in 2021. It introduced Pay-to-Taproot (P2TR) outputs governed by version 1 witness rules. The change affects how coins are spent, not what holders own: recipients still receive BTC, no separate Taproot token exists, and the Bitcoin (BTC) price and supply schedule sit outside its scope.

The upgrade bundles three coordinated proposals. BIP 340 specifies Schnorr signatures on the secp256k1 curve, a different algebraic structure from the ECDSA scheme Bitcoin had relied on, and one that lends itself to multi-party signing protocols. BIP 341 defines the Taproot output format, its commitment structure and the rules for spending it. BIP 342, known as Tapscript, sets the script execution rules inside those outputs. The three interlock but describe distinct layers, and treating them as a single feature is a common error.

On addresses, mainnet Taproot outputs usually begin with bc1p and use Bech32m encoding, while native SegWit version 0 addresses begin with bc1q and use Bech32. Both live on the same chain; there is no second Bitcoin (BTC) network and no conversion by manually editing a prefix. The prefix rides on the Segregated Witness versioning system, which created numbered witness versions, with Taproot occupying version 1. Old outputs remain valid after activation, and migration is voluntary: moving coins into a Taproot output still costs an on-chain transaction fee. The soft fork also leaves the Proof of Work consensus layer untouched, which is why compatibility work concentrates in wallets rather than in the protocol itself.

Key Path and Script Path Do Different Jobs

A Taproot output can be spent two ways, and the split drives everything an observer sees on-chain. The Key Path authorizes a spend with a Schnorr signature that validates against the output's public key. Nothing about alternate scripts is disclosed, and in a cooperative design, such as a MuSig-type protocol, several participants can jointly produce one signature that looks on-chain like a single owner's. Chain analysis cannot reliably tell a solo spend from a collaborative one. The Script Path applies when a committed condition is exercised: the spender reveals the chosen script, supplies the data that satisfies it and proves the script belongs to the output's commitment. Unused branches stay hidden, but the exercised script and its proofs do appear.

Typical uses differ accordingly. Direct payments and cooperative multi-party spending run through the Key Path, while timelocks, backup conditions and other contingencies ride the Script Path. Two misconceptions matter for anyone moving funds. Multisig does not automatically collapse into one signature at activation; it requires a suitable multi-party signing protocol plus wallet support, and legacy multisig coins are not converted. Cross-input signature aggregation is likewise not a feature this upgrade provides automatically. On privacy, Taproot trims the disclosure of spending conditions and lets different designs converge on identical-looking Key Path spends, but amounts, output structure and transaction links stay public and analyzable, so a bc1p address is not an anonymity guarantee.

Fees are not uniformly lower either. Cost depends on a transaction's virtual size, the chosen sat/vB rate and mempool competition, and the data cost of creating a Taproot output differs from that of later spending it, so the two stages must be evaluated together. Consider a two-party custody arrangement: in normal operation the parties sign cooperatively through the Key Path, while a timelocked backup script is committed in advance and only revealed and satisfied if cooperation fails. The concept is general, but keys, scripts, backups and signing protocols must be built correctly for the effect to hold.

What Wallet Support Still Decides

The protocol work itself is settled: BIP 341 fixes the output, commitment and spending rules, and node operators running current consensus rules validate P2TR spends without added configuration. What is not settled is the tooling around it. A wallet able to receive at a Taproot address is not automatically one that can sign a Key Path spend, and hardware devices or custom multisig setups must be rebuilt to use the new path safely. The expanded script design space that projects now grouped under Bitcoin DeFi build on, and the version 1 witness structure that later carried Bitcoin Ordinals inscriptions, both rest on these same rules. Until signers, devices and deposit platforms align on bc1p, adoption stays opt-in and uneven.