<p>For all intents and purposes, the <a href="https://eprint.iacr.org/2018/068" rel="nofollow noreferrer">MuSig1</a> scheme is supplanted by the <a href="https://eprint.iacr.org/2020/1261" rel="nofollow noreferrer">MuSig2</a> scheme (and the MuSig2* scheme defined in the same paper). MuSig2 only needs 2 rounds of interactions, as opposed to the 3 rounds that MuSig1 needs, at the cost of a small bandwidth and computation increase. As far as I know, no production-ready specification for MuSig1 was ever written, and nobody ever deployed MuSig1 in production.</p>
<p>MuSig1 and MuSig2 are multi-signature schemes, which support key aggregation compatible with Schnorr signatures. This means that it enables a group of participants to jointly produce a single Schnorr signature that is valid for an aggregate of their public keys. Verifiers do not need to know or care that the signature was constructed through MuSig; for all intents and purposes, it is a normal Schnorr signature.</p>
<p>The MuSig1 paper does additionally propose an Interactive Aggregated Signature (IAS) variant of the MuSig1 multi-signature scheme. In this variant, each signer can have their own message to sign, and the result is not compatible with Schnorr signatures (because the verifier needs to know all messages being signed, while Schnorr signatures only have one message). While MuSig1 (and MuSig2) can be turned into IAS schemes like this, there are simpler algorithms like <a href="https://cseweb.ucsd.edu/%7Emihir/papers/multisignatures.pdf" rel="nofollow noreferrer">BN06</a> that also support this.</p>
<p>This distinction is relevant for how these technologies can be used in Bitcoin:</p>
<ul>
<li><p>Multi-signatures can be used as a cheaper, more compact, and more private replacement for Bitcoin's traditional <code>OP_CHECKMULTISIG</code>-based multisig(*) scripts. Instead of publishing all public keys, and all individual signatures to the blockchain at spending time, only the aggregated public key (pre-negotiated between the participants) and the aggregated multi-signature is published. Notably, this does not require integration of the scheme &quot;in&quot; Bitcoin, in the sense that it doesn't become part of its protocol or consensus rules. It is just something any group of wallets that want to engage in multisig-like control of funds can choose to use, without anyone else needing to be aware.</p>
</li>
<li><p>The IAS variant is potentially useful for <a href="https://bitcoinops.org/en/topics/cross-input-signature-aggregation/" rel="nofollow noreferrer">cross-input aggregation</a> (CISA): the idea that an entire <em>transaction</em> (not just a single input of a transaction) would only need a single signature, created jointly by all participants whose coins are spent by the transaction. This is typically just a single party, but may involve multiple parties in the case of CoinJoin, for example. This is distinct from the multi-signature case in multiple ways:</p>
<ul>
<li>Each output still has its own public key(s). Instead of doing the key aggregation ahead of time when the address is decided, it is done when spending.</li>
<li>The set participants may not be known before spending time (e.g., in a CoinJoin they are decided on the fly).</li>
<li>This requires integration into Bitcoin's consensus rules. There is no way today for scripts to even observe what other inputs of the same transaction are doing. Enabling the ability to have a single signature for all of them necessarily means changing that.</li>
</ul>
<p>I bring this distinction up because based on your comments, you seem to be under the impression that MuSig (1 or 2) needs to be integrated &quot;into&quot; Bitcoin, and CISA is the only application I'm aware of that actually needs something like this. Using MuSig as a replacement for multisig can be done by anyone at any time, without anyone's permission. We wouldn't even be able to tell if someone were to be using MuSig1 today on Bitcoin.</p>
</li>
</ul>
<p>Lastly, while the &quot;P&quot; in BIP means &quot;proposal&quot;, BIPs are really just the name of the documents, and process around those documents, in which specifications for Bitcoin are published. Some BIPs never make it past the point of being a proposal, but others end up being part of the protocol. In either case, it is not because something is (still) a BIP that it is or isn't &quot;part of Bitcoin&quot;. This is up to individual software choosing to implement these proposals or not.</p>
<p>(*) Note that &quot;multisig&quot; in Bitcoin context means &quot;k-of-n spending policy&quot; (where k may be less than n), while multi-signatures in the cryptography context means &quot;compact n-of-n signature&quot;, while compact k-of-n signatures are known as <em>threshold signatures</em>. There is work as well on <a href="https://bitcoinops.org/en/topics/threshold-signature/" rel="nofollow noreferrer">Bitcoin-compatible threshold signatures</a>, such a FROST.</p>
<hr />
<p>As for your questions:</p>
<blockquote>
<ol>
<li><strong>Sharing ti, Ri, and si:</strong> How do participants send their commitments (ti), share their Ri values, and exchange partial signatures (si)? What does this process look like in practice? Is there a standard, asynchronous, and user-friendly way to manage this in software? Or do participants need to manually compute their si, sum them, and share the results back and forth?</li>
</ol>
</blockquote>
<p>For MuSig2 (itself specified for Bitcoin in <a href="https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki" rel="nofollow noreferrer">BIP327</a>), there is <a href="https://github.com/bitcoin/bips/blob/master/bip-0373.mediawiki" rel="nofollow noreferrer">BIP373</a> which specifies MuSig2-specific fields for the PSBT (partially signed Bitcoin transaction) format. Multisig participants can then exchange PSBT files with each other.</p>
<p>Beyond that, expect that MuSig2 will be integrated into more ad-hoc protocols.</p>
<p>Parties can aggregate the partial nonces received from other parties themselves, or have one coordinator do that for them. A dishonest coordinator can only result in an invalid signature; they can't cause forgeries or key leaks.</p>
<blockquote>
<ol start="2">
<li><strong>Verification Process:</strong> Who verifies the final signature (Rsum, ssum)? When and how does this verification happen in real-world Bitcoin use cases? Is the verification done via P2SH scripts?</li>
</ol>
</blockquote>
<p>The final signature is (in the case of Bitcoin, using BIP327) is Bitcoin-style Schnorr signature (specified in <a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki" rel="nofollow noreferrer">BIP340</a>). BIP340 signatures can only be used when spending Taproot outputs (specified in <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP341</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki" rel="nofollow noreferrer">BIP342</a>); it is not available inside P2SH. Since they're just signatures, no script is needed. Any place where one would want to use a signature to spend an output, MuSig2 multisig could be used instead of the normal (single party) BIP340 signing. The verifier is always just Bitcoin nodes that validate blocks and transactions, but again, they will not even be aware that MuSig2 is involved. To them, it's just a normal key, and a normal signature.</p>
<blockquote>
<p>And regarding the initiation of the verification process—does a participant (e.g., one of the multisig signers) who has collected all the Rsum and ssum values create the transaction from the P2SH address? Or am I misunderstanding this flow?</p>
</blockquote>
<p>One of the parties, or a coordinator, will aggregate the partial signatures and construct the full signature, which can then be placed in the spending transaction, which will make the spending transaction valid and broadcastable to the network.</p>
<blockquote>
<ol start="3">
<li><strong>What Happens Without Commitments?</strong> What could an adversary do if the commitments (ti) were not part of the protocol? What kind of attacks could occur, and how would they exploit the lack of commitments?</li>
</ol>
</blockquote>
<p>In MuSig1, without the first nonce-commitment phase, practical attacks are possible where an attacker starts multiple concurrent signing sessions with a victim, and succeeds in constructing a forged signature (for a message the attacker chooses, not agreed by the victims). In MuSig2, this phase does not exist anymore.</p>

