1

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?

1 Answer 1

2

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.

8
  • 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
    Commented Nov 8, 2023 at 13:19
  • 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
    Commented Nov 8, 2023 at 13:20
  • @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. Commented Nov 8, 2023 at 13:24
  • 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
    Commented Nov 8, 2023 at 13:34
  • 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. Commented Nov 8, 2023 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.