Author: Sebastian
Source: https://blog.bitbox.swiss/en/musig2-and-frost-explaining-multisignature-schemes-on-taproot/
In November 2021, the Taproot upgrade was activated on BTC through a soft fork, bringing some new features to BTC transactions and more efficient Schnorr signatures. Although the adoption rate increased slowly at first, currently, Taproot-style transaction outputs have already accounted for 20% of all unspent BTC transaction outputs, and more applications are beginning to use Taproot's advanced features. Of course, BitBoxApp and BitBox02 have supported sending funds to Taproot addresses and receiving funds with Taproot addresses since 2022.
In this article, we will look forward to new multisignature schemes (such as MuSig2 and FROST); these schemes will allow multisig wallets to benefit from the enhanced privacy and efficiency of Taproot wallets. To understand how they work and where these benefits come from, we will first briefly understand BTC scripts and Taproot, and then elaborate on these signature schemes.
[The rest of the translation follows the same professional and accurate approach, maintaining the technical terminology and style of the original text.]Signature Aggregation
The electronic signature scheme used in Taproot Script is the "Schnorr Signature", which has an interesting property called "linearity", because its signature result is easy to add, and can "aggregate" electronic signatures from multiple signers into a single signature.
Based on this principle, Bitcoin experts and cryptographers have derived an elegant multi-signature scheme. MuSig2 uses key aggregation and signature aggregation to enable n-of-n multisignature wallets (for example, the figure below shows a 4-of-4 multisignature wallet), without revealing any information about the pre-aggregation public keys and pre-aggregation signatures on the Bitcoin network.
Apart from those who participated in the signing process, no one can see that Alice, Bob, Satoshi, and Carol were involved in creating the signature. Not even can anyone see that this transaction comes from a multisignature wallet - because it is blended with other Taproot transactions, thus enhancing security. Such an aggregated signature transaction is the same size as a regular single-signature transaction, as there is no need to expose any pre-aggregation public keys; the reduced transaction volume benefits users with lower fees, and the BTC blockchain becomes more efficient.
Interactivity
But like other things in life, MuSig2 also has its sacrifices, which is the need for interaction between signers. In traditional multisignature wallets, signers only need to send out signatures, which become part of the final transaction, whereas in the MuSig2 scheme, these signers must communicate back and forth, more than once, to securely calculate the aggregated public key and aggregated signature.
The first version of MuSig required three rounds of interaction, and for security reasons, it had to be slightly adjusted, which is why its successor "MuSig2" is now more famous, requiring only two rounds of interaction. Of course, this brings complexity to users, although the privacy and transaction volume benefits may be enough to convince many users to overcome these inconveniences.
Another limitation of the n-of-n facility is that it cannot directly form a threshold mechanism (such as 2-of-3), which is what most multisignature wallet users want - to help them counter private key loss events. To add this security redundancy, additional script paths are needed to form "backup combinations" of different keys. This can essentially produce a mechanism with it, but also requires more complex scripts and setup. But you might have guessed, we have not exhausted all possibilities.
FROST
"Flexible and Optimal-Round Schnorr Threshold" protocol, abbreviated as "FROST", is another multi-signature protocol similar to MuSig2, at least from the perspective of creating and aggregating signatures. However, it uses a different key generation method, thereby supporting threshold mechanisms.
To securely use the threshold mechanism, allowing signatures from any 2 out of (for example) 4 predefined public keys to be aggregated into a valid signature, there are two choices for creating key fragments: (1) having a trusted participant generate and distribute public keys, which is a simpler solution but obviously requires trust between signers; (2) letting signing participants generate keys through an interactive process, usually called "Distributed Key Generation (DKG)", requiring a secure communication channel between signers.
In other words, the ability to add a set threshold also brings complexity, but also brings a more universal and more robust setup. Key path spending using the FROST protocol is no different from other Taproot transactions using the key path, thus providing better privacy - no one knows which signers participated in spending the funds.
Conclusion
If you don't think about these concepts in isolation, but imagine how they can be combined (and combined with other mechanisms), you'll find that the possibilities are almost endless. Users can fine-tune subset settings, such as adding time locks and recovery paths, just like BitBox02 with Liana Wallet can already do, allowing them to combine and benefit from the advanced schemes we've learned. Scaling solutions like the Lightning Network can also leverage schemes like MuSig to make channel management more efficient and private.
The benefits of MuSig2 and FROST basically increase with the complexity of wallet settings and the number of signers, making them very attractive to large enterprises with complex financial management requirements. But even for individual users, they can save on fees and gain better privacy. Both are still in very early stages, but Taproot and its benefits are long-term, so the adoption and user experience of signature schemes like MuSig2 and FROST will eventually catch up. We will continue to follow these developments and see if we can benefit BitBox users!
(End)
