What are the advantages of Schnorr vs ECDSA?

Question

I understand that Schnorr signatures provide an improvement on ECDSA in that they are a fixed 64 bytes instead of the longer ECDSA sig format, however, I don't see how this is an advantage over ECDSA in any situation except multisig.

With ECDSA, transactions can be signed & verified without needing to include the signer's pubkey in the message. However Schnorr (as described in the recent BIP) doesn't have that advantage, which means that for any transaction not from a multisig address, the necessary space to store all data necessary for verification would be 26 bytes cheaper under ECDSA (assuming a 64 byte Schnorr sig with a 33 byte compressed pubkey vs a ~71 byte ECDSA sig without a pubkey).

With regards to that, why is Schnorr receiving such focus? Do multisig transactions make up enough of Bitcoin's load that Schnorr would be that significant? And why has there been little to no focus on implementing transactions without storing pubkeys (which ethereum has been doing all along)?

Answer 1

Your question seems to assume that the only goal is minimizing on-chain transaction size. Reducing size and related costs is certainly something that can be improved upon, but it's far from the only thing. The primary advantages of the Schnorr proposal are:

• Better privacy, by making different multisig spending policies indistinguishable on chain. When combined with Taproot, this extends to pretty much all cooperative executions of contracts (which become just a single signature on-chain, regardless of complexity or number of participants)
• Enabling simpler higher-level protocols, such as atomic swaps that are indistinguishable from normal payments. These can be used to build more efficient payment channel constructions.
• Improving verification speed, by supporting batch validation of all signatures in a block at once (for a fraction of the speed of validating them individually).
• Switching to a provably secure construction, perhaps preventing an exploit against ECDSA in the future.

As far as your specific suggestion of using public key recovery to avoid publishing the public key in a spend goes, there are some arguments against:

• Public key recovery is incompatible with batch validation, and when ignoring batch validation it is (slightly) slower than normal validation on itself.
• There may be patents that apply to public key recovery.
• The same size savings can be accomplished more simply by using pay-to-pubkey instead of pay-to-pubkeyhash (again, when combined with Taproot this advantage extends to scripts as well as single key constructions).
• Longer term cross-input signature aggregation holds much better potential size savings by reducing the total number of signatures per transaction (not just transaction input) to 1. Cross-input aggregation is also incompatible with public key recovery, though this isn't currenty included in the Schnorr proposal.

Also note that the lack of public key recovery isn't inherent to Schnorr - it is a result of choosing key-prefixed Schnorr. It's better to see it as a tradeoff between 3 properties:

1. Linearity: the ability to jointly produce a signature for the sum of public keys (the basis for all Schnorr multisignature constructions).
2. Lack of key malleability: with key malleability it is possible to take a signature for an existing public key and turn it into a signature for a related key (for example, one in the same BIP32 tree)
3. Public key recovery: the ability to reconstruct a public key from a signature and message.

Key-prefixed Schnorr lacks public key recovery. Non key-prefixed Schnorr suffers from key malleability. ECDSA lacks linearity. It doesn't seem possible to construct a signature scheme that has all three.