BIP-341 (Taproot Spending Rules)

What Is BIP-341?

BIP-341 is the Bitcoin Improvement Proposal that defines Taproot spending rules. Authored by Pieter Wuille, Jonas Nick, and Anthony Towns, it specifies how Pay-to-Taproot (P2TR) outputs are constructed and spent on the Bitcoin network. Activated at block 709,632 on November 14, 2021, BIP-341 introduced SegWit version 1, the most significant upgrade to Bitcoin since Segregated Witness in 2017.

The core insight behind BIP-341 is that most transactions settle cooperatively. Even complex contracts involving multiple signers, timelocks, or conditional logic typically end with all parties agreeing on the outcome. Taproot optimizes for this common case: cooperative settlements produce a single signature that looks identical to any ordinary payment, while the full script machinery is only revealed when cooperation breaks down.

BIP-341 works alongside two companion proposals: BIP-340, which defines the Schnorr signature scheme and x-only public keys, and BIP-342, which defines the Tapscript rules for executing scripts inside Taproot outputs. Together, these three BIPs form the complete Taproot upgrade.

How It Works

Every P2TR output locks funds to a 32-byte output key Q. This key is derived from two components: an internal public key P (representing the key-path owner) and an optional Merkle tree of scripts (representing alternative spending conditions). The spender can unlock the output through either path.

Output Key Construction

The output key Q is computed by tweaking the internal key P with a commitment to the script tree:

Q = P + int(t) * G

where:
  P = internal public key (32-byte x-only)
  t = hashTapTweak(P || merkle_root)
  G = secp256k1 generator point

If no script tree exists (key-path only), the tweak simplifies to t = hashTapTweak(P) with no Merkle root appended. The resulting output key Q is encoded in a 34-byte scriptPubKey: OP_1 OP_PUSHBYTES_32 <Q>. On-chain, this appears as a bech32m address starting with bc1p.

The hashTapTweak function uses the tagged hash scheme defined in BIP-340: SHA256(SHA256("TapTweak") || SHA256("TapTweak") || data). Tagged hashes provide domain separation, ensuring that hashes computed for different purposes (tweaks, leaf nodes, branches, signature messages) can never collide.

Key-Path Spending

Key-path spending is the simplest and most private way to spend a P2TR output. The owner of the internal key produces a single Schnorr signature for the tweaked output key Q. The witness contains exactly one element: a 64-byte signature (using the implicit SIGHASH_DEFAULT) or a 65-byte signature (with an explicit sighash type byte appended).

On-chain, a key-path spend is indistinguishable from a simple single-signature payment. There is no indication that a script tree existed, how many alternative spending paths were available, or how many parties were involved. When combined with key aggregation protocols like MuSig2, even a 5-of-7 multisig can produce a single aggregated key and signature, appearing identical to a solo spender.

// Key-path witness structure
witness: [schnorr_signature]

// Signature is 64 bytes (SIGHASH_DEFAULT)
// or 65 bytes (64-byte sig + 1-byte sighash type)

Script-Path Spending

When cooperative key-path spending is not possible, the spender can reveal and execute one script from the committed Merkle tree. The witness stack for a script-path spend contains three parts (bottom to top):

1. The inputs that satisfy the script (stack elements consumed during execution)
2. The leaf script being executed
3. A control block proving the script was committed in the output key

The control block is 33 + 32m bytes, where m is the number of Merkle path hashes (from 0 to a maximum depth of 128):

// Control block structure
byte 0:    (leaf_version & 0xfe) | output_key_parity_bit
bytes 1-32:  internal public key P (32-byte x-only)
bytes 33+:   Merkle path hashes (m * 32 bytes)

During validation, the verifier reconstructs the Merkle root from the leaf script and the path hashes, computes the expected output key using the internal key and tweak, and checks that it matches the actual output key. If valid, the leaf script is executed under the rules defined by its leaf version. For leaf version 0xc0, BIP-342 Tapscript rules apply.

The Merkle Script Tree

BIP-341 organizes spending conditions into a binary Merkle tree where each leaf contains a script and a leaf version byte. The tree is built by hashing pairs of nodes using lexicographic ordering:

leaf_hash = hashTapLeaf(leaf_version || compact_size(script) || script)

branch_hash = hashTapBranch(sort(left, right))
// The smaller hash is placed first, eliminating the need
// for left/right direction bits in the Merkle path

This design allows placing the most likely script paths near the root, reducing the Merkle proof size for common spending scenarios. Rarely used fallback conditions can be buried deeper in the tree with minimal cost to the common case.

