Summary
Schnorr Signatures is are extremely well researched improve the privacy of users whilst also helping with issues of scaling at the same time.
Currently, Cosmos SDK supports only ECDSA signatures. We started a work for adding ed25519. However it's not specified and lacking in depth analysis for batch verification, aggregation and specification for strickness for validation rules intended for consensus-critical contexts (--> tendermint issue for fixing it to provide guaranteess for cross-implementation consensus)
Background
Many Bitcoin derived blockchains use ECDSA for digital signatures. Schnorr Signatures algorithm patent was about to expire by the time Bitcoin paper was released. Now Schnorr is coming back to Bitocin with the MuSig update allowing better privacy and efficiency.
Problem Definition
ECDSA has a number of downsides compared to Schnorr signatures:
- Provable security: Schnorr signatures are provably secure. In more detail, they are strongly unforgeable under chosen message attack (SUF-CMA)
- There are claims saying that NSA used backdoor in ECDSA design.
- Non-malleability: The SUF-CMA security of Schnorr signatures implies that they are non-malleable. On the other hand, ECDSA signatures are inherently malleable[3]; a third party without access to the secret key can alter an existing valid signature for a given public key and message into another signature that is valid for the same key and message.
- Doesn't support aggregation.
- Doesn't support full privacy for multi-sign use-cases. With Schnorr Sig. we can combine all signatures and public keys in the transaction to a single key and a signature and nobody will find out that they correspond to multiple keys.
- Doesn't support batch verification.
Advantages of advanced Schnorr signatures
- Hidden feature: we can hide who signed the message
- Better UX than current multisig: no need to sign in a specific order
- Aggregated signatures (Schnorr aggregation) are more efficient: no need to attach a list of signatures: we have only one aggregated sig. So smaller size and faster verification
Proposal
Support Schnorr signatures for every use-case:
- simple signatures
- multisig
- coin-join scenarios (which is kind of double multisig).
Schnorr is extremely powerful for the privacy because we can make complex multi-sig transactions and even complex coinjoin transactions look like everyday normal transactions. This makes it difficult for chain analysis companies to analyse the transaction flows. In genera, aggregated signature scheme like Schnorr MuSig allows users to make a multisig output look like a standard user’s single sig output. This is a huge improvement compared to a normal multisig, where the users need to broadcast all of their public keys and signatures (requiring blockchain to validate and store it indefinitely. Instead, with a this proposal, the users do the enforcement themselves by constructing signatures between themselves resulting in a single final signature.
Benefits:
- Onchain transaction size is reduced allowing for more transaction throughput. Schnorr aggregated signatures have constant size (no matter how many signatures we aggregate).
- Better privacy for participants of a Multi-Signature wallets
- Transaction validate faster.
- Combat certain forms of spam attacks
Drawbacks:
- Schnorr aggregation requires interaction between parties (2+ rounds of communication).
How (proposal)
- 64-byte Schnorr signatures over the elliptic curve based on BIP:340. This specification addresses many security traps caused by wrong implementation (like Rogue Key Attack).
- Implement MuSig2 is effectively a key aggregation scheme developed by Blockstream. Earlier version, MuSig1 (algorithm description). This sheme uses Schnorr Signatures and is designed for Bitcoin. secp256k1-zkp noted that they are implementing MuSig2.
Alternative:
Notes:
Note about BLS
BLS is another elegant solution for private signatures and aggregation. It's more optimal for scenarios where we need to aggregate thousands than signatures (for smaller use-cases Schnorr is faster). The Achilles' heel of BLS is pairing function are complicated, and it can become our foe if we are not careful enough.
There is an attack on elliptic curve crypto systems, called MOV attack (named after Menezes, Okamoto, and Vanstone), that allows to reduce security of the system by using pairing functions.
TL;DR: if not needed, it's safer to use well researched Schnorr Signatures rather than BLS.
For Admin Use
Summary
Schnorr Signatures is are extremely well researched improve the privacy of users whilst also helping with issues of scaling at the same time.
Currently, Cosmos SDK supports only ECDSA signatures. We started a work for adding
ed25519. However it's not specified and lacking in depth analysis for batch verification, aggregation and specification for strickness for validation rules intended for consensus-critical contexts (--> tendermint issue for fixing it to provide guaranteess for cross-implementation consensus)Background
Many Bitcoin derived blockchains use ECDSA for digital signatures. Schnorr Signatures algorithm patent was about to expire by the time Bitcoin paper was released. Now Schnorr is coming back to Bitocin with the MuSig update allowing better privacy and efficiency.
Problem Definition
ECDSA has a number of downsides compared to Schnorr signatures:
Advantages of advanced Schnorr signatures
Proposal
Support Schnorr signatures for every use-case:
Schnorr is extremely powerful for the privacy because we can make complex multi-sig transactions and even complex coinjoin transactions look like everyday normal transactions. This makes it difficult for chain analysis companies to analyse the transaction flows. In genera, aggregated signature scheme like Schnorr MuSig allows users to make a multisig output look like a standard user’s single sig output. This is a huge improvement compared to a normal multisig, where the users need to broadcast all of their public keys and signatures (requiring blockchain to validate and store it indefinitely. Instead, with a this proposal, the users do the enforcement themselves by constructing signatures between themselves resulting in a single final signature.
Benefits:
Drawbacks:
How (proposal)
Alternative:
Notes:
Note about BLS
BLS is another elegant solution for private signatures and aggregation. It's more optimal for scenarios where we need to aggregate thousands than signatures (for smaller use-cases Schnorr is faster). The Achilles' heel of BLS is pairing function are complicated, and it can become our foe if we are not careful enough.
There is an attack on elliptic curve crypto systems, called MOV attack (named after Menezes, Okamoto, and Vanstone), that allows to reduce security of the system by using pairing functions.
TL;DR: if not needed, it's safer to use well researched Schnorr Signatures rather than BLS.
For Admin Use