Taproot

Overview

Taproot is defined primarily by BIP 341 together with related Schnorr-signature and script rules. A Taproot output commits to an internal public key and can optionally commit to a tree of alternative scripts. Spending can use the key path or reveal one selected script path.

Key-path spending can make a cooperative multisignature or complex policy appear like a simple single-key spend on-chain. Script-path spending reveals only the executed script and the proof connecting it to the commitment, not every unused condition. This can reduce transaction size and limit unnecessary information disclosure.

Taproot uses witness version 1 and therefore requires Bech32m address encoding. An application that supports only original Bech32 version 0 addresses may reject a valid Taproot destination. Compatibility must include address validation, signing, fee estimation, and transaction monitoring.

The upgrade does not make Bitcoin transactions anonymous or automatically cheaper. Benefits depend on wallet design, spending path, signature aggregation, and user behavior. Publishing a script path can still reveal conditions, and address reuse can link activity.

For payment systems, Taproot is primarily an address and transaction compatibility requirement. Operators should use maintained Bitcoin libraries, recognize the `bc1p`-style mainnet form, calculate Virtual Byte (vByte) size correctly, and avoid converting the destination into a legacy format.

Output descriptors and hardware-wallet support are important for operational adoption. A treasury may receive to a Taproot address successfully but still be unable to construct or approve the intended spending path if backups, policies, or signing devices do not understand the descriptor and script tree.