BIP341 - Taproot: SegWit Version 1 Spending Rules¶

BIP341 (Bitcoin Improvement Proposal 341) is one of the Bitcoin improvement proposals, put forward by Pieter Wuille, Jonas Nick, Anthony Towns, and Tim Ruffing in 2020. It defines the core spending rules of Taproot. Taproot is a major upgrade to the Bitcoin protocol, combining Schnorr signatures (BIP340) and Tapscript (BIP342) to bring stronger privacy, higher efficiency, and more flexible smart contract capabilities to Bitcoin.

Core Concept¶

The core idea of Taproot is to make complex smart contracts appear indistinguishable from simple single-signature payments on-chain. Through MAST (Merklized Alternative Script Tree) and the key aggregation properties of Schnorr signatures, Taproot allows advanced features such as multisignature and complex script conditions to be hidden behind what appears to be an ordinary public key.

Taproot introduces SegWit version 1 (witness v1), using a 32-byte public key (rather than a public key hash) as the output. Addresses start with bc1p (bech32m encoding). This design brings revolutionary improvements to Bitcoin's privacy and scalability.

Key Features¶

1. Key Path Spending¶

Taproot outputs can be spent directly with a single Schnorr signature:

Output script: OP_1 <32-byte public key>
Witness data: <64-byte Schnorr signature>

Key Advantages: - Multisignature through key aggregation (MuSig2) becomes a single public key - N-of-N multisig is completely identical to single-sig on-chain - Cannot be externally distinguished as single-sig, multisig, or complex script - Significantly enhances privacy

2. Script Path Spending¶

When spending via the key path is not possible, a pre-committed script can be revealed and executed:

Witness data:
  <script input data>
  <script>
  <control block>

The control block contains: - Output public key parity (1 byte) - Internal public key (32 bytes) - Merkle proof path (32 bytes x path length)

3. MAST (Merklized Alternative Script Tree)¶

Taproot uses MAST to organize multiple script branches:

                    Taproot Output Public Key
                           |
                    +------+------+
              Internal Key     Merkle Root
                              |
                       +------+------+
                   Hash AB         Hash CD
                    |                 |
                 +--+--+           +--+--+
              Script A  Script B  Script C  Script D

Advantages: - Only the executed script branch needs to be revealed - Unused branches remain private - Saves block space - Reduces fees

4. Taptweak (Adjustment Mechanism)¶

The Taproot output public key is a combination of the internal public key and the Merkle root:

P = Q + hash(Q || merkle_root) x G

Where:
- P: Taproot output public key (visible on-chain)
- Q: Internal public key (revealed only during script path spending)
- merkle_root: Merkle root of the script tree
- G: Elliptic curve generator point

This adjustment means: - Key path spending only requires signing for P - Script path spending requires revealing Q and the Merkle proof

5. Schnorr Signature Integration¶

Taproot fully adopts BIP340 Schnorr signatures: - 64-byte fixed-size signatures - Supports key aggregation (MuSig2) - Batch verification speedup - Linear property facilitates future extensions

Technical Details¶

Taproot Output Format¶

Output script: OP_1 <32-byte Taproot output public key>

Version number 1 indicates this is SegWit v1 (Taproot)

Key Path Spending Verification¶

1. Parse witness data as a single 64-byte signature
2. Verify the signature using BIP340
3. The public key is the 32-byte data in the output script
4. The signature message is the transaction signature hash (defined by BIP341)

Script Path Spending Verification¶

1. Parse witness data:

   Last element: control block
   Second to last element: the script to execute
   Remaining elements: script input data (stack elements)
   

2. Verify the control block:

3. First byte: leaf version + output public key parity
4. Next 32 bytes: internal public key Q

5. Remaining bytes: Merkle proof path (32 bytes per node)

6. Compute leaf hash:

   leaf_hash = tagged_hash("TapLeaf", leaf_version || script_length || script)
   

7. Verify the Merkle path:

   Starting from leaf_hash, use the proof nodes from the control block
   to compute up to the Merkle root
   

8. Reconstruct the Taproot output public key:

   P' = Q + tagged_hash("TapTweak", Q || merkle_root) x G
   

9. Verify P' matches the output public key

10. Execute script verification

Signature Hash Algorithm¶

BIP341 defines a new signature hash algorithm (based on BIP143):

Signature hash = SHA256(SHA256(
  epoch (0x00)
  hash_type (1 byte)
  nVersion (4 bytes)
  nLockTime (4 bytes)
  hashPrevouts (32 bytes)
  hashAmounts (32 bytes)       <- New
  hashScriptPubKeys (32 bytes) <- New
  hashSequences (32 bytes)
  hashOutputs (32 bytes)
  spend_type (1 byte)          <- New
  [If script path spending:
    tapleaf_hash (32 bytes)
    key_version (1 byte)
    codesep_pos (4 bytes)
  ]
  [Input index-related data]
))

