Bitcoin Forum
May 05, 2024, 01:47:08 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: MuSig2: Simple Two-Round Schnorr Multi-Signatures  (Read 197 times)
achow101 (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6581


Just writing some code


View Profile WWW
October 14, 2020, 07:00:30 PM
Merited by gmaxwell (5), HCP (5), ABCbits (4), dkbit98 (3), DooMAD (2), fillippone (2), Carlton Banks (1), HeRetiK (1)
 #1

New paper from Jonas Nick, Tim Ruffing, and Yannick Seurin for a 2 round Schnorr Multisignature scheme based upon the original 3 round MuSig scheme.

Quote
Abstract: Multi-signatures enable a group of signers to produce a single signature on a given message. Recently, Drijvers et al. (S&P'19) showed that all thus far proposed two-round multi-signature schemes in the DL setting (without pairings) are insecure under concurrent sessions, i.e., if a single signer participates in multiple signing sessions concurrently. While Drijvers et al. improve the situation by constructing a secure two-round scheme, saving a round comes with the price of having less compact signatures. In particular, the signatures produced by their scheme are more than twice as large as Schnorr signatures, which arguably are the most natural and compact among all practical DL signatures and are therefore becoming popular in cryptographic applications (e.g., support for Schnorr signature verification has been proposed to be included in Bitcoin). If one needs a multi-signature scheme that can be used as a drop-in replacement for Schnorr signatures, then one is either forced to resort to a three-round scheme such as MuSig (Maxwell et al., DCC 2019) or MSDL-pop (Boneh, Drijvers, and Neven, ASIACRYPT 2018), or to accept that signing sessions are only secure when run sequentially, which may be hard to enforce in practice, e.g., when the same signing key is used by multiple devices.

In this work, we propose MuSig2, a novel and simple two-round multi-signature scheme variant of the MuSig scheme. Our scheme is the first multi-signature scheme that simultaneously i) is secure under concurrent signing sessions, ii) supports key aggregation, iii) outputs ordinary Schnorr signatures, iv) needs only two communication rounds, and v) has similar signer complexity as regular Schnorr signatures. Furthermore, our scheme is the first multi-signature scheme in the DL setting that supports preprocessing of all but one rounds, effectively enabling a non-interactive signing process, without forgoing security under concurrent sessions. The combination of all these features makes MuSig2 highly practical. We prove the security of MuSig2 under the one-more discrete logarithm (OMDL) assumption in the random oracle model, and the security of a more efficient variant in the combination of the random oracle and algebraic group models.

https://eprint.iacr.org/2020/1261

1714873628
Hero Member
*
Offline Offline

Posts: 1714873628

View Profile Personal Message (Offline)

Ignore
1714873628
Reply with quote  #2

1714873628
Report to moderator
"Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what." -- Greg Maxwell
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
NotATether
Legendary
*
Offline Offline

Activity: 1596
Merit: 6728


bitcoincleanup.com / bitmixlist.org


View Profile WWW
October 21, 2022, 02:25:35 PM
 #2

My apologies for bumping a really old thread, but I've just read in the paper that the whitepaper only takes into scope "n-of-n" multisig.

Does that mean that "m-of-n" multisigs (m < n) are impossible to achieve in MuSig2?

Would I be right in saying that this is not a supported configuration in MuSig1 either (though I remember reading otherwise around here... or maybe that was the case if you "emulated" m-of-n MuSigs with nCr(m,n) n-of-n Musig TapLeafs)?

.
.BLACKJACK ♠ FUN.
█████████
██████████████
████████████
█████████████████
████████████████▄▄
░█████████████▀░▀▀
██████████████████
░██████████████
████████████████
░██████████████
████████████
███████████████░██
██████████
CRYPTO CASINO &
SPORTS BETTING
▄▄███████▄▄
▄███████████████▄
███████████████████
█████████████████████
███████████████████████
█████████████████████████
█████████████████████████
█████████████████████████
███████████████████████
█████████████████████
███████████████████
▀███████████████▀
█████████
.
achow101 (OP)
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6581


Just writing some code


View Profile WWW
October 21, 2022, 04:06:46 PM
Merited by NotATether (2)
 #3

My apologies for bumping a really old thread, but I've just read in the paper that the whitepaper only takes into scope "n-of-n" multisig.

Does that mean that "m-of-n" multisigs (m < n) are impossible to achieve in MuSig2?

Would I be right in saying that this is not a supported configuration in MuSig1 either (though I remember reading otherwise around here...
Yes. All variants of MuSig are cryptographic multisigs, i.e. n-of-n is required. If you want a threshold signature (what we in Bitcoin call multisigs), you need a different scheme such as FROST.

or maybe that was the case if you "emulated" m-of-n MuSigs with nCr(m,n) n-of-n Musig TapLeafs)?
That was the suggestion.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!