P2TR (Pay-to-Taproot)

What Is P2TR (Pay-to-Taproot)?

P2TR (Pay-to-Taproot) is a Bitcoin output type defined in BIP 341 that locks funds to a tweaked public key. Unlike older address formats such as P2PKH or P2SH, P2TR encodes all possible spending conditions into a single 32-byte key that appears on-chain. The spender can then unlock funds via a direct signature (key-path) or by revealing a specific script from a committed Merkle tree (script-path).

Taproot activated at block height 709,632 in November 2021, representing the culmination of three interrelated proposals: BIP 340 (Schnorr signatures for secp256k1), BIP 341 (Taproot spending rules), and BIP 342 (Tapscript validation). Together, these upgrades introduced SegWit version 1, giving Bitcoin a more efficient and private transaction format.

For a broader comparison of how P2TR fits alongside legacy and SegWit address types, see the Bitcoin address types guide.

How It Works

Every P2TR output commits to a tweaked public key Q. The on-chain scriptPubKey is always the same structure:

OP_1 <32-byte tweaked_public_key>

The tweaked key is computed as Q = P + hash(P || m) * G, where P is the internal public key, m is the Merkle root of any committed scripts (empty if there are none), and G is the secp256k1 generator point. This tweak binds the internal key to the script tree without revealing either on-chain.

Key-Path Spending

The key-path is the default and most efficient way to spend a P2TR output. The signer tweaks their private key by the same tweak value and produces a single Schnorr signature. The witness contains only the 64-byte signature (or 65 bytes with an explicit sighash type).

No public key, no script, and no Merkle proof appear in the transaction. This makes key-path spends the smallest and cheapest input type in Bitcoin. It also means that a 3-of-5 multisig using MuSig2 looks identical to a single-key spend on-chain.

Script-Path Spending

When the key-path signer is unavailable or the output requires complex conditions, the spender reveals a specific leaf script from the committed Merkle tree. The witness for a script-path spend contains:

1. The inputs required by the script (signatures, preimages, etc.)
2. The leaf script being executed
3. A control block containing the internal key and the Merkle proof that links the leaf to the tweaked key Q

Only the executed branch is revealed. All other scripts in the tree remain private. This is a major improvement over P2SH, which requires revealing the entire redeem script regardless of which condition is used.

The Merkle tree supports up to 128 levels of depth, allowing a single P2TR output to commit to billions of possible spending conditions. Each leaf uses tagged hashing (TapLeaf and TapBranch domain separators) to prevent hash collisions between script data and branch nodes.

Bech32m Encoding

P2TR addresses use bech32m encoding (defined in BIP 350) rather than the original bech32 used by P2WPKH. A vulnerability in bech32 allowed inserting or deleting q characters before a trailing p without invalidating the checksum. While this did not affect SegWit v0 addresses (which have fixed lengths), it posed a risk for future witness versions.

Bech32m fixes this by using a different checksum constant (0x2bc830a3 instead of 0x01). The result is that P2TR addresses start with bc1p on mainnet and tb1p on testnet, and are always 62 characters long.

# Address format comparison
P2WPKH (SegWit v0):  bc1q...  (42 chars, bech32)
P2TR   (SegWit v1):  bc1p...  (62 chars, bech32m)

Fee Savings

P2TR key-path spends are the most fee-efficient input type available, thanks to Schnorr signatures being a fixed 64 bytes (compared to 70-72 bytes for DER-encoded ECDSA) and the elimination of the public key from the witness.

The savings are even more dramatic for multisig: a 2-of-3 MuSig2 P2TR key-path spend is approximately 57.5 vB, compared to roughly 296 vB for a legacy P2SH multisig input: an 81% reduction. For a deeper look at transaction sizing, see the transaction lifecycle guide.

One tradeoff: P2TR outputs are 43 vB compared to 31 vB for P2WPKH, because the 32-byte x-only public key is larger than the 20-byte hash used by SegWit v0. For transactions creating many outputs, this can offset some of the input savings.

Privacy Benefits

P2TR represents the largest privacy upgrade in Bitcoin's history at the protocol level. Several properties combine to make chain analysis significantly harder:

• All P2TR outputs are indistinguishable: a single-sig wallet, a multisig vault, and a complex timelocked contract all produce the same 34-byte scriptPubKey on-chain
• Key-path spends reveal nothing about the spending policy: a threshold signature aggregated via MuSig2 looks identical to a solo signer
• Unused scripts stay hidden: if a P2TR output commits to a timelock fallback, that fallback is never visible unless it is actually used
• Common heuristics used by chain analysis firms (identifying script type, counting signers, detecting multisig) become ineffective when all outputs share the same format