Improvements: - Commits to all input amounts (hashAmounts) - Commits to all input script public keys (hashScriptPubKeys) - Distinguishes between key path and script path spending (spend_type) - Supports OP_CODESEPARATOR position tracking

Tagged Hash¶

Taproot uses tagged hashes to prevent cross-protocol attacks:

def tagged_hash(tag, data):
    tag_hash = SHA256(tag.encode())
    return SHA256(tag_hash + tag_hash + data)

Common tags: - TapLeaf: Computes script leaf hashes - TapBranch: Computes Merkle branch nodes - TapTweak: Computes the taptweak value - TapSighash: Computes the signature hash (Taproot-specific)

Technical Advantages¶

Privacy Enhancement¶

• Script privacy: Unused script branches are never revealed
• Multisig privacy: N-of-N multisig is indistinguishable from single-sig
• Contract privacy: Complex conditions are completely hidden in key path spending
• Statistical privacy: Higher Taproot usage means a larger anonymity set

Example:

Lightning Network channel close:
- Cooperative close: Uses key path, looks like a regular payment
- Unilateral close: Uses script path, reveals the necessary script
- External observers cannot know in advance that this is a Lightning channel

Space Efficiency¶

• Key path spending: Only 64 bytes of signature (compared to multisig saves significant space)
• Script path spending: Only the executed branch is revealed (unexecuted branches occupy just 32-byte hashes)
• Batch operations: Schnorr signatures support future signature aggregation

Comparison:

2-of-3 multisig:
- Traditional P2SH: ~254 bytes witness data
- Taproot (key path): 64 bytes witness data
- Savings: ~75%

Flexibility Improvements¶

• Arbitrary complex script trees: Supports hundreds of script branches
• Mixed strategies: Key path for common cases, script path for special cases
• Future compatible: Reserved script version space (leaf versions 0xc0-0xfe)
• No oracle needed: Some scenarios can replace oracles with key aggregation

Performance Optimization¶

• Batch verification: Schnorr signatures support batch verification
• Reduced data: Smaller witness data reduces bandwidth requirements
• Faster verification: Optimized signature hash algorithm

Practical Applications¶

Multisignature Wallets¶

Scriptless multisig using MuSig2:

2-of-2 wallet (e.g., custody service):
1. Both parties generate their public keys: P1, P2
2. Aggregate into a joint public key: P = P1 + P2 (simplified)
3. Create Taproot output: OP_1 <P>
4. To spend: Both parties cooperatively generate a single Schnorr signature
5. Witness data: only 64-byte signature

On-chain, it is impossible to tell this is multisig versus single-sig!

Lightning Network¶

Lightning channels using Taproot:

