P2TR

P2TR stands for pay to Taproot. It locks an output to a single 32-byte public key, called the tweaked key. That key commits to a set of optional custom scripts, but it looks like any other key on chain.

To spend, you either sign with the tweaked key, which is the key path, or reveal one of the scripts and meet its conditions, which is the script path. P2TR was added by the Taproot upgrade, which activated at block 709,632 in November 2021.

P2TR combines what earlier locks did separately. A P2WPKH lock covers one key, and a P2WSH lock covers one script. A P2TR lock can cover a key and many scripts, and the spend shows only the part that is used.

What does a P2TR lock look like?

A P2TR scriptPubKey is OP_1 followed by a 32-byte push. The push is the tweaked key itself, not a hash of it:

OP_1
OP_PUSHBYTES_32
0f0c8db753acbd17343a39c2f3f4e35e4be6da749f9e35137ab220e7b238a667

As hex, the lock is 34 bytes:

51200f0c8db753acbd17343a39c2f3f4e35e4be6da749f9e35137ab220e7b238a667

Output 0 of a7115c7267dbb4aab62b37818d431b784fe731f4d2f9fa0939a9980d581690ec carries this lock. It was confirmed in block 861,957. Its address is bc1ppuxgmd6n4j73wdp688p08a8rte97dkn5n70r2ym6kgsw0v3c5ensrytduf.

OP_1 is witness version 1. A P2WPKH lock starts with OP_0, and a P2WSH lock also starts with OP_0, but P2TR is the next version. The 32-byte push is a bare key, not a hash, so a P2TR lock carries no hash to look up.

What is the tweaked key?

The tweaked key is built from two parts:

• The internal key, a 32-byte public key, usually the owner's own key. It is an x-only key, which means only the x coordinate is stored. The y coordinate is taken to be even, as BIP 340 defines.
• The script tree root, a hash that commits to every script in the tree. If there are no scripts, there is no root.

The tweak is a hash of the internal key and the root, as BIP 341 defines. The tweaked key is the internal key, moved by that tweak along the curve. Anyone can compute it from the parts. The lock holds only the result.

This construction hides the scripts. If the output is spent by key path, nobody learns that scripts exist. If it is spent by script path, the other scripts stay hidden. Only the script used and its branch of the tree are revealed.

How can you spend a P2TR output?

The witness tells Bitcoin which path to take. First, the optional annex is removed. It is the last item, and only when the witness has two or more items and that item starts with 50. Annexes are reserved for future use, so wallets should not add one. Then the number of items decides:

• One item. This is a key path spend. The item is a Schnorr signature made with the tweaked private key.
• Two or more items. This is a script path spend. The last item is the control block, the item before it is the leaf script, and any items before those are script inputs.

What does a key path spend look like?

A key path witness has one item, a 65-byte signature. The signature is 64 bytes plus a sighash byte. The example is input 0 of 091d2aaadc409298fd8353a4cd94c319481a0b4623fb00872fe240448e93fcbe, which was confirmed in block 861,970. Its witness is:

0141b693a0797b24bae12ed0516a2f5ba765618dca89b75e498ba5b745b71644362298a45ca39230d10a02ee6290a91cebf9839600f7e35158a447ea182ea0e022ae01

The first byte, 01, is the item count. Then 41 gives the 65-byte item. Its last byte, 01, is the sighash type, SIGHASH_ALL. A Taproot signature with no sighash byte is 64 bytes, and that means SIGHASH_DEFAULT.

The signature is a Schnorr signature, not an ECDSA one. Schnorr signatures have a fixed 64-byte form, with no DER wrapping, so they are shorter. They also let several signers combine their keys into one aggregate key, using MuSig2, so a multisig can spend like a single key. The Schnorr page explains the signature itself.

What does a script path spend look like?

A script path witness has at least two items. The example below has three. It is input 0 of 797505b104b5fb840931c115ea35d445eb1f64c9279bf23aa5bb4c3d779da0c2, confirmed in block 863,508:

