<p>From <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules" rel="nofollow noreferrer">BIP341</a>:</p>
<blockquote>
<p>A Taproot output is a native SegWit output (see BIP141) with version
number 1, and a 32-byte witness program. [...]</p>
<ul>
<li>Let <em>q</em> be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents a public key
according to BIP340.</li>
<li>Fail if the witness stack has 0 elements.</li>
<li>If there are at least two witness elements, and the first byte of the last element is 0x50, this last element is called <em>annex a</em>
and is removed from the witness stack. The annex (or the lack of
thereof) is always covered by the signature and contributes to
transaction weight, but is otherwise ignored during taproot
validation.</li>
<li>If there is exactly one element left in the witness stack, key path spending is used:
<ul>
<li>The single witness stack element is interpreted as the signature and must be valid (see the next section) for the public key
<em>q</em> (see the next subsection).</li>
</ul>
</li>
<li>If there are at least two witness elements left, script path spending is used:
<ul>
<li>Call the second-to-last stack element <em>s</em>, the script.</li>
</ul>
</li>
</ul>
</blockquote>
<p>In other words, Taproot key path spends only have one<sup>1</sup> witness item, the signature. Script path spends always have at least two witness items, and usually more to provide an initial stack for the script execution.</p>
<p>Since BIP340 signatures don't allow public key recovery, you can't compute the public key (and therefore address) from the signature alone in a key path spend. In a script path spend, you could combine the revealed internal key with the root of the script to get the public key.</p>
<p>However, getting the output script of the output being spent is as simple as looking up the transaction output referenced by the txid and index in the input, so there's rarely a reason to use a method that only works for some output scripts, and requires you to know the output type (P2TR in this case) in the first place.</p>
<hr>
<p><sup>1</sup> Assuming the annex is not present.</p>

CC BY-SA 4.0
2023-04-27T21:40:30.760Z
Thank you, so the only workaround to compute the address is to lookup the blockchain again for prev out?
Sina Sharifzade
CC BY-SA 4.0
2023-04-27T21:50:11.517Z
I wouldn't even call that a workaround, that's just how it's normally done. Of course this all depends on what exactly you're doing, maybe you're storing the previous outputs with the transaction itself, but you definitely had to look them up at least once.
Vojtěch Strnad
CC BY-SA 4.0
2023-04-27T21:51:12.607Z
We pay for those blockchain requests, I just wanted to reduce the number of requests.
It is possible to compute an address in other scripts, but it seems this is not the case for p2tr.
Sina Sharifzade
CC BY-SA 4.0
2023-04-27T22:08:17.107Z
Even for those other scripts, you need to know what type of script you're looking at to compute the address. A witness stack with two items could be a P2WPKH, or it could be something else. I'd recommend considering a solution that doesn't require paying for API requests – this would usually involve running your own node.
Vojtěch Strnad
CC BY-SA 4.0
2023-12-04T21:43:20.307Z
if you can't recover the public key from a p2tr, then how can the network verify the signature included in the witness?
David 天宇 Wong
CC BY-SA 4.0
2023-12-04T21:46:25.927Z
ah, IIUC the signature will be for the tweaked key always, so you don't need to retrieve any internal pubkey, you can use the tweaked pubkey to verify a signature
David 天宇 Wong
CC BY-SA 4.0
2023-04-27T21:31:43.943Z
2023-04-27T21:31:43.943Z
Vojtěch Strnad
<p>Can you please tell me what is inside the Taproot Witness data?</p>
<p>For P2WPKH, it is defined in BIP-0141 and we have: <code>&lt;signature&gt; &lt;pubkey&gt;</code></p>
<p>But for Taproot, I can't find anything similar. Per exploring the raw transaction data, it seems we only have <code>&lt;signature&gt;</code>.</p>
<p>If I am correct, how can I extract the public key, or sender address from an input which spends a P2TR output?</p>

