Schnorr vs ECDSA

9

2

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)?

Lev Knoblock

Posted 2018-07-16T02:20:06.560

Reputation: 93

Answers

15

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.

Pieter Wuille

Posted 2018-07-16T02:20:06.560

Reputation: 54 032

@PieterWuille Do you happen to know how fast is Schnorr vs ECDSA in terms of verifications per second? Albert Casademont says (https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/#comment-1279759097) that: rsa 2048 bits 34423.4 verify/s and 256 bit ecdsa (nistp256) 4500.6 verify/s. What can we expect from Schnorr here (roughly)?

– Martin Vseticka – 2019-06-05T13:38:09.097

1@Martin Single (non batch) Schnorr verification is very close in performance to ECDSA. On reasonably recent hardware libsecp256k1 can verify over 10000 sigs/s. – Pieter Wuille – 2019-06-05T14:32:49.300

Could you explain what linearity means in the context of ECDSA? – Lev Knoblock – 2018-07-16T15:39:14.853

2ECDSA is not linear. Schnorr is: the signature verification equation is sG = R + H(R,P,m)P. Two people can come up with their own R1 and R2, and if they then produce signatures s1 and s2 that satisfy the equation s1G = R1 + H(R1+R2,P,m)P1, and then add up s = s1 + s2, the result satisfies sG = R + H(R,P,M)(P1+P2); i.e. it's a valid signature for the sum of the keys. Such a construction is only possible due to the equation being linear in all signer variables: s = k + H(R,P,m)x (with k = nonce, x = private key). For ECDSA it is sk = m + rx. The multiplication s*k breaks linearity. – Pieter Wuille – 2018-07-16T17:25:16.683

Asked: 2018-07-16T02:20:06.560

Viewed: 1 549 times

Active: 2019-05-07T14:09:35.973