CC BY-SA 4.0
2024-12-13T22:53:33.880Z
thanks you so much for you answer.......


>"In MuSig1, without the first nonce-commitment phase, replay attacks are possible where participants can learn the private key of other participants. In MuSig2, this phase does not exist anymore".........   

so commitments are not to prevent the rogue attack, but instead to prevent replay attack. can you tell me how these replay attacks can be performed to learn private key of other participants? or maybe giving me a reference from which I can learn more about? what's the link between a commitment and a private key
allexj
CC BY-SA 4.0
2024-12-14T08:34:51.597Z
@allexj You may want to look at section 2.1 "The Challenge of Constructing Two-Round Schemes" in the MuSig2 paper for a brief description of the attack against MuSig1 without the nonce-commitment phase.
nickler
CC BY-SA 4.0
2024-12-14T19:39:31.247Z
@nickler Thanks, I was confusing the replay attacks (which are possible when nonces are chosen predictably) with the concurrent signing attacks (which are possible without the nonce commitment in MuSig1). I have updated my answer.
Pieter Wuille
CC BY-SA 4.0
2024-12-17T11:54:03.740Z
@nickler thanks for the answer, I've read that paragraph of that paper. One question though: how should I imagine, in a real world scenario, the fact that the adversary opens up k different signing sessions? Why should a victim allow that? Also, I thought that multi signatures were performed by passing the partial signature data across the users "manually" until the required number of user is reached, and at that point, the last user can send the final signature to the bitcoin network.... so how can I imagine this "k different signing sessions"? Is there a protocol/system to support that?
allexj
CC BY-SA 4.0
2024-12-17T11:54:32.507Z
@PieterWuille I also tag you
allexj
CC BY-SA 4.0
2024-12-17T12:26:01.727Z
also, why X aggregate is the product? Shouldn't it be a sum? The same for R*, shouldn't it be a sum? Is there a technological/performance/security reason why it's a multiplication and not a sum?
allexj
CC BY-SA 4.0
2024-12-17T12:32:05.177Z
@allexj A "session" in the MuSig2 sense is the time between the first and second round (i.e., the time while the victim needs to hold on to a private nonce whose public version has been shared with others). MuSig2 is secure even when a victim is participating in multiple such sessions at the same time. It doesn't matter how the partial nonces or signatures are shared; the concurrent attack just requires the attacker to have multiple at the same time, and being able to choose which ones to continue.
Pieter Wuille
CC BY-SA 4.0
2024-12-17T12:34:44.280Z
@allexj The product vs. sum is just a notation issue. Some people write the group operation (for elliptic curves, point addition) as an addition, and its repetition (point multiplication) as a multiplication. Others use a multiplicative notation for the group operation and exponentiation for its repetition. Note that the latter is where the term "discrete logarithm" comes from; in the additive notation setting it ought to be called "discrete division". The MuSig2 paper uses multiplicative notation.
Pieter Wuille
CC BY-SA 4.0
2024-12-13T21:29:10.357Z
2024-12-14T19:38:31.560Z
2024-12-14T19:38:31.560Z
Pieter Wuille
<p><strong>Signature Generation</strong></p>
<ol>
<li>Let <code>L = h(P1 || ... || Pn)</code>. Each participant computes the digest: <code>ai = h(L || Pi)</code>.</li>
<li>Compute the aggregated public key: <code>X̃ = Σ (ai * Pi)</code> for <code>i = 1, ..., n</code>. <code>X̃</code> is made public.</li>
<li>Each participant randomly selects <code>ri</code> and computes: <code>Ri = ri * G</code>. Each participant sends their commitment: <code>ti = h(Ri)</code> to all other participants.</li>
<li>After receiving the other <code>n-1</code> commitments, each participant sends their point <code>Ri</code>.</li>
<li>After receiving the other <code>n-1</code> points <code>Ri</code>, each participant verifies: <code>ti = h(Ri)</code> for all <code>i ∈ {1, ..., n}</code>.</li>
<li>Calculate the aggregated point: <code>Rsum = R1 + ... + Rn</code>.</li>
<li>Each participant computes the challenge: <code>c = h(Rsum || X̃ || M)</code>.</li>
<li>Each participant calculates their partial signature: <code>si = ri + c * di * ai mod N</code>.Finally, compute the aggregated signature: <code>ssum = s1 + ... + sn mod N</code>.</li>
<li>The signature is the pair <code>(Rsum, ssum)</code>.</li>
</ol>
<p><strong>Signature Verification</strong><br />
Check if:<br />
<code>ssum * G = Rsum + c * X̃</code>.</p>
<p><strong>Questions:</strong></p>
<ol>
<li><p><strong>Sharing ti, Ri, and si:</strong><br />
How do participants send their commitments (<code>ti</code>), share their <code>Ri</code> values, and exchange partial signatures (<code>si</code>)? What does this process look like in practice? Is there a standard, asynchronous, and user-friendly way to manage this in software? Or do participants need to manually compute their <code>si</code>, sum them, and share the results back and forth?</p>
</li>
<li><p><strong>Verification Process:</strong><br />
Who verifies the final signature <code>(Rsum, ssum)</code>? When and how does this verification happen in real-world Bitcoin use cases? Is the verification done via P2SH scripts?<br />
And regarding the initiation of the verification process—does a participant (e.g., one of the multisig signers) who has collected all the <code>Rsum</code> and <code>ssum</code> values create the transaction from the P2SH address? Or am I misunderstanding this flow?</p>
</li>
<li><p><strong>What Happens Without Commitments?</strong><br />
What could an adversary do if the commitments (<code>ti</code>) were not part of the protocol? What kind of attacks could occur, and how would they exploit the lack of commitments?</p>
</li>
</ol>

