<p>To sign for an aggregated public key you need to run the respective collaborative signing protocol (e.g. if you use MuSig2 key aggregation to aggregate the keys, you need to run the MuSig2 signing protocol between the signers). There are several such protocols.</p>
<p>If the aggregated public key that comes out is then also tweaked in some way, you need to use a modified version of the signing protocol that also supports tweaking. This is a simple modification, but it's not just an additional step after the normal MuSig2 signing protocol.</p>

CC BY-SA 4.0
2023-11-08T13:19:59.787Z
So If I understood, there are a different ways (algorithms/protocols) to create a public key and its corresponding signature when we work with Schnorr. For example: MuSig, MuSig2, MuSig-DN... All these algorithm use some parts of Schnorr mathematic to create a correct signature and its public key. However, when we (and other nodes) validate the signature, we **always use one validating (Schnorr) algorithm that does not have anything with the way we created that public key and its signature**.
LeaBit
CC BY-SA 4.0
2023-11-08T13:20:43.800Z
So, other nodes do not need to know the way we got the signature and public key (the used algorithm; for example, is it MuSig or MuSig2), public key and signature just need to match each other according to the Schnorr signature validation algorithm and that's all. Is this correct?
LeaBit
CC BY-SA 4.0
2023-11-08T13:24:12.230Z
@LeaBit Yes. Public keys look all indistinguishable from one another (they're supposed to be random-looking, regardless of how they were generated). And for signatures the only requirement is that it's a valid BIP340 signature for the public key in the output (for key path spends) or for the public key(s) in the revealed script (in a script path spend). Nodes do not know or care how that signature was generated.
Pieter Wuille
CC BY-SA 4.0
2023-11-08T13:34:13.810Z
Just one more question. Is this a specificity of the Schnorr algorithm and the way it works, or can this also be applied in ECDSA? I know the basic (original) algorithm for obtaining signatures in ECDSA and ECC public keys, where we can additionally do basic tweaking of public and private keys with some value (for P2C) and that's it. **However, with ECDSA, can we also use DIFFERENT algorithms (MuSig, MuSig2 etc) to obtain public key and its corresponding signature, and then use ONLY one ECDSA signature validation algorithm?** In other words, does this whole story also apply to ECDSA?
LeaBit
CC BY-SA 4.0
2023-11-08T13:36:25.733Z
There also exist multi-party ECDSA algorithms, but they are very different and much more complicated (look up 2P-ECDSA for example). MuSig and friends don't apply to ECDSA, as their signing algorithm results in a valid Schnorr signature, not a valid ECDSA signature. It's specifically due to Schnorr's simple structure that multi-party variants are easy.
Pieter Wuille
CC BY-SA 4.0
2023-11-08T13:47:04.300Z
Okay, but still different algorithms (related now to ECDSA mathematic) can be used for generating public key and its signature and these algorithms do not have anything with the process of validating signature. That is, only one validation signature ECDSA algorithm is used? I ask, because as I know we do not state anywhere in ECDSA which algorithm we used to generate the keys and their signatures, it is only important to signature be valid and that's all. Is this true?
LeaBit
CC BY-SA 4.0
2023-11-08T13:49:49.960Z
Yes and no. ECDSA (like any digital signature scheme) is technically speaking a collection of three algorithms (key generation, signing, verification). It just so happens that the 2P-ECDSA scheme (which replaces the key generation and signing part with something else) happens to have the same verification algorithm as normal ECDSA. The same is true for MuSig etc. with BIP340/Schnorr. So yes, the verification algorithm is always that of just ECDSA (for pre-Taproot outputs) or BIP340 (for Taproot outputs).
Pieter Wuille
CC BY-SA 4.0
2023-11-08T14:02:16.247Z
@Leabit: If you have a follow-up question that goes beyond the scope of the original question, please create another topic.—Pieter: Could you please incorporate the additional information relevant to this topic from the comments into your answer?
Murch
CC BY-SA 4.0
2023-11-08T12:26:53.640Z
2023-11-08T12:26:53.640Z
Pieter Wuille
<p><strong>EDIT: Can we just tweak the signature with the root MAST as well?</strong></p>
<p>As I understand, the public key in scriptPubKey for P2TR is obtained by tweaking (let's call it <strong>original public key</strong>) and the root of the MAST. This <strong>original public key</strong>, in context of multi-signature, <code>is obtained by the process of Schnorr aggregation of the public keys owned by multiple participants</code>. In the following, I will refer to the obtained public key (the one in scriptPubKey) as the <strong>P2TR public key</strong>.</p>
<p>What I'm interested in is <strong>how do we get a proper signature for such a P2TR public key?</strong></p>
<p>If it was just one public key (not one obtained from multiple public keys), it would be easy. We would simply tweak the private key with the MAST root as well and then create the signature.</p>
<p>However, in the case of multisig (as far as I understand) the signature is created in such a way that all participants, each with their own private key, create partial signatures that are then merged into one. The problem is that this signature will match the <strong>original public key</strong>, not the <strong>P2TR public key</strong> that is in the scriptPubKey. So, the signature is not correct.</p>
<p>How is this overcome? How to make a correct signature in this case?</p>

<multi-signature><taproot><p2tr><key-tweaking>
How to get signature for tweaked public key in P2TR in case of multiple signature?
LeaBit
# How to get signature for tweaked public key in P2TR in case of multiple signature?

(Asked by: username_0 on 2023-11-08)

**EDIT: Can we just tweak the signature with the root MAST as well?**

As I understand, the public key in scriptPubKey for P2TR is obtained by tweaking (let's call it **original public key**) and the root of the MAST. This **original public key**, in context of multi-signature, `is obtained by the process of Schnorr aggregation of the public keys owned by multiple participants`. In the following, I will refer to the obtained public key (the one in scriptPubKey) as the **P2TR public key**.

What I'm interested in is **how do we get a proper signature for such a P2TR public key?**

If it was just one public key (not one obtained from multiple public keys), it would be easy. We would simply tweak the private key with the MAST root as well and then create the signature.

However, in the case of multisig (as far as I understand) the signature is created in such a way that all participants, each with their own private key, create partial signatures that are then merged into one. The problem is that this signature will match the **original public key**, not the **P2TR public key** that is in the scriptPubKey. So, the signature is not correct.

How is this overcome? How to make a correct signature in this case?

**Tags:** multi-signature, taproot, p2tr, key-tweaking


---

## 1 answers

### Answer by username_1 on 2023-11-08. Score: 2 | Accepted answer

To sign for an aggregated public key you need to run the respective collaborative signing protocol (e.g. if you use MuSig2 key aggregation to aggregate the keys, you need to run the MuSig2 signing protocol between the signers). There are several such protocols.

If the aggregated public key that comes out is then also tweaked in some way, you need to use a modified version of the signing protocol that also supports tweaking. This is a simple modification, but it's not just an additional step after the normal MuSig2 signing protocol.

> **Comments:**
> **username_0**: So If I understood, there are a different ways (algorithms/protocols) to create a public key and its corresponding signature when we work with Schnorr. For example: MuSig, MuSig2, MuSig-DN... All these algorithm use some parts of Schnorr mathematic to create a correct signature and its public key. However, when we (and other nodes) validate the signature, we **always use one validating (Schnorr) algorithm that does not have anything with the way we created that public key and its signature**.  
> **username_0**: So, other nodes do not need to know the way we got the signature and public key (the used algorithm; for example, is it MuSig or MuSig2), public key and signature just need to match each other according to the Schnorr signature validation algorithm and that's all. Is this correct?  
> **username_1**: @username_0 Yes. Public keys look all indistinguishable from one another (they're supposed to be random-looking, regardless of how they were generated). And for signatures the only requirement is that it's a valid BIP340 signature for the public key in the output (for key path spends) or for the public key(s) in the revealed script (in a script path spend). Nodes do not know or care how that signature was generated.  
> **username_0**: Just one more question. Is this a specificity of the Schnorr algorithm and the way it works, or can this also be applied in ECDSA? I know the basic (original) algorithm for obtaining signatures in ECDSA and ECC public keys, where we can additionally do basic tweaking of public and private keys with some value (for P2C) and that's it. **However, with ECDSA, can we also use DIFFERENT algorithms (MuSig, MuSig2 etc) to obtain public key and its corresponding signature, and then use ONLY one ECDSA signature validation algorithm?** In other words, does this whole story also apply to ECDSA?  
> **username_1**: There also exist multi-party ECDSA algorithms, but they are very different and much more complicated (look up 2P-ECDSA for example). MuSig and friends don't apply to ECDSA, as their signing algorithm results in a valid Schnorr signature, not a valid ECDSA signature. It's specifically due to Schnorr's simple structure that multi-party variants are easy.  
> **username_0**: Okay, but still different algorithms (related now to ECDSA mathematic) can be used for generating public key and its signature and these algorithms do not have anything with the process of validating signature. That is, only one validation signature ECDSA algorithm is used? I ask, because as I know we do not state anywhere in ECDSA which algorithm we used to generate the keys and their signatures, it is only important to signature be valid and that's all. Is this true?  
> **username_1**: Yes and no. ECDSA (like any digital signature scheme) is technically speaking a collection of three algorithms (key generation, signing, verification). It just so happens that the 2P-ECDSA scheme (which replaces the key generation and signing part with something else) happens to have the same verification algorithm as normal ECDSA. The same is true for MuSig etc. with BIP340/Schnorr. So yes, the verification algorithm is always that of just ECDSA (for pre-Taproot outputs) or BIP340 (for Taproot outputs).  
> **username_2**: @username_0: If you have a follow-up question that goes beyond the scope of the original question, please create another topic.—username_1: Could you please incorporate the additional information relevant to this topic from the comments into your answer?  

---