Channel funding output:
- Internal public key: Joint public key of both parties (cooperative close path)
- Script tree:
  +-- Timeout refund script (Alice's path)
  +-- Timeout refund script (Bob's path)

Cooperative close: Uses key path, completely private
Unilateral close: Reveals the corresponding timeout script

Complex Smart Contracts¶

Using MAST to organize multiple conditions:

Inheritance planning contract:
- Internal public key: Holder's public key (normal usage)
- Script tree:
  +-- Heir 1 (available after 1 year)
  +-- Heir 2 (available after 1 year)
  +-- Heir 1 + 2 multisig (available after 6 months)
  +-- Emergency recovery path (requires notary signature)

Holder's normal spending: Only key path signature
Inheritance scenario: Only the relevant script branch is revealed

Atomic Swaps¶

Cross-chain atomic swaps using adapter signatures:

Alice (BTC) <-> Bob (LTC)

BTC side: Taproot output
- Key path: Alice + Bob joint signature (successful swap)
- Script path:
  +-- Alice hash lock + time lock (refund)
  +-- Bob hash lock (claim)

Successful swaps use the key path; scripts are only revealed on failure

Relationship with Other BIPs¶

BIP340 (Schnorr Signatures)¶

The signature foundation for Taproot: - Key path spending uses BIP340 signatures - OP_CHECKSIG in script path also uses Schnorr - Key aggregation enables multisig privacy

BIP342 (Tapscript)¶

Script language used in script path: - Defines execution rules for Taproot scripts - Added new opcodes like OP_CHECKSIGADD - Removes signature operation count limits - Optimizes script verification

BIP350 (Bech32m)¶

Taproot address encoding format: - Uses the improved Bech32m encoding - Addresses start with bc1p (mainnet) - Fixes the length extension weakness of the original Bech32

BIP32 (HD Wallets)¶

Key derivation compatibility: - BIP86 defines the standard derivation path for Taproot: m/86'/0'/0'/0/0 - Can use the existing HD wallet architecture - Backward compatible with BIP44/49/84

Activation and Deployment¶

Speedy Trial Activation¶

Taproot was activated in November 2021: - Activation mechanism: BIP8 + Speedy Trial (a fast variant of BIP9) - Signaling period: May - August 2021 - Lock-in block: 709,632 (June 12, 2021) - Activation block: 709,632 (November 14, 2021) - Miner support: Over 90% signaling support

Compatibility¶

Backward Compatible (soft fork): - Old nodes treat Taproot outputs as "anyone-can-spend" - Old nodes can still validate blocks - No chain split occurs

Forward Compatible: - New nodes fully verify Taproot rules - Invalid Taproot spending is rejected - Consensus consistency is maintained

Adoption Status¶

Wallet Support: - Hardware wallets: Ledger, Trezor, Coldcard (firmware update required) - Software wallets: Bitcoin Core, Sparrow, BlueWallet, Muun - Libraries and tools: libsecp256k1, btcd, rust-bitcoin

Exchange Support: - Major exchanges gradually supporting Taproot deposits and withdrawals - Batch payments beginning to adopt Taproot to save fees

Network Statistics (as of 2024): - Taproot output share: ~5-10% (growing) - Primary use cases: Ordinals, Lightning Network, privacy wallets

Security Considerations¶

1. Key Aggregation Security¶

Use secure protocols like MuSig2: - Prevent rogue key attacks - Each party must prove private key ownership - Use multi-round interaction for signature generation

2. Script Design¶

When designing a Taproot script tree: - Place the most likely executed paths at shallow levels - Balance tree depth and privacy needs - Consider fee differences between branches

3. Address Verification¶

Verify Taproot addresses: - Confirm the address starts with bc1p (mainnet) - Verify the length (62 characters) - Use wallet software that supports Taproot

4. Backup and Recovery¶

Taproot wallet backup: - Mnemonic phrases can recover keys - Complex script trees require additional backup of script definitions - Recording the script tree structure and parameters is recommended

5. Privacy Practices¶

Maximize privacy benefits: - Prefer key path spending - Only use script path when necessary - Avoid unnecessary script complexity - Mix transactions with other Taproot users

Comparison: Before and After Taproot¶

Practical Impact¶

Impact on Users¶

• Lower fees: Key path spending is cheaper
• Enhanced privacy: Transaction types are harder to identify
• Better multisig: Multisig wallet experience approaches single-sig
• New address format: Wallet upgrades required

Impact on Developers¶

• New tools: MuSig2, Taproot script construction libraries
• Lightning Network: More private, more efficient channels
• Smart contracts: More complex on-chain logic becomes possible
• Privacy technology: New privacy protection schemes (e.g., Silent Payments)

Impact on the Network¶

• Capacity increase: Smaller witness data = more transactions
• Verification optimization: Schnorr batch verification accelerates block verification
• Privacy improvement: Overall network privacy level increases
• Innovation foundation: Reserves space for future protocol upgrades

Future Development¶

Cross-Input Signature Aggregation¶

Potential future upgrade: - All inputs in a transaction share a single signature - Further reduces transaction size - Requires new protocol design

FROST Threshold Signatures¶

Schnorr-based threshold scheme: - Implements M-of-N multisig without revealing the threshold - Still looks like single-sig on-chain - Improves security for enterprises and DAOs

Cross-Chain Atomic Swaps¶

Taproot provides a better foundation for cross-chain transactions: - Adapter Signatures - Scriptless conditional payments - More private cross-chain operations

Taproot Assets¶

Asset issuance protocol based on Taproot: - Issue tokens and NFTs on Bitcoin - Leverages Taproot's privacy features - Reduces on-chain footprint

Silent Payments¶

Leveraging Taproot: - Reusable payment codes - Recipient generates unique addresses - Completely private, no address reuse

Summary¶

BIP341, through the introduction of Taproot, brought Bitcoin its most important protocol upgrade since SegWit:

Core Achievements: - Privacy revolution: Complex transactions can be hidden as simple payments - Efficiency improvement: Smaller witness data, lower fees - Flexibility: MAST supports arbitrarily complex script logic - Future compatibility: Paves the way for advanced features like signature aggregation

Practical Value: - Multisignature privacy improved by 100% (completely indistinguishable) - Witness data reduced by 75% (key path spending) - Script privacy: Unexecuted branches are never revealed - Opens new possibilities for Bitcoin's long-term development

Historical Significance: - The result of years of effort by the Bitcoin community - Demonstrates Bitcoin's capacity for continuous innovation - Introduces major improvements while maintaining decentralization and security - Lays the foundation for the next generation of Bitcoin applications

Taproot is not just a technical upgrade; it is a milestone in Bitcoin's evolution toward greater privacy, efficiency, and flexibility. As the ecosystem gradually adopts it, Taproot's true potential will be progressively realized in the coming years, bringing fundamental improvements to Bitcoin's privacy, scalability, and smart contract capabilities.