Taproot

Taproot is the soft fork that activated on Bitcoin in November 2021 at block height 709,632, bringing two cryptographic upgrades into the protocol: Schnorr signatures (BIP-340) and Taproot itself (BIP-341, authored by Pieter Wuille, Jonas Nick, and Anthony Towns), along with the new Tapscript language (BIP-342) for advanced spending conditions.

The headline feature is that every Taproot output looks the same on-chain. Whether it backs a single-sig wallet, a multisig, or a complex script with timelocks and hash preimages, the output on the chain is just a 32-byte public key, and if the parties cooperate the spend is a single 64-byte Schnorr signature. Observers cannot tell which was used unless a script path is revealed. This is huge for privacy.

Taproot addresses start with bc1p (using bech32m encoding).

How it works

A Taproot output commits to either a single public key (the "internal key") or a tree of alternative spending scripts (the script paths), or both.

Two spending paths:

1. Key-path spending. If all participants in a multisig or complex contract agree, they can collectively sign with an aggregated public key (via MuSig2). The spend looks like a single signature on-chain; observers cannot tell whether script paths existed or what they would have been. This is the common case and the most private and cheapest spend type Bitcoin has.
2. Script-path spending (MAST). If they do not agree - someone is offline, a timelock triggers, or a backup branch is needed - one party can reveal only the script branch actually being executed, along with a Merkle proof that it was committed to in the original output. Other branches stay hidden.

The combination means complex contracts pay almost zero on-chain cost when they "go right" (everyone signs cooperatively), and only reveal the strictly necessary branch when they "go wrong."

What it unlocks

• MuSig2 / FROST aggregation. Multiple cosigners produce a single Schnorr signature on a single internal key. A 5-of-7 federation spends a Taproot output indistinguishably from a single-sig wallet.
• Lightning channel privacy. Cooperative channel closes look like any other Taproot key-path spend, no longer visibly "2-of-2 multisig closing."
• Cheap multisig. Pay for the signature you actually use, not for all the keys you committed to.
• Less data on-chain. Schnorr signatures are a fixed 64 bytes vs ECDSA's ~71-72 bytes after low-R grinding.
• Cleaner cryptography. Schnorr has tighter security proofs than ECDSA.
• A foundation for future protocols. Silent payments, Discreet Log Contracts (DLCs), and newer Lightning constructions all benefit from Taproot primitives.

Adoption

Taproot adoption took a few years to ripple through wallet software, hardware wallets, and infrastructure. As of 2026 it is widely supported for sending and receiving, but most major wallets still hand out native SegWit bc1q addresses by default: Bitcoin Core, Trezor, and Ledger all default to SegWit and offer Taproot as an option. About 5 percent of newly created outputs are bc1p..., down from the 2024 inscription peak, even though by count Taproot is now the largest output type in the UTXO set.

One structural property worth naming: Taproot outputs commit to the tweaked public key directly in the bech32m address - there is no hash layer in front. Every P2TR output is therefore "always-exposed" in post-quantum terms: the pubkey is on chain from output creation, regardless of whether it is ever spent. The tradeoff buys key-path privacy and efficiency for complex contracts. The fix when post-quantum signatures arrive is a new output type, not abandoning Taproot.

See Schnorr Signature and Signature Aggregation for the building blocks.

See The BIP Process for the process that got Taproot activated.

Go deeper in How Taproot Actually Works - the tweak, both spending paths byte by byte, what Schnorr did and did not change, the activation timeline, and five years of adoption numbers.