Item	Size	Contents	Role
0	65 bytes (41)	A Schnorr signature with a sighash byte	Script input
1	34 bytes (22)	20, a 32-byte key, then ac	Leaf script
2	33 bytes (21)	c0, then a 32-byte internal key	Control block

The leaf script says: the key must sign. The 20 is a push of 32 bytes, the key, and ac is OP_CHECKSIG. As hex, the whole witness is:

034101769105cbcbdcaaee5e58cd201ba3152477fda31410df8b91b4aee2c4864c7700615efb425e002f146a39ca0a4f2924566762d9213bd33f825fad83977fba7f0122206d4ddc0e47d2e8f82cbe2fc2d0d749e7bd3338112cecdc76d8f831ae6620dbe0ac21c0924c163b385af7093440184af6fd6244936d1288cbb41cc3812286d3f83a3329

The control block has no merkle path, since the tree has only one script. A control block is 33 bytes, plus 32 bytes for each step of the path, as BIP 341 defines. The longest path, 128 steps, makes a control block of 4,129 bytes.

How does the control block prove the script?

The control block lets Bitcoin confirm that the leaf script was committed to the lock. It does this in five steps:

1. Leaf hash. A tagged hash of the leaf version, the script length and the script. The leaf version is the first byte of the control block, with its parity bit cleared. c0 means version 0xc0, which is tapscript.
2. Merkle root. The leaf hash is combined with each hash in the path. With one leaf, the root is the leaf hash.
3. Tweak. A tagged hash of the internal key and the root.
4. Tweaked key. The internal key plus the tweak times the generator point, which is the same point the lock stores.
5. Match. The result must equal the key in the lock, and the parity bit in the control block must match its y coordinate. If both match, Bitcoin runs the leaf script with the script inputs.

What is tapscript?

Leaf scripts in P2TR use tapscript, defined in BIP 342. Tapscript is close to ordinary script, with three main changes:

• Signatures in OP_CHECKSIG are 64-byte Schnorr signatures.
• Tapscript has no OP_CHECKMULTISIG. Multisig is written with OP_CHECKSIGADD instead, which counts valid signatures one at a time.
• Some unused opcodes succeed on purpose, so a later upgrade can give them meaning without breaking old nodes.

The multisig page explains the older form that tapscript replaced.

Why use P2TR?

P2TR has three main benefits:

• Flexibility. One lock can hold several spend conditions, and the owner picks the one to use.
• Privacy. A key path spend looks like any single-key spend. Unused scripts never appear on chain.
• Efficiency. The lock is one 32-byte key whatever the number of scripts. A multisig can spend as one signature when its signers use MuSig2.

If you need only one key, P2WPKH is simpler. If you need only one script, P2WSH is simpler. P2TR is worth its extra complexity when you need several conditions, or a key path that looks ordinary.

How do you make a P2TR address?

The address is the witness program, the 32-byte tweaked key, encoded with bech32m, defined in BIP 350. Bech32m differs from bech32 in one constant of the checksum, and that difference is what marks witness version 1 and later. The address starts with bc1p and is always 62 characters long.

What is the history of P2TR?

P2TR was added in the Taproot upgrade, which combined two earlier proposals: Merkle trees of scripts, from BIP 114 (MAST), and Schnorr signatures. Taproot was one soft fork, so one upgrade covered both. It activated at block 709,632 in November 2021. The Taproot page covers the upgrade, and the Taproot word page gives a short definition.

What do real P2TR transactions look like?

• Output. Output 0 of a7115c7267dbb4aab62b37818d431b784fe731f4d2f9fa0939a9980d581690ec, confirmed in block 861,957.
• Key path spend. Input 0 of 091d2aaadc409298fd8353a4cd94c319481a0b4623fb00872fe240448e93fcbe, confirmed in block 861,970.
• Script path spend. Input 0 of 797505b104b5fb840931c115ea35d445eb1f64c9279bf23aa5bb4c3d779da0c2, confirmed in block 863,508.

Compare the key path and the script path spends. Both pay to the same kind of lock, and the chain shows only what the spender chose to reveal.