CC BY-SA 4.0
2023-04-27T20:15:18.347Z
Hi Sina, "witness program" refers to the byte vector in an output (such as the public key hash in P2WPKH). You probably mean "witness stack" or "input witness", is this correct?
Vojtěch Strnad
CC BY-SA 4.0
2023-04-27T20:18:32.693Z
You are probably right. according to BIP-0141, it seems it is called `witness fields` or `witness data`.
Sina Sharifzade
CC BY-SA 4.0
2023-05-01T14:05:05.883Z
Note that there is no such thing as a “sender address”. It is not necessarily a given that the sender has control of the address that input funds were received to. E.g. if the sender uses a custodial service, the address may be associated with another user, or if the transaction was created by multiple users, the inputs may have been owned by various users.
Murch
<segregated-witness><taproot><p2tr>
How can I find the public key corresponding to a P2TR input?
Sina Sharifzade
# How can I find the public key corresponding to a P2TR input?

(Asked by: username_0 on 2023-04-27)

Can you please tell me what is inside the Taproot Witness data?

For P2WPKH, it is defined in BIP-0141 and we have: `<signature> <pubkey>`

But for Taproot, I can't find anything similar. Per exploring the raw transaction data, it seems we only have `<signature>`.

If I am correct, how can I extract the public key, or sender address from an input which spends a P2TR output?

**Tags:** segregated-witness, taproot, p2tr

> **Comments:**
> **username_1**: Hi username_0, "witness program" refers to the byte vector in an output (such as the public key hash in P2WPKH). You probably mean "witness stack" or "input witness", is this correct?  
> **username_0**: You are probably right. according to BIP-0141, it seems it is called `witness fields` or `witness data`.  
> **username_2**: Note that there is no such thing as a “sender address”. It is not necessarily a given that the sender has control of the address that input funds were received to. E.g. if the sender uses a custodial service, the address may be associated with another user, or if the transaction was created by multiple users, the inputs may have been owned by various users.  

---

## 1 answers

### Answer by username_1 on 2023-04-27. Score: 3 | Accepted answer

From [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules):

> A Taproot output is a native SegWit output (see BIP141) with version
> number 1, and a 32-byte witness program. [...]
>
> * Let *q* be the 32-byte array containing the witness program (the second push in the scriptPubKey) which represents a public key
>   according to BIP340.
> * Fail if the witness stack has 0 elements.
> * If there are at least two witness elements, and the first byte of the last element is 0x50, this last element is called *annex a*
>   and is removed from the witness stack. The annex (or the lack of
>   thereof) is always covered by the signature and contributes to
>   transaction weight, but is otherwise ignored during taproot
>   validation.
> * If there is exactly one element left in the witness stack, key path spending is used:
>   + The single witness stack element is interpreted as the signature and must be valid (see the next section) for the public key
>     *q* (see the next subsection).
> * If there are at least two witness elements left, script path spending is used:
>   + Call the second-to-last stack element *s*, the script.

In other words, Taproot key path spends only have one1 witness item, the signature. Script path spends always have at least two witness items, and usually more to provide an initial stack for the script execution.

Since BIP340 signatures don't allow public key recovery, you can't compute the public key (and therefore address) from the signature alone in a key path spend. In a script path spend, you could combine the revealed internal key with the root of the script to get the public key.

However, getting the output script of the output being spent is as simple as looking up the transaction output referenced by the txid and index in the input, so there's rarely a reason to use a method that only works for some output scripts, and requires you to know the output type (P2TR in this case) in the first place.

---

1 Assuming the annex is not present.

> **Comments:**
> **username_0**: Thank you, so the only workaround to compute the address is to lookup the blockchain again for prev out?  
> **username_1**: I wouldn't even call that a workaround, that's just how it's normally done. Of course this all depends on what exactly you're doing, maybe you're storing the previous outputs with the transaction itself, but you definitely had to look them up at least once.  
> **username_0**: We pay for those blockchain requests, I just wanted to reduce the number of requests. It is possible to compute an address in other scripts, but it seems this is not the case for p2tr.  
> **username_1**: Even for those other scripts, you need to know what type of script you're looking at to compute the address. A witness stack with two items could be a P2WPKH, or it could be something else. I'd recommend considering a solution that doesn't require paying for API requests – this would usually involve running your own node.  
> **username_3**: if you can't recover the public key from a p2tr, then how can the network verify the signature included in the witness?  
> **username_3**: ah, IIUC the signature will be for the tweaked key always, so you don't need to retrieve any internal pubkey, you can use the tweaked pubkey to verify a signature  

---

