OP_0
OP_PUSHBYTES_32
0f0c8db753acbd17343a39c2f3f4e35e4be6da749f9e35137ab220e7b238a667
P2TR
Pay To Taproot
BIP 341: Taproot: SegWit version 1 spending rules
P2TR (Pay To Taproot) is a locking script that locks an output to a public key and multiple optional custom locking scripts*.
It's effectively a hybrid of the P2WPKH and P2WSH locking scripts, but the actual lock itself is small and contains a single public key (thanks to some clever mathematics and cryptography).
On this page I'll give an overview of what P2TR locking scripts look like.
P2TR was introduced as part of the Taproot upgrade.
*The custom locking scripts use a variant of script called tapscript.
Usage
How does P2TR work?
The technical details of a P2TR are a little complex, so I'll just show you the structure of the ScriptPubKey and Witness so that you can see what they look like and get an idea of how they work.
Check out the Taproot page for a complete guide on how to construct and spend a P2TR.
ScriptPubKey
51200f0c8db753acbd17343a39c2f3f4e35e4be6da749f9e35137ab220e7b238a667
Transaction: a7115c7267dbb4aab62b37818d431b784fe731f4d2f9fa0939a9980d581690ec (Output 0)
A P2TR locking script starts with the version opcode OP_1
followed by the data push of a public key.
However, this public key is a little "different" for two reasons:
- It's a tweaked public key. This is like any other normal public key, but it has been tweaked to include a commitment to all the additional custom scripts you'd like to use to be able to unlock the P2TR output. This tweak value is basically the hash of all the custom scripts, and you use this tweak on an initial public key to create the tweaked public key.
- Public keys in P2TR are only 32 bytes in length. So they're slightly shorter than the 33 byte compressed public keys found in older locking scripts (e.g. P2PK). This is because they do not include the leading byte (i.e. 0x02 or 0x03) indicating whether the y coordinate is even or odd. So it's the same as a standard compressed public key, but without the first byte.
But as I say, even though this is referred to as a tweaked public key, it looks and behaves like any other public key.
The tweaked public key is referred to as the taproot, hence the name Pay To Taproot.
- The
OP_1
version opcode indicates that this is a P2TR locking script (P2WPKH and P2WSH start withOP_0
). - A P2TR locking script contains a raw public key as opposed to a public key hash (as found in P2PKH and P2WPKH).
See Taproot P2TR construction for details.
ScriptSig
A P2TR output is not unlocked via the ScriptSig field.
It is unlocked via the Witness field instead.
Witness
This is the interesting part.
A P2TR output can be unlocked in two ways, and the structure of the witness field varies depending on which method you choose to use.
1. Key Path Spend
Default method
b693a0797b24bae12ed0516a2f5ba765618dca89b75e498ba5b745b71644362298a45ca39230d10a02ee6290a91cebf9839600f7e35158a447ea182ea0e022ae01
{ "stackitems": "01", "0": { "size": "41", "item": "b693a0797b24bae12ed0516a2f5ba765618dca89b75e498ba5b745b71644362298a45ca39230d10a02ee6290a91cebf9839600f7e35158a447" }, }
0141b693a0797b24bae12ed0516a2f5ba765618dca89b75e498ba5b745b71644362298a45ca39230d10a02ee6290a91cebf9839600f7e35158a447ea182ea0e022ae01
Transaction: 091d2aaadc409298fd8353a4cd94c319481a0b4623fb00872fe240448e93fcbe (Input 0)
In a key path spend, the witness just contains a single signature item.
This signature is created by first tweaking the private key used to create the initial public key.
If the signature corresponds to the tweaked public key in the ScriptPubKey, the output is unlocked and can be spent.
- P2TR uses Schnorr signatures instead of ECDSA.
- Signatures in P2TR are also slightly shorter due to not using DER encoding.
- The hash type byte at the end of the signature is optional.
See Taproot key path spend for details.
2. Script Path Spend
Alternative method(s)
01769105cbcbdcaaee5e58cd201ba3152477fda31410df8b91b4aee2c4864c7700615efb425e002f146a39ca0a4f2924566762d9213bd33f825fad83977fba7f01 206d4ddc0e47d2e8f82cbe2fc2d0d749e7bd3338112cecdc76d8f831ae6620dbe0ac c0924c163b385af7093440184af6fd6244936d1288cbb41cc3812286d3f83a3329
{ "stackitems": "03", "0": { "size": "41", "item": "01769105cbcbdcaaee5e58cd201ba3152477fda31410df8b91b4aee2c4864c7700615efb425e002f146a39ca0a4f2924566762d9213bd33f825fad83977fba7f01" }, "1": { "size": "22", "item": "206d4ddc0e47d2e8f82cbe2fc2d0d749e7bd3338112cecdc76d8f831ae6620dbe0ac" }, "2": { "size": "21", "item": "c0924c163b385af7093440184af6fd6244936d1288cbb41cc3812286d3f83a3329" } }
034101769105cbcbdcaaee5e58cd201ba3152477fda31410df8b91b4aee2c4864c7700615efb425e002f146a39ca0a4f2924566762d9213bd33f825fad83977fba7f0122206d4ddc0e47d2e8f82cbe2fc2d0d749e7bd3338112cecdc76d8f831ae6620dbe0ac21c0924c163b385af7093440184af6fd6244936d1288cbb41cc3812286d3f83a3329
Transaction: 797505b104b5fb840931c115ea35d445eb1f64c9279bf23aa5bb4c3d779da0c2 (Input 0)
A script path spend is where you spend the P2TR output using one of the custom locking scripts encoded in to the tweaked public key.
This witness is obviously a little more complex than in a key path spend. Nonetheless, it can be broken down in to 3 parts:
- Script Inputs — The first item(s) in the witness are the data elements required to unlock the custom script.
- Leaf Script — The second-to-last item in the witness is your chosen custom locking script. This is one of the custom scripts you used when constructing the tweaked public key.
- Control Block — The last item in the witness contains the data that proves the custom script you're using was one of the original scripts used to create the tweaked public key.
So in a script path spend, the witness usually contains 3 or more items. There will always be at least 2 items (the leaf script and control block), and then you can have multiple script inputs at the start (e.g. a signature).
If the data in the control block confirms that the leaf script was encoded in to the tweaked public key, and the script inputs satisfy the conditions of the leaf script, the output is unlocked and can be spent.
See script path spend execution for details.
- The fact that a script path spend contains more than 1 item is what differentiates it from a key path spend.
- The witness for a script path spend looks similar to the witness for a P2WSH, except it includes an additional control block at the end.
See Taproot script path spend for details.
Execution
As you'd expect, the execution of the ScriptPubKey + witness for a P2TR is different to the execution of other scripts in Bitcoin.
The method of execution varies depending on how many items are in the witness.
Here's an overview of the steps:
- The first step is to always remove the optional annex from the witness.
A. Key Path Spend
If there is only 1 item left in the witness, key path spend execution is used.
- Check that the item in the witness is a valid signature for the tweaked public key in the ScriptPubKey.
B. Script Path Spend
If there are 2 or more items left in the witness, script path spend execution is used.
- Check that the leaf script was in fact encoded in to the tweaked public key in the ScriptPubKey. This is performed using the data in the control block.
Details
Here's are some more detailed steps on how the tweaked public key is calculated from the witness data.
This probably won't make too much sense unless you're already familiar with the construction of a P2TR, but I thought I'd cover the steps in more detail here anyway.
- Calculate leaf hash. The first step is to calculate the leaf hash. This is calculated using the leaf script and the leaf version (which is encoded in to the first byte of the control block).
- Calculate merkle root. Next, use the leaf hash from the previous step along with the merkle path in the control block to calculate the merkle root.
- Calculate tweak. The tweak is calculated by hashing the merkle root from the previous step along with the initial public key provided in the control block.
- Calculate tweaked public key. Next, you use the tweak from the previous step to calculate the tweaked public key. This is calculated by first creating a new point by multiplying the generator point by the tweak, then adding this point to the initial public key (converted to a point) inside the control block.
- Check tweaked public key. Check that the tweaked public key we just calculated matches the tweaked public key in the ScriptPubKey. If it matches, this confirms that the leaf script being used was encoded in to the original tweaked public key.
- Execute the leaf script along with the script inputs provided in the witness. If this script is valid, the output is unlocked can be spent.
The bulk of the script path spend execution involves using the control block to confirm that the given leaf script was in fact encoded in to the tweaked public key.
After that, you just execute the script inputs + leaf script (just like you would in a standard P2WSH).
Each leaf script uses tapscript, which is a slight variation of standard script.
Benefits
There are three main benefits to using P2TR over other locking scripts:
- Flexibility. P2TR allows you to lock an output to a simple public key and/or multiple custom locking scripts. This means that the output can be locked using multiple spending conditions. You typically use one of the additional scripts if the "default" method of unlocking via the public key is not preferred (for whatever reason).
- Privacy. If you spend the output via the default public key, any additional spending conditions are not revealed (in fact, you wouldn't even know if there were any). Furthermore, if you unlock the output using one of the additional custom scripts, the other scripts in the tree will not be revealed.
- Efficiency.
- All of the spending conditions for a P2TR output can be condensed down in to a single 32-byte tweaked public key, which saves on space compared to having multiple custom locking scripts placed directly on an output.
- P2TR outputs use Schnorr signatures instead of ECDSA, which means that any signatures required for unlocking the output can be added together. As a result, this makes it far more efficient to use P2TR for multisignature locking scripts compared to other options such as P2MS, P2SH, or P2WSH (all of which use ECDSA).
However, if you just want to lock an output to a public key without any additional spending conditions, it's perfectly fine to stick with the simpler P2WPKH.
Similarly, if you just want to use a single custom locking script (instead of having multiple to choose from), it's perfectly fine to stick with the simpler P2WSH.
But there's nothing wrong with using P2TR for these simple kinds of locks if you prefer.
Address
A P2TR locking script has been given its own address format.
It can be converted to an address by encoding the entire ScriptPubKey in to bech32m.
A P2TR address always starts with bc1p and is 62 characters in length.
The address for a P2TR is encoded using bech32m instead of bech32. It's basically the same as bech32, but with a slight change to the way the checksum is calculated.
History
P2TR was added to Bitcoin in 2021 as part of the Taproot upgrade.
It combines the functionality of previously proposed MAST and Schnorr signature upgrades in to one single locking mechanism, which is why it was introduced as part of one major soft fork upgrade to the software.
Summary
P2TR is like an "all in one" locking mechanism that provides the same functionality of all previous locking scripts combined. The inclusion of Schnorr signatures is a nice bonus.
So if you could only ever use one type of locking script in Bitcoin from here on out, you'd choose P2TR.
Of course, all of this functionality means that it's naturally more complex to construct and spend than the simpler P2WPKH and P2WSH locking mechanisms. However, once you've got the hang of it you'll find that it's an extremely versatile locking script.
So it's worth learning how to use it.