Privacy Benefits

BIP-341 delivers significant privacy improvements over previous output types. The design minimizes how much information about spending conditions is revealed on-chain:

• Key-path spends reveal nothing about script conditions. A cooperative 2-of-3 multisig settlement looks identical to a simple wallet transfer.
• Script-path spends reveal only the executed leaf plus the Merkle path hashes. All other scripts in the tree remain hidden.
• All P2TR outputs look the same regardless of their underlying complexity. Unlike legacy scripts where P2PKH, P2SH, and multisig outputs have distinct fingerprints, every Taproot output is a uniform 34-byte scriptPubKey.

For a deeper technical analysis of these privacy properties, see the research article on Taproot and Schnorr signatures.

Technical Parameters

Use Cases

Efficient Multisig

Before Taproot, a 3-of-5 multisig required revealing all five public keys and three signatures on-chain, consuming significant block space and identifying the transaction as multisig. With BIP-341 and MuSig2 key aggregation, the same 3-of-5 setup can be collapsed into a single aggregated key. The cooperative case produces one 64-byte signature, indistinguishable from any other payment. The script path serves as a fallback if some signers become unresponsive.

Lightning Network Channels

Lightning channels benefit from Taproot in multiple ways. Cooperative channel closes use the key-path for a single-signature close that looks like an ordinary transfer. Complex HTLC scripts and timelock conditions are pushed into the script tree, only revealed during force closes. This improves both the privacy and the on-chain efficiency of the Lightning Network.

Advanced Contracts

BIP-341 enables richer smart contract constructions on Bitcoin. Miniscript policies, covenants, threshold signatures, and time-locked inheritance schemes can all be encoded in the Merkle tree while maintaining a clean key-path for the common case. Protocols like Discreet Log Contracts and Ark leverage Taproot to keep contract complexity off-chain.

Layer 2 Protocols

Layer 2 solutions like Spark use Taproot outputs for their on-chain commitments. The ability to encode complex exit conditions in a script tree while keeping cooperative operations as simple key-path spends makes Taproot ideal for scaling protocols that need both efficiency and trustless fallback guarantees.

The Annex Field

BIP-341 reserves an optional witness element called the annex, identified by its first byte being 0x50. When present, the annex is committed in the signature hash (preventing malleability) but is otherwise ignored during validation. It is reserved for future soft fork extensions that may need to attach additional data to transactions.

The specification recommends that users should not include an annex until a future upgrade defines its semantics, since doing so could result in fund loss if consensus rules change.

Risks and Considerations

Adoption and Wallet Support

While Taproot activated in November 2021, adoption has been gradual. Wallets and services must update to support P2TR address generation, signing, and spending. Sending to bc1p addresses requires bech32m encoding support, which not all platforms implemented immediately. Users should verify that their wallet and any receiving services support Taproot before migrating funds to P2TR outputs.

Script-Path Privacy Leakage

While key-path spends offer strong privacy, script-path spends do reveal information. The executed script and the depth of the Merkle tree are visible on-chain. The tree depth can leak information about the wallet software or the number of spending conditions, partially reducing the privacy benefits.

NUMS Point Complexity

When a P2TR output should only be spendable via the script path (no key-path), the internal key must be set to a Nothing Up My Sleeve (NUMS) point with no known private key. Constructing and verifying NUMS points correctly requires care. Using the wrong internal key could either make the output unspendable or allow unauthorized key-path spending.

Backwards Compatibility

BIP-341 was deployed as a soft fork, meaning older nodes still validate blocks containing Taproot transactions. However, older nodes treat SegWit version 1 outputs as "anyone-can-spend," relying on miners to enforce the new rules. This follows the standard Bitcoin soft fork security model that previous upgrades like SegWit also used.

BIP-341 and Related Proposals

BIP-341 sits at the center of the Taproot upgrade trio. Understanding its role requires seeing how it connects to the other two:

• BIP-340 defines the Schnorr signature algorithm, x-only 32-byte public keys, and the tagged hash primitive. BIP-341 uses all three for key-path verification and the Merkle tree commitment scheme.
• BIP-342 defines Tapscript, the updated Bitcoin Script dialect used inside Taproot script leaves (leaf version 0xc0). It replaces legacy opcodes like OP_CHECKMULTISIG with OP_CHECKSIGADD and enables batch signature validation.

Together, these proposals deliver smaller transactions, stronger privacy, and more expressive scripting for Bitcoin. For a comprehensive overview, see the research article on Bitcoin address types from P2PKH to Taproot.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.