<p>A slight variant of MuSig2, named MuSig2*, sets one of the coefficients to 1 to make the key aggregation function slightly more efficient. This is described in a <a href="https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki#design" rel="nofollow noreferrer">draft specification of MuSig2</a> : ↩</p>
<blockquote>
<p>MuSig2* optimization: The specification uses an optimization that allows saving a point multiplication in key aggregation. The MuSig2 scheme with this optimization is called MuSig2* and proven secure in the appendix of the MuSig2 paper. The optimization is that the second distinct key in the list of public keys given to the key aggregation algorithm (as well as any keys identical to this key) gets the constant key aggregation coefficient 1.</p>
</blockquote>
<p>I was myself confused by this when writing my <a href="https://popeller.io/schnorr-musig2" rel="nofollow noreferrer">blog post about MuSig2</a>.</p>
<p>This trick resembles normalization of a polynomial, which is accomplished by dividing each term by the first terms' coefficient.</p>

CC BY-SA 4.0
2022-07-22T11:42:00.743Z
2022-07-22T11:47:10.230Z
2022-07-22T11:47:10.230Z
Kalle Rosenbaum
<p>In MuSig2 <code>R''_i</code> is added to itself b times (in <a href="https://bitcoin.stackexchange.com/questions/114490/in-musig2-how-is-multiplication-of-coordinates-defined">multiplicative notation</a>, it has the exponent <code>b</code>) but <code>R'_i</code> is not (it does not have the exponent <code>b</code>).</p>
<p>Why does only one of the nonce points have the exponent <code>b</code> and not both? I was expecting:</p>
<p><code>R_i = (R'_i.R''_i)^b</code></p>
<p>I'm assuming it saves on exponentiations and somehow offers the same security (because <code>b</code> is hashing both <code>R'_i</code> and <code>R''_i</code>)?</p>
<p>(<code>R_i</code> is the generator point G added to itself <code>r_i</code> times where <code>r_i</code> is the nonce. Or <code>R_i = g^r_i</code> in multiplicative notation.)</p>
<p>The following is taken from Tim Ruffing's slides at <a href="https://i.sstatic.net/IIzmx.png" rel="nofollow noreferrer">Real World Crypto 2021</a>:</p>
<p><a href="https://i.sstatic.net/IIzmx.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/IIzmx.png" alt="musig2" /></a></p>

<multi-signature><schnorr-signatures><musig>
Why does only one of the two nonce points in MuSig2 have the exponent b?
Michael Folkson
# Why does only one of the two nonce points in MuSig2 have the exponent b?

(Asked by: username_0 on 2022-07-22)

In MuSig2 `R''_i` is added to itself b times (in [multiplicative notation](https://bitcoin.stackexchange.com/questions/114490/in-musig2-how-is-multiplication-of-coordinates-defined), it has the exponent `b`) but `R'_i` is not (it does not have the exponent `b`).

Why does only one of the nonce points have the exponent `b` and not both? I was expecting:

`R_i = (R'_i.R''_i)^b`

I'm assuming it saves on exponentiations and somehow offers the same security (because `b` is hashing both `R'_i` and `R''_i`)?

(`R_i` is the generator point G added to itself `r_i` times where `r_i` is the nonce. Or `R_i = g^r_i` in multiplicative notation.)

The following is taken from Tim Ruffing's slides at [Real World Crypto 2021](https://i.sstatic.net/IIzmx.png):

[![musig2](https://i.sstatic.net/IIzmx.png)](https://i.sstatic.net/IIzmx.png)

**Tags:** multi-signature, schnorr-signatures, musig


---

## 1 answers

### Answer by username_1 on 2022-07-22. Score: 2 | Accepted answer

A slight variant of MuSig2, named MuSig2\*, sets one of the coefficients to 1 to make the key aggregation function slightly more efficient. This is described in a [draft specification of MuSig2](https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki#design) : ↩

> MuSig2\* optimization: The specification uses an optimization that allows saving a point multiplication in key aggregation. The MuSig2 scheme with this optimization is called MuSig2\* and proven secure in the appendix of the MuSig2 paper. The optimization is that the second distinct key in the list of public keys given to the key aggregation algorithm (as well as any keys identical to this key) gets the constant key aggregation coefficient 1.

I was myself confused by this when writing my [blog post about MuSig2](https://popeller.io/schnorr-musig2).

This trick resembles normalization of a polynomial, which is accomplished by dividing each term by the first terms' coefficient.


---