CC BY-SA 4.0
2024-12-13T17:49:46.027Z
Have you read [BIP 327](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki), the MuSig2 spec for Bitcoin?
Pieter Wuille
CC BY-SA 4.0
2024-12-13T18:13:41.280Z
@PieterWuille is MuSig2 used by Bitcoin? I thought it was still a BIP.... anyway, I asked about MuSig1, not MuSig2
allexj
<multi-signature><p2sh><schnorr-signatures><musig><key-aggregation>
How does MuSig work in real Bitcoin scenarios? Questions on communication and steps
allexj
# How does MuSig work in real Bitcoin scenarios? Questions on communication and steps

(Asked by: username_0 on 2024-12-13)

**Signature Generation**

1. Let `L = h(P1 || ... || Pn)`. Each participant computes the digest: `ai = h(L || Pi)`.
2. Compute the aggregated public key: `X̃ = Σ (ai * Pi)` for `i = 1, ..., n`. `X̃` is made public.
3. Each participant randomly selects `ri` and computes: `Ri = ri * G`. Each participant sends their commitment: `ti = h(Ri)` to all other participants.
4. After receiving the other `n-1` commitments, each participant sends their point `Ri`.
5. After receiving the other `n-1` points `Ri`, each participant verifies: `ti = h(Ri)` for all `i ∈ {1, ..., n}`.
6. Calculate the aggregated point: `Rsum = R1 + ... + Rn`.
7. Each participant computes the challenge: `c = h(Rsum || X̃ || M)`.
8. Each participant calculates their partial signature: `si = ri + c * di * ai mod N`.Finally, compute the aggregated signature: `ssum = s1 + ... + sn mod N`.
9. The signature is the pair `(Rsum, ssum)`.

