<blockquote>
<p>Is there any need for addition key tweaking if we use MuSig2 protocol for multisignature?</p>
</blockquote>
<p>Citing <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP341</a>:</p>
<blockquote>
<p><strong>Why should the output key always have a taproot commitment, even if there is no script path?</strong></p>
<p>If the taproot output key is an aggregate of keys, there is the possibility for a malicious party to add a script path without being noticed by the other parties. This allows to bypass the multiparty policy and to steal the coin. <em>MuSig key aggregation does not have this issue because it already causes the internal key to be randomized.</em> The attack works as follows: Assume Alice and Mallory want to aggregate their keys into a taproot output key without a script path. In order to prevent key cancellation and related attacks they use MSDL-pop instead of MuSig. The MSDL-pop protocol requires all parties to provide a proof of possession of their corresponding secret key and the aggregated key is just the sum of the individual keys. After Mallory receives Alice's key A, Mallory creates M = M0 + int(t)G where M0 is Mallory's original key and t allows a script path spend with internal key P = A + M0 and a script that only contains Mallory's key. Mallory sends a proof of possession of M to Alice and both parties compute output key Q = A + M = P + int(t)G. Alice will not be able to notice the script path, but Mallory can unilaterally spend any coin with output key Q.</p>
</blockquote>
<p>(emphasis mine)</p>
<p>BIP341 recommends always tweaking, even without a script path, because it is the conservative option. Explaining, or even just reasoning about when it is or isn't okay not to tweak is complicated when multiple protocols are in use, so it is just a safe default. In the case of just MuSig2 as internal key, I am relatively confident there is no means of attacking that. My recommendation is still to always tweak.</p>

CC BY-SA 4.0
2023-11-23T13:53:29.873Z
2023-11-23T13:58:48.637Z
2023-11-23T13:58:48.637Z
Pieter Wuille
<p>I read in some article for Taproot that if there is no need for a script path spending and a number of participant (multisignature with key aggregation) create together a taproot output key (key for a segWit 1 witness program), the key shouldn't just be the sum of their public keys (A+B+C+D). Reason comes from the fact that some participant (either A, B, C or D) can create a &quot;hidden&quot; script that can later be used to steal coins through script path without knowledge of other participant. So when the taproot output key is the sum of public keys, then it is necessary to also tweak that key with &quot;something&quot; additional. However, what if we use MuSig2 protocol (and its key aggregation) instead of just basic sum of the public keys?</p>
<p><strong>Is there any need for addition key tweaking if we use MuSig2 protocol for multisignature?</strong></p>

<public-key><taproot><musig><key-tweaking>
Do we need a taproot commit for multisignatures if there is no script path, but we are using the MuSig2 protocol?
LeaBit
# Do we need a taproot commit for multisignatures if there is no script path, but we are using the MuSig2 protocol?

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

I read in some article for Taproot that if there is no need for a script path spending and a number of participant (multisignature with key aggregation) create together a taproot output key (key for a segWit 1 witness program), the key shouldn't just be the sum of their public keys (A+B+C+D). Reason comes from the fact that some participant (either A, B, C or D) can create a "hidden" script that can later be used to steal coins through script path without knowledge of other participant. So when the taproot output key is the sum of public keys, then it is necessary to also tweak that key with "something" additional. However, what if we use MuSig2 protocol (and its key aggregation) instead of just basic sum of the public keys?

**Is there any need for addition key tweaking if we use MuSig2 protocol for multisignature?**

**Tags:** public-key, taproot, musig, key-tweaking


---

## 1 answers

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

> Is there any need for addition key tweaking if we use MuSig2 protocol for multisignature?

Citing [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki):

> **Why should the output key always have a taproot commitment, even if there is no script path?**
>
> If the taproot output key is an aggregate of keys, there is the possibility for a malicious party to add a script path without being noticed by the other parties. This allows to bypass the multiparty policy and to steal the coin. *MuSig key aggregation does not have this issue because it already causes the internal key to be randomized.* The attack works as follows: Assume Alice and Mallory want to aggregate their keys into a taproot output key without a script path. In order to prevent key cancellation and related attacks they use MSDL-pop instead of MuSig. The MSDL-pop protocol requires all parties to provide a proof of possession of their corresponding secret key and the aggregated key is just the sum of the individual keys. After Mallory receives Alice's key A, Mallory creates M = M0 + int(t)G where M0 is Mallory's original key and t allows a script path spend with internal key P = A + M0 and a script that only contains Mallory's key. Mallory sends a proof of possession of M to Alice and both parties compute output key Q = A + M = P + int(t)G. Alice will not be able to notice the script path, but Mallory can unilaterally spend any coin with output key Q.

(emphasis mine)

BIP341 recommends always tweaking, even without a script path, because it is the conservative option. Explaining, or even just reasoning about when it is or isn't okay not to tweak is complicated when multiple protocols are in use, so it is just a safe default. In the case of just MuSig2 as internal key, I am relatively confident there is no means of attacking that. My recommendation is still to always tweak.


---

