<p>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:</p>

<ul>
<li><strong>Better privacy</strong>, 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)</li>
<li>Enabling <strong>simpler higher-level protocols</strong>, such as atomic swaps that are indistinguishable from normal payments. These can be used to build more efficient payment channel constructions.</li>
<li>Improving <strong>verification speed</strong>, by supporting batch validation of all signatures in a block at once (for a fraction of the speed of validating them individually).</li>
<li>Switching to a <strong>provably secure construction</strong>, perhaps preventing an exploit against ECDSA in the future.</li>
</ul>

<p>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:</p>

<ul>
<li>Public key recovery is incompatible with batch validation, and when ignoring batch validation it is (slightly) slower than normal validation on itself.</li>
<li>There may be patents that apply to public key recovery.</li>
<li>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).</li>
<li>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.</li>
</ul>

<p>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:</p>

<ol>
<li><strong>Linearity</strong>: the ability to jointly produce a signature for the sum of public keys (the basis for all Schnorr multisignature constructions).</li>
<li><strong>Lack of key malleability</strong>: 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)</li>
<li><strong>Public key recovery</strong>: the ability to reconstruct a public key from a signature and message.</li>
</ol>

<p>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.</p>

CC BY-SA 4.0
2018-07-16T15:39:14.853Z
Could you explain what linearity means in the context of ECDSA?
Lev Knoblock
CC BY-SA 4.0
2018-07-16T17:25:16.683Z
ECDSA 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
CC BY-SA 4.0
2019-06-05T13:38:09.097Z
@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
CC BY-SA 4.0
2019-06-05T14:32:49.300Z
@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
CC BY-SA 4.0
2021-05-20T21:28:41.370Z
@PieterWuille How fast is it to batch-validate a block with only Schnorr over a block with only ECDSA?
noɥʇʎԀʎzɐɹƆ
CC BY-SA 4.0
2021-05-20T21:30:43.497Z
Signature validation will probably be around a factor 2x faster, but block validation isn't just signatures, and the details depend on lot on the implementation. The ratio between single and batch validation used to be larger in libsecp256k1, but general performance improvements have reduced the benefit slightly (by benefiting single validation more than batch).
Pieter Wuille
CC BY-SA 4.0
2018-07-16T02:50:08.477Z
2018-07-16T07:41:12.140Z
2018-07-16T07:41:12.140Z
Pieter Wuille
<p>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.</p>
<p>With ECDSA, transactions can be signed &amp; 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).</p>
<p>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)?</p>

<multi-signature><transaction-verification><ecdsa><message-signing><schnorr-signatures>
What are the advantages of Schnorr vs ECDSA?
Lev Knoblock
# What are the advantages of Schnorr vs ECDSA?

(Asked by: username_0 on 2018-07-16)

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

**Tags:** multi-signature, transaction-verification, ecdsa, message-signing, schnorr-signatures


---

## 1 answers

### Answer by username_1 on 2018-07-16. Score: 23 | Accepted answer

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.

> **Comments:**
> **username_0**: Could you explain what linearity means in the context of ECDSA?  
> **username_1**: ECDSA 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.  
> **username_2**: @username_1 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)?  
> **username_1**: @username_2 Single (non batch) Schnorr verification is very close in performance to ECDSA. On reasonably recent hardware libsecp256k1 can verify over 10000 sigs/s.  
> **username_3**: @username_1 How fast is it to batch-validate a block with only Schnorr over a block with only ECDSA?  
> **username_1**: Signature validation will probably be around a factor 2x faster, but block validation isn't just signatures, and the details depend on lot on the implementation. The ratio between single and batch validation used to be larger in libsecp256k1, but general performance improvements have reduced the benefit slightly (by benefiting single validation more than batch).  

---