**Signature Verification**  
Check if:  
`ssum * G = Rsum + c * X̃`.

**Questions:**

1. **Sharing ti, Ri, and si:**  
   How do participants send their commitments (`ti`), share their `Ri` values, and exchange partial signatures (`si`)? What does this process look like in practice? Is there a standard, asynchronous, and user-friendly way to manage this in software? Or do participants need to manually compute their `si`, sum them, and share the results back and forth?
2. **Verification Process:**  
   Who verifies the final signature `(Rsum, ssum)`? When and how does this verification happen in real-world Bitcoin use cases? Is the verification done via P2SH scripts?  
   And regarding the initiation of the verification process—does a participant (e.g., one of the multisig signers) who has collected all the `Rsum` and `ssum` values create the transaction from the P2SH address? Or am I misunderstanding this flow?
3. **What Happens Without Commitments?**  
   What could an adversary do if the commitments (`ti`) were not part of the protocol? What kind of attacks could occur, and how would they exploit the lack of commitments?

**Tags:** multi-signature, p2sh, schnorr-signatures, musig, key-aggregation

> **Comments:**
> **username_1**: Have you read [BIP 327](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki), the MuSig2 spec for Bitcoin?  
> **username_0**: @username_1 is MuSig2 used by Bitcoin? I thought it was still a BIP.... anyway, I asked about MuSig1, not MuSig2  

---

## 1 answers

### Answer by username_1 on 2024-12-13. Score: 3 | Accepted answer

