BIP-341 is the Bitcoin Improvement Proposal that specifies the Taproot upgrade, introducing Pay-to-Taproot (P2TR) as a native SegWit version 1 output type that unifies key-path and script-path spending under a single Schnorr-based commitment. It integrates Merklised Alternative Script Trees (MAST) so that only the executed spending branch is revealed on-chain, preserving the privacy of unexplored script conditions. BIP-341 activated on the Bitcoin mainnet at block 709,632 in November 2021 via the Speedy Trial soft-fork mechanism, requiring 90% miner signalling. It forms part of the Taproot bundle alongside BIP-340 (Schnorr signatures for Bitcoin) and BIP-342 (Tapscript), collectively the largest upgrade to Bitcoin’s scripting system since SegWit.
Overview
- BIP-341 addresses three long-standing limitations in Bitcoin’s script system: (1) privacy leakage from multi-condition scripts that reveal all unused branches on-chain; (2) inefficiency of ECDSA Signature schemes versus the linearly aggregatable Schnorr Signature; and (3) size penalties for complex contract constructs under Pay-to-Script-Hash (P2SH) and P2WSH.
- The upgrade is a soft fork, meaning nodes running older software continue to see P2TR outputs as spendable by anyone; only upgraded nodes enforce the new validation rules. Miners signalled readiness via the Speedy Trial mechanism, reaching the 90% threshold in June 2021 and locking in at block 687,285.
- Bitcoin Core v22.0 shipped full BIP-341 support, and all major wallets and exchanges adopted P2TR by mid-2022. The Lightning Network protocol leverages Taproot for cooperative channel closures, reducing on-chain footprint and improving Bitcoin Fungibility.
Key Components
Pay-to-Taproot (P2TR) Output
- The primary new output type introduced by BIP-341; a SegWit v1 output carrying a 32-byte tweaked public key.
- Formed by combining an internal key with a Cryptographic Commitment to an optional Merklised Alternative Script Tree.
- Spending via key path broadcasts a single Schnorr Signature — indistinguishable on-chain from a plain single-signature spend regardless of underlying script complexity.
- Spending via script path reveals only the satisfied leaf script plus a Merkle Tree proof of inclusion; all other script branches remain hidden.
Taproot Tweak
- The internal public key is tweaked with
H_taptweak(internal_key || merkle_root)using a Tagged Hash construction, binding the key to the MAST root cryptographically. - When no script tree is needed, the tweak uses an empty MAST root, producing a pure key-path-only output.
- The tweak ensures no Cryptographic Commitment ambiguity: a key-path spend is indistinguishable from a simple Schnorr Signature spend.
Merklised Alternative Script Tree (MAST)
- A binary Merkle Tree whose leaves are individual spending scripts (called “tapleaves”), each tagged with a version byte and a script body.
- Allows wallets to commit to an arbitrary number of spending conditions in O(log n) proof size on-chain.
- The leaf version mechanism (currently
0xC0) provides a forward-compatible upgrade path for new Bitcoin Script semantics (the “Tapscript” version). - Only the leaf being spent plus its Merkle inclusion proof are broadcast; unexplored branches contribute no on-chain data.
Control Block
- A data structure included in the witness stack for script-path spending.
- Contains the leaf version, internal public key, and the Merkle path proving the leaf’s inclusion in the MAST.
- The verifier recomputes the tweaked key from the control block and checks it against the on-chain output key, then executes the script using BIP-342 (Tapscript) rules.
Schnorr Key Aggregation Compatibility
- BIP-341 outputs natively support Multisignature schemes such as MuSig2 without requiring any changes to the output format.
- Multiple signers can aggregate their keys off-chain into a single internal public key, making a k-of-n multisig spend appear identical to a single-signature spend.
- This extends naturally to threshold signatures, Multisignature wallets, and Lightning Network channel funding outputs.
Applications and Use Cases
- Privacy-enhanced multisig wallets: hardware wallet vendors (Ledger, Trezor, ColdCard) support Taproot P2TR, allowing 2-of-3 multisig to appear on-chain as single-sig via MuSig2.
- Lightning Network channels: cooperative closes use key-path spending; only uncooperative closes fall back to script-path, reducing the on-chain footprint and distinguishability of channel activity.
- Taproot Assets protocol: formerly known as Taro; leverages the MAST script tree to embed asset issuance metadata in P2TR outputs, enabling tokenised assets on Bitcoin without base-layer consensus changes.
- Bitcoin Smart Contracts: discrete log contract (DLC) oracles, atomic swaps, and time-locked vaults all benefit from MAST’s ability to commit multiple spending paths without revealing unused ones.
- CoinJoin privacy: when all participants use key-path spending, Taproot CoinJoin transactions are indistinguishable from ordinary transactions, improving Bitcoin Fungibility.
- Cross-chain atomic swaps: the script-path mechanism makes hash-locked and time-locked swap contracts more compact and private, strengthening interoperability with other UTXO chains.
- Threshold signature schemes: enterprises and custodians benefit from cryptographically sound n-of-m signatures that carry no on-chain script size overhead vs. simple sends.
Standards and Context
- BIP-341 was authored by Pieter Wuille, Jonas Nick, and Anthony Towns and follows the Bitcoin Improvement Proposals process governed by a BIP editor and community review.
- The activation mechanism used was Speedy Trial (described separately in BIP-8 variant): a 3-month signalling window with a 90% miner threshold, designed to minimise activation controversy following the SegWit2x dispute.
- Three BIPs form the Taproot bundle: BIP-340 (Schnorr/secp256k1 signatures), BIP-341 (Taproot output semantics), and BIP-342 (Tapscript opcode semantics).
- The proposal references BIP-114 (MAST) and BIP-116 (MERKLEBRANCHVERIFY) as earlier exploratory proposals that were superseded by the integrated Taproot design.
- P2TR is a SegWit version 1 output and as such is distinct from P2WPKH (v0) and P2WSH (v0); it benefits from the third-party malleability fix introduced by SegWit.
- The Bitcoin Network enforces Taproot rules as a consensus upgrade; nodes not upgraded to Bitcoin Core v22.0 or equivalent will not reject invalid Taproot spends (they see them as anyone-can-spend outputs), though the economic majority’s nodes do enforce them.
- No further BIP has amended BIP-341 as of 2026; proposals such as OP_CAT (BIP-347) and OP_CHECKSIGFROMSTACK extend Tapscript further and depend on BIP-341 as a prerequisite.