For more on Taproot's cryptographic foundations and how Schnorr signatures enable these properties, see the Taproot and Schnorr signatures deep dive.

Why It Matters

P2TR is not merely a more efficient encoding: it changes what is practical to build on Bitcoin. Before Taproot, complex spending conditions required revealing the full script on-chain, making them expensive and privacy-leaking. P2TR allows developers to commit to arbitrarily complex logic while keeping the common case (a simple signature) cheap and private.

This has direct implications for Layer 2 protocols. Spark, for example, benefits from Taproot's ability to represent complex cooperative and unilateral exit conditions in a single compact output. Cooperative closes look like ordinary single-key spends, revealing nothing about the underlying protocol. The Lightning Network has similarly adopted P2TR for channel funding outputs through Simple Taproot Channels, where MuSig2-based cooperative closes appear indistinguishable from regular payments.

The Ordinals protocol also relies on P2TR's script-path witness space to embed data on-chain, demonstrating the flexibility of Taproot's design beyond its original intended use cases.

Key Derivation

BIP 86 standardizes key derivation for single-key P2TR outputs. It uses the HD wallet path m/86'/0'/0', following the same structure as BIP 44 (for P2PKH) and BIP 84 (for P2WPKH) but with purpose code 86.

# BIP 86 derivation for P2TR
m / 86' / 0' / account' / change / index

# Example: first receiving address
m / 86' / 0' / 0' / 0 / 0

BIP 86 specifies that the internal key is used directly with an empty script tree (the tweak uses no Merkle root), meaning Q = P + hash(P) * G. This keeps single-key P2TR wallets simple while remaining compatible with the full Taproot spending rules.

Use Cases

• Standard wallets: single-signature wallets using BIP 86 derivation get lower fees and better privacy compared to P2WPKH
• Multisig vaults: collaborative custody setups using MuSig2 or FROST threshold signatures produce key-path spends that are indistinguishable from single-sig transactions
• Layer 2 protocols: Lightning channels, Spark, and other off-chain systems use P2TR to commit cooperative and unilateral spending paths without revealing protocol details on-chain
• Complex contracts: timelocked inheritance schemes, escrow arrangements, and covenant-like constructions can encode multiple fallback paths in the script tree, paying only for the path that is actually used
• Miniscript policies: Tapscript (BIP 342) provides a cleaner scripting environment with improved opcodes, making Miniscript-based spending policies more practical

Adoption Status

P2TR adoption has followed a non-linear trajectory. The Ordinals and inscriptions wave pushed Taproot usage to over 75% of daily transactions in mid-2024, as inscriptions embed data in the script-path witness. After that activity subsided, Taproot settled to approximately 20% of transactions by late 2025.

Wallet support is now widespread:

• Hardware wallets: Ledger (Nano S Plus, Nano X, Stax), Trezor (Model T, Safe 3), Coldcard (Mk4, Q), and BitBox02 all support P2TR natively
• Software wallets: Bitcoin Core, Sparrow Wallet, BlueWallet, and Muun all generate P2TR addresses by default or as a selectable option
• Infrastructure: BTCPay Server accepts P2TR payments, and LND supports Simple Taproot Channels for Lightning with MuSig2-based funding outputs

Risks and Considerations

Output Size Tradeoff

P2TR outputs are 12 bytes larger than P2WPKH outputs (43 vB vs. 31 vB) because the 32-byte x-only public key replaces the 20-byte hash. For wallets that primarily receive many small UTXOs, the larger output size may offset input fee savings.

Quantum Computing Considerations

P2TR exposes the public key directly in the output (as a 32-byte x-only key), unlike hash-based formats like P2PKH that add a layer of hash protection. If quantum computers capable of breaking elliptic curve cryptography become practical, P2TR outputs would be vulnerable. However, the script-path provides a potential mitigation: a quantum-resistant spending condition could be included as a script leaf. BIP 360, merged in February 2026, proposes a Pay-to-Merkle-Root format as a longer-term quantum-safe alternative.

Adoption and Compatibility

While major wallets and services support P2TR, some older platforms and exchanges still do not recognize bc1p addresses. Sending to a P2TR address from an incompatible service will fail. Users should verify that their counterparty supports bech32m before providing a Taproot address.

Script-Path Complexity

Building correct Taproot script trees requires understanding tagged hashing, key tweaking, and Merkle proof construction. Errors in tree construction can result in unspendable outputs. Tools like Miniscript and descriptor wallets help manage this complexity, but developers working with raw Tapscript should test thoroughly.

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.