For all intents and purposes, the [MuSig1](https://eprint.iacr.org/2018/068) scheme is supplanted by the [MuSig2](https://eprint.iacr.org/2020/1261) scheme (and the MuSig2\* scheme defined in the same paper). MuSig2 only needs 2 rounds of interactions, as opposed to the 3 rounds that MuSig1 needs, at the cost of a small bandwidth and computation increase. As far as I know, no production-ready specification for MuSig1 was ever written, and nobody ever deployed MuSig1 in production.

MuSig1 and MuSig2 are multi-signature schemes, which support key aggregation compatible with Schnorr signatures. This means that it enables a group of participants to jointly produce a single Schnorr signature that is valid for an aggregate of their public keys. Verifiers do not need to know or care that the signature was constructed through MuSig; for all intents and purposes, it is a normal Schnorr signature.

The MuSig1 paper does additionally propose an Interactive Aggregated Signature (IAS) variant of the MuSig1 multi-signature scheme. In this variant, each signer can have their own message to sign, and the result is not compatible with Schnorr signatures (because the verifier needs to know all messages being signed, while Schnorr signatures only have one message). While MuSig1 (and MuSig2) can be turned into IAS schemes like this, there are simpler algorithms like [BN06](https://cseweb.ucsd.edu/%7Emihir/papers/multisignatures.pdf) that also support this.

This distinction is relevant for how these technologies can be used in Bitcoin:

* Multi-signatures can be used as a cheaper, more compact, and more private replacement for Bitcoin's traditional `OP_CHECKMULTISIG`-based multisig(\*) scripts. Instead of publishing all public keys, and all individual signatures to the blockchain at spending time, only the aggregated public key (pre-negotiated between the participants) and the aggregated multi-signature is published. Notably, this does not require integration of the scheme "in" Bitcoin, in the sense that it doesn't become part of its protocol or consensus rules. It is just something any group of wallets that want to engage in multisig-like control of funds can choose to use, without anyone else needing to be aware.
* The IAS variant is potentially useful for [cross-input aggregation](https://bitcoinops.org/en/topics/cross-input-signature-aggregation/) (CISA): the idea that an entire *transaction* (not just a single input of a transaction) would only need a single signature, created jointly by all participants whose coins are spent by the transaction. This is typically just a single party, but may involve multiple parties in the case of CoinJoin, for example. This is distinct from the multi-signature case in multiple ways:

  + Each output still has its own public key(s). Instead of doing the key aggregation ahead of time when the address is decided, it is done when spending.
  + The set participants may not be known before spending time (e.g., in a CoinJoin they are decided on the fly).
  + This requires integration into Bitcoin's consensus rules. There is no way today for scripts to even observe what other inputs of the same transaction are doing. Enabling the ability to have a single signature for all of them necessarily means changing that.

  I bring this distinction up because based on your comments, you seem to be under the impression that MuSig (1 or 2) needs to be integrated "into" Bitcoin, and CISA is the only application I'm aware of that actually needs something like this. Using MuSig as a replacement for multisig can be done by anyone at any time, without anyone's permission. We wouldn't even be able to tell if someone were to be using MuSig1 today on Bitcoin.

Lastly, while the "P" in BIP means "proposal", BIPs are really just the name of the documents, and process around those documents, in which specifications for Bitcoin are published. Some BIPs never make it past the point of being a proposal, but others end up being part of the protocol. In either case, it is not because something is (still) a BIP that it is or isn't "part of Bitcoin". This is up to individual software choosing to implement these proposals or not.

(\*) Note that "multisig" in Bitcoin context means "k-of-n spending policy" (where k may be less than n), while multi-signatures in the cryptography context means "compact n-of-n signature", while compact k-of-n signatures are known as *threshold signatures*. There is work as well on [Bitcoin-compatible threshold signatures](https://bitcoinops.org/en/topics/threshold-signature/), such a FROST.

---

As for your questions:

> 1. **Sharing ti, Ri, and si:** How do participants send their commitments (ti), share their Ri values, and exchange partial signatures (si)? What does this process look like in practice? Is there a standard, asynchronous, and user-friendly way to manage this in software? Or do participants need to manually compute their si, sum them, and share the results back and forth?

For MuSig2 (itself specified for Bitcoin in [BIP327](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki)), there is [BIP373](https://github.com/bitcoin/bips/blob/master/bip-0373.mediawiki) which specifies MuSig2-specific fields for the PSBT (partially signed Bitcoin transaction) format. Multisig participants can then exchange PSBT files with each other.

Beyond that, expect that MuSig2 will be integrated into more ad-hoc protocols.

Parties can aggregate the partial nonces received from other parties themselves, or have one coordinator do that for them. A dishonest coordinator can only result in an invalid signature; they can't cause forgeries or key leaks.

> 2. **Verification Process:** Who verifies the final signature (Rsum, ssum)? When and how does this verification happen in real-world Bitcoin use cases? Is the verification done via P2SH scripts?

The final signature is (in the case of Bitcoin, using BIP327) is Bitcoin-style Schnorr signature (specified in [BIP340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)). BIP340 signatures can only be used when spending Taproot outputs (specified in [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) and [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)); it is not available inside P2SH. Since they're just signatures, no script is needed. Any place where one would want to use a signature to spend an output, MuSig2 multisig could be used instead of the normal (single party) BIP340 signing. The verifier is always just Bitcoin nodes that validate blocks and transactions, but again, they will not even be aware that MuSig2 is involved. To them, it's just a normal key, and a normal signature.

> And regarding the initiation of the verification process—does a participant (e.g., one of the multisig signers) who has collected all the Rsum and ssum values create the transaction from the P2SH address? Or am I misunderstanding this flow?

One of the parties, or a coordinator, will aggregate the partial signatures and construct the full signature, which can then be placed in the spending transaction, which will make the spending transaction valid and broadcastable to the network.

> 3. **What Happens Without Commitments?** What could an adversary do if the commitments (ti) were not part of the protocol? What kind of attacks could occur, and how would they exploit the lack of commitments?

In MuSig1, without the first nonce-commitment phase, practical attacks are possible where an attacker starts multiple concurrent signing sessions with a victim, and succeeds in constructing a forged signature (for a message the attacker chooses, not agreed by the victims). In MuSig2, this phase does not exist anymore.

> **Comments:**
> **username_0**: thanks you so much for you answer.......   >"In MuSig1, without the first nonce-commitment phase, replay attacks are possible where participants can learn the private key of other participants. In MuSig2, this phase does not exist anymore".........     so commitments are not to prevent the rogue attack, but instead to prevent replay attack. can you tell me how these replay attacks can be performed to learn private key of other participants? or maybe giving me a reference from which I can learn more about? what's the link between a commitment and a private key  
> **username_2**: @username_0 You may want to look at section 2.1 "The Challenge of Constructing Two-Round Schemes" in the MuSig2 paper for a brief description of the attack against MuSig1 without the nonce-commitment phase.  
> **username_1**: @username_2 Thanks, I was confusing the replay attacks (which are possible when nonces are chosen predictably) with the concurrent signing attacks (which are possible without the nonce commitment in MuSig1). I have updated my answer.  
> **username_0**: @username_2 thanks for the answer, I've read that paragraph of that paper. One question though: how should I imagine, in a real world scenario, the fact that the adversary opens up k different signing sessions? Why should a victim allow that? Also, I thought that multi signatures were performed by passing the partial signature data across the users "manually" until the required number of user is reached, and at that point, the last user can send the final signature to the bitcoin network.... so how can I imagine this "k different signing sessions"? Is there a protocol/system to support that?  
> **username_0**: @username_1 I also tag you  
> **username_0**: also, why X aggregate is the product? Shouldn't it be a sum? The same for R*, shouldn't it be a sum? Is there a technological/performance/security reason why it's a multiplication and not a sum?  
> **username_1**: @username_0 A "session" in the MuSig2 sense is the time between the first and second round (i.e., the time while the victim needs to hold on to a private nonce whose public version has been shared with others). MuSig2 is secure even when a victim is participating in multiple such sessions at the same time. It doesn't matter how the partial nonces or signatures are shared; the concurrent attack just requires the attacker to have multiple at the same time, and being able to choose which ones to continue.  
> **username_1**: @username_0 The product vs. sum is just a notation issue. Some people write the group operation (for elliptic curves, point addition) as an addition, and its repetition (point multiplication) as a multiplication. Others use a multiplicative notation for the group operation and exponentiation for its repetition. Note that the latter is where the term "discrete logarithm" comes from; in the additive notation setting it ought to be called "discrete division". The MuSig2 paper uses multiplicative notation.  

---

