Du kannst diesen Artikel auch auf Deutsch lesen.
Puoi leggere questo articolo anche in italiano.
More than three years ago, in November 2021, the Taproot update was soft forked into Bitcoin, bringing with it new features for transactions and more efficient Schnorr signatures. While adoption has been rather slow at first, the new Taproot format accounts for about 20% of all Bitcoin outputs today and more applications are starting to make use of Taproot’s more advanced features. Of course, the BitBoxApp and BitBox02 support sending and receiving with Taproot addresses since 2022 as well.
In this article, we want to take a glimpse into the future, at new multisignature schemes such as MuSig2 and FROST, which enable multisignature wallets that benefit from Taproot’s improved privacy and efficiency. To understand how they work and where their benefits actually come from, we’ll take a brief look at Bitcoin scripting and Taproot first, before diving into the signature schemes in more detail!
Bitcoin scripting
When you receive bitcoin, the sender creates a new output which locks bitcoin to a script – a technically accurate way of saying “they pay to your Bitcoin address”. A script in Bitcoin is a small and simple program that determines whether a transaction can be spent or not; which is exactly what every peer in the network checks when verifying transactions. For example, the default Native Segwit script (P2WPKH) makes sure a provided public key and digital signature match against an existing public key hash on the Bitcoin blockchain – and that’s it. To put it more simply: The script makes sure you have the right keys to the Bitcoin address.
However, there are more complex ways to use Bitcoin’s scripting capability by adding more spending conditions. One popular example of this are multisignature wallets, which require more than one signature to spend coins. When spending coins from a multisig address, this more complex script must be revealed as well, to prove your signatures are valid, but also to allow others to verify the address actually commits to them.
This current status quo of multisig wallets mainly has two downsides: First of all, it’s not ideal for privacy, because everyone can see the details of your setup (e.g. whether you use a 2-of-3, 3-of-5 or even more complicated approach). Secondly, the more spending conditions you add, the larger the script will get and the higher the transaction fee will be.
Key and script path spends
When spending coins from a Taproot address, there are two different paths to choose from: Key path and script path. Both have advantages in certain situations and enable more private and efficient transactions.
Key path spends
The default or “preferred” way of using Taproot are key path spends, which are actually quite easy to understand on their own: Taproot outputs contain a single public key and can be spent with a single signature. If you provide nothing but a signature when trying to spend a Taproot output, you just made a key path spend. For example, every regular transaction from a Taproot address created in the BitBoxApp is a key path spend.
Key path spends are great because they completely strip away all irrelevant information from the Bitcoin blockchain, requiring only a single public key and digital signature to work. This allows every Taproot transaction using key path spends to essentially look the same. You cannot tell the exact conditions that were necessary to create the signature – because there is no reason to. As long as the signature is valid, the transaction is valid. Whether there is a standard single-signature, multi-signature or even a Lightning channel behind it does not matter.
Script path spends
The second option is similar to the current status quo, where spending conditions are revealed and validated directly on the Bitcoin blockchain. They can be used as an alternative option to spend an output with, for example, if the usual conditions for a key path spend are not met. An example for such a usual condition may be your main hardware wallet, while an alternative option might be a backup key at a remote location, only needed when the regular hardware wallet can’t be accessed.
Script path spends on Taproot still offer benefits, however, because only parts of the spending conditions that were actually used have to be revealed. This again has potential for improved privacy and smaller transaction sizes, as not all details must be recorded on the Bitcoin blockchain – only the ones that are actually relevant.
The cool thing about Taproot is that we can do both! A Taproot output containing a single public key can be spent by either a single signature or by activating an alternative path in the script path. You may notice how the public key in a Taproot output must be quite an interesting construction in terms of the cryptography behind it, since it’s way more than “just a simple public key”. But we’re just getting started!
Can you hear the MuSig?
Now that we have a basic understanding of Bitcoin scripting and how the different spending paths work, we can finally dive deeper into different multisignature schemes and how they make use of Taproot’s features. In one of the previous sections, we already hinted at the ability to use a multisignature wallet “behind” a simple key path spend, but how is that possible? How can a single signature represent multiple signers?
Signature aggregation
Schnorr signatures, introduced with the Taproot update, have an appealing property called “linearity” which means that signatures can be easily added together, “aggregating” multiple signatures from different signers into a single one.
Based on this principle, Bitcoin experts and cryptographers came up with an elegant multisignature scheme. MuSig2 uses key and signature aggregation to enable n-of-n multisig wallets (e.g. 4-of-4 as shown in the graphic below) without having to reveal information about the individual signatures in the Bitcoin network.
Nobody outside this signing session knows that Alice, Bob, Satoshi and Carol all had to come together and create a signature together. Well, nobody even knows the transaction comes from a multisig wallet in the first place, improving the privacy by blending in with other Taproot transactions. The transaction has also the same size as a regular single-signature transaction, since none of the four individual keys or signatures are published, reducing the transaction fees and making Bitcoin more efficient.
Interactivity
Like most things in life, MuSig2 also comes with some trade-offs, which mainly boil down to interaction requirements between the signers. With traditional multisignature wallets, signers simply have to share the signatures, which are part of the final transaction, whereas in MuSig2, they have to communicate back and forth more than once to compute the aggregated keys and signatures securely.
The first iteration of MuSig required three rounds of interaction and had to be slightly tweaked for security reasons, which is why it’s now known under the name of its successor MuSig2, requiring only two rounds of communication. Still, it adds complexity for its users, even though the privacy and transaction size benefits are probably beneficial enough to overcome this inconvenience for many.
Another aspect is the limitation to n-of-n setups, with no ability to directly set a threshold (e.g. 2-of-3), like most users of multisig wallets prefer, to cover for the event of a lost key. To add more redundancy, additional script paths can be set for a “backup combination” of different keys. This would effectively introduce a threshold, but also require a more complicated script and setup on the flip side. But you may have guessed it, we’re not done yet!
FROST
The “Flexible Round-Optimized Schnorr Threshold Signature” protocol, or FROST for short, is another multisignature scheme similar to MuSig2, at least in terms of creating and aggregating signatures. However, it uses a different construction for generating the keys to enable thresholds.
In order to do this securely and allow, for example, any two signers in a 2-of-4 setup to produce a valid aggregated signature, there are essentially two options to create the key shares before signing: Option one is a trusted party generating and distributing the keys, which is a simple solution but obviously requires trust. The other option is to hold an interactive session between the signing parties to create the keys, also known as distributed key generation (DKG), which requires secure communication channels between the signers.
In other words, adding the ability to set a threshold adds complexity, but it also enables more versatile and redundant setups. A FROST key path spend would again look like any Taproot transaction, with the added privacy benefit that nobody knows which constellation of the available signers came together to spend the coins.
Conclusion
If you stop thinking about these concepts individually, but instead how they can be combined and used together with other mechanisms, the possibilities are almost endless. Users will be able to fine-tune their setups, e.g. with time locks and recovery paths, as already possible with Liana wallet and the BitBox02, while combining them and benefiting from the advanced schemes we just learned about. Scaling solutions such as the Lightning network can also make use of schemes like MuSig2 to make channel management more efficient and private.
The benefits of MuSig2 & FROST generally scale with the complexity of the wallet setup and the amount of individual signers, making them especially interesting for larger cooperations with more complex requirements. But even for personal use, they can be beneficial to save transaction fees and for a boost in privacy. It’s still quite early days, but Taproot and its benefits are here to stay, and the adoption and quality of user experience of multisignature schemes like MuSig2 and FROST are likely going to increase eventually. We’ll continuously look into these developments to see if and how they can benefit BitBox users as well!
Don’t own a BitBox yet?
Keeping your crypto secure doesn't have to be hard. The BitBox02 hardware wallet stores the private keys for your cryptocurrencies offline. So you can manage your coins safely.
The BitBox02 also comes in a Bitcoin-only version, featuring a radically focused firmware: less code means less attack surface, which further improves your security when only storing Bitcoin.
Shift Crypto is a privately-held company based in Zurich, Switzerland. Our team of Bitcoin contributors, crypto experts, and security engineers builds products that enable customers to enjoy a stress-free journey from novice to mastery level of cryptocurrency management. The BitBox02, our second generation hardware wallet, lets users store, protect, and transact Bitcoin and other cryptocurrencies with ease - along with its software companion, the BitBoxApp.