<p>Yes you can do public key recovery with EC Schnorr. Consider</p>

<pre><code>R = kG, [r = R.x, s = k + H(r, m)d], Q = dG
</code></pre>

<p>verify:</p>

<pre><code>sG = ?R + H(r, m)Q
</code></pre>

<p>recovery:</p>

<pre><code>sG = kG + H(r, m) dG = R + H(r, m)Q
</code></pre>

<p>so</p>

<pre><code>Q = 1 / H(r, m) * (sG - R).
</code></pre>

<p>(And to compute <code>R</code> from <code>r</code> if <code>R</code> is point-compressed, <code>R = (r,f(r)) R' = (r,-f(r))</code> and try both <code>R</code> and <code>R'</code> by checking if the signature is valid with the resultant public key).</p>

CC BY-SA 4.0
2019-02-20T13:17:42.347Z
but you [can't do key recovery with BIP-Schnorr](https://crypto.stackexchange.com/a/60828/12089)
Janus Troelsen
CC BY-SA 3.0
2015-04-16T03:06:46.377Z
2015-07-08T09:30:49.457Z
2015-07-08T09:30:49.457Z
Adam Back
<p>The primary design goal for DSA was to avoid infringing the Schnorr patent.  Now that the patent has expired, there aren't really any good mathematical reasons to go with DSA.  With Schnorr, the algorithm and analysis are simpler and often more efficient.  It's also easier to split Schnorr private keys, create threshold variants, etc.  However, DSA and ECDSA are standards, and have been for a while.  As a result, library implementations are everywhere.  You can find hardware security module support, etc.  Someday the same will hold of either Ed25519 or some other Schnorr variant.  People are unlikely to standardize new DSA variants.  But for the moment ECDSA is still the algorithm to use if you want something standard and widely supported.</p>

CC BY-SA 3.0
2015-04-16T06:06:23.217Z
2015-04-16T06:06:23.217Z
user3188445
<p>Warning: I've never actually worked with the Schnorr signature scheme.  The
following is my analysis based on reading the <a href="https://en.wikipedia.org/wiki/Schnorr_signature" rel="nofollow noreferrer">Wikipedia
article</a>, the <a href="http://ed25519.cr.yp.to/" rel="nofollow noreferrer">ed25519
page</a>, and some discussions between devs in
<a href="https://en.bitcoin.it/wiki/IRC_channels" rel="nofollow noreferrer">#bitcoin-dev</a>.</p>
<h2>Likely Changes</h2>
<ol>
<li><p><strong>Changed op code behavior:</strong> we will need an op code to check
Schnorr signatures. With a hard fork, we can redefine
<a href="https://en.bitcoin.it/wiki/OP_CHECKSIG" rel="nofollow noreferrer"><code>op_checksig</code></a> and
<code>op_checksigverify</code> to also check Schnorr signatures. With a soft
fork, we can redefine one of the <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">reserved no-op op codes</a> to check
Schnorr signatures.</p>
</li>
<li><p><strong>Increased P2SH usage (maybe):</strong> I think it's highly unlikely
that a new address format will be introduced to do the same thing
for pubkey scripts paying Schnorr public keys that
<a href="https://bitcoin.org/en/developer-guide#term-p2pkh" rel="nofollow noreferrer">P2PKH</a> does for
ECDSA public keys. That means people who want an address to use
Schnorr even with just one key (non-multisig) will have to use
P2SH. Of course, for applications that don't need addresses (like for
mining or when using the
<a href="https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki" rel="nofollow noreferrer">BIP70</a>
payment protocol), they can just use <code>op_checksigverify_schnorr</code> (or
whatever) directly in their <a href="https://bitcoin.org/en/developer-guide#term-pubkey-script" rel="nofollow noreferrer">pubkey scripts</a>.</p>
</li>
<li><p><strong>Smaller multisig transactions:</strong> one of the most widely touted
advantages of the Schnorr scheme is that it can allow multiple
signers to combine their signatures into a single signature which can
be authenticated against a single public key created by all the
authorized parties. This accomplishes the same thing current Bitcoin
multisig does but uses fewer bytes. This may be especially useful if
dozens or hundreds of signatures are required, such as in a
crowdfunding situation.  Note: if I understand correctly, this is
also possible also with ECDSA, but in a less flexible way. (2018 note: there's now a paper out that details how to do <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf" rel="nofollow noreferrer">script-less scripts on ECDSA</a>, including 2-of-2 multisig)</p>
</li>
<li><p><strong>Slightly smaller for all transactions:</strong> assuming Bitcoin uses the
<a href="http://ed25519.cr.yp.to/" rel="nofollow noreferrer">ed25519</a> curve, which has a similar key
strength to the <a href="https://en.bitcoin.it/wiki/Secp256k1" rel="nofollow noreferrer">secp256k1</a> ECDSA curve Bitcoin currently uses,
compressed Schnorr public keys and signatures will be (respectively)
32 bytes and up to 64 bytes compared to current compressed Bitcoin
secp256k1 public keys and (non-compressed) signatures that are 33
bytes and up to 75 bytes.</p>
</li>
<li><p><strong>Plausible deniability for multisig:</strong> using Schnorr <a href="https://en.wikipedia.org/wiki/Threshold_cryptosystem" rel="nofollow noreferrer">threshold
signatures</a> it
may be easier to prevent multiple signers or third-parties from knowing who else
signed or didn't sign. That's because the individual signatures are
merged into a unified signature that doesn't directly reveal who
signed it. This can be used in situations where the signers are
afraid of reprisals for spending funds in a particular way.</p>
</li>
<li><p><strong>Plausible deniability of authorized parties</strong> using a
third-party organizer (which doesn't need to be trusted with private
keys), it's possible to prevent signers from knowing whether their
private key is part of the set of signing keys. Although not
directly relevant to Bitcoin transactions, I seem to recall[1] Greg
Maxwell saying he'd like to see this property used for distributed
forum moderation: choose a bunch of senior forum members, get a
public key from each of them, create a threshold public key from
some of the individual public keys, and then let individuals submit
a signature when they think a post should be removed. The
third-party organizer (probably an automated program) will combine
the signatures without leaking whose signature actually contributed
towards meeting the threshold. If nobody knows whose signature
actually matters and the pool of possible moderators is large,
effective reprisals against moderators become very expensive. [1]: #bitcoin IRC about 4 months ago; unfortunately that chatroom is not
publicly logged.</p>
</li>
<li><p><strong>Theoretical better security properties:</strong> the experts agree general
Schnorr signatures have <a href="https://en.wikipedia.org/wiki/Schnorr_signature#Security_argument" rel="nofollow noreferrer">better theoretical security
properties</a>
than equivalent ECDSA signatures. The most notable of these
improvements is that the hash function used in Schnorr doesn't need
to be as collision resistant as the hash function used in ECDSA.
(Bitcoin would likely use the same hash function for Schnorr that it
uses for ECDSA: SHA256.) Also, the ed25519 page linked above
describes several ways it is resistant to side-channel attacks, which
can allow hardware wallets to operate safely in less secure
environments.</p>
</li>
<li><p><strong>Faster signature verification:</strong> it likely takes fewer CPU cycles
to verify an ed25519 Schnorr signature than a secp256k1 ECDSA
signature. This is probably only a tiny improvement for Bitcoin:
Bitcoin Core verifies signatures before adding a transaction to its
mempool. When a block is received containing transactions already in
the local mempol, Bitcoin Core does not re-verify those transactions,
so as long as the local node and the mining node have identical
mempools, no signature verifications need to be performed. (Recall the
coinbase transaction doesn't have a signature.) However, signature
verification is currently a bounding factor for nodes during initial
blockchain download (assuming a high-speed connection and Bitcoin
Core 0.10.0), so &quot;faster would be better.&quot;</p>
</li>
<li><p><strong>Multi-crypto multisig:</strong> with two (slightly) different
cryptosystems to choose from, high-security users can create 2-of-2
multisig pubkey scripts that require both ECDSA and Schnorr
signatures, so their bitcoins can't be stolen if only one
cryptosystem is broken.  Unless we hardfork in Schnorr (see point #1),
they won't be able to use standard op_checkmultisig---but they can do
something like <code>&lt;ecdsa pubkey&gt; OP_CHECKSIGVERIFY &lt;schnorr pubkey&gt; OP_CHECKSIGVERIFY_SCHNORR</code></p>
</li>
</ol>
<h2>Uncertainties (To Me)</h2>
<ol start="10">
<li><strong>Maybe changed TXIDs:</strong> I'm not familiar enough with Schnorr
signatures to know how they might be malleable (changeable by
third-parties without invalidating them), but crypto expert <a href="http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02939.html" rel="nofollow noreferrer">Adam Back seems to think</a> they'd be pretty malleable. His solution would be to change how <a href="https://bitcoin.org/en/developer-guide#term-txid" rel="nofollow noreferrer">TXIDs</a> are calculated from <code>hash(&lt;whole transaction&gt;)</code> to <code>hash(&lt;almost everything except the signature&gt;)</code>.  This would fix some current <a href="https://bitcoin.org/en/developer-guide#transaction-malleability" rel="nofollow noreferrer">malleability</a>-based problems, such as slow <a href="https://bitcoin.org/en/developer-guide#micropayment-channel" rel="nofollow noreferrer">micropayment channel</a> creation, but it also be a major hard fork that affects effectively all Bitcoin software.  The last fork of that scale---the soft-fork <a href="https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki" rel="nofollow noreferrer">P2SH implementation</a>---still doesn't have support for it from all Bitcoin programs after three years of discussion, two years of implementation, and fairly widespread use.</li>
</ol>

<ul>
<li><strong>Public key recovery from signatures:</strong> I don't know whether a Schnorr public key can be recovered from a Schnorr signature the way an ECDSA pubkey can be recovered from an ECDSA signature.  This could be important: the Bitcoin Core <a href="https://bitcoin.org/en/developer-reference#verifymessage" rel="nofollow noreferrer"><code>verifymessage</code> RPC</a> uses key recovery to verify messages signed with the <a href="https://bitcoin.org/en/developer-reference#signmessage" rel="nofollow noreferrer"><code>signmessage</code> RPC</a> or by another client's sign message implementation.  (Note: this point left unnumbered because it was added after the original posting.)</li>
</ul>
<h2>Non-Changes</h2>
<p>Just to be clear, here are some things that don't change.</p>
<ol start="11">
<li><p><strong>Deterministic signatures:</strong> there has been a drive towards
<a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">deterministic ECDSA signatures</a>
in Bitcoin software. For example, Bitcoin Core will begin using them
in the upcoming 0.10.0 release. Schnorr signatures can also be
generated deterministically. With deterministic signatures, you
don't need a high-quality source of entropy (randomness) to create
secure signatures. However, you do still need high-quality entropy
to generate private keys or root seeds (see point below).</p>
</li>
<li><p><strong>HD wallets:</strong> it looks to me like the <a href="https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation" rel="nofollow noreferrer">hierarchical deterministic
(HD) key generation
protocol</a>
will work for Schnorr key pairs with a few small modifications. You
can even use the same root seed for both ECDSA and Schnorr
hierarchies.</p>
</li>
<li><p><strong>Key (address) reuse:</strong> as with properly-implemented ECDSA, it's
possible to securely create multiple Schnorr signatures for different
transactions, meaning it's secure to receive multiple outputs to the
same address or public key. This is in contrast to
<a href="https://en.wikipedia.org/wiki/Merkle_signature_scheme" rel="nofollow noreferrer">some signature
schemes</a> which
only allow you to securely use a one signature per public key.  However, key reuse
can still be less secure than using unique keys for each transaction,
and key reuse will always be much less private for you and your
trading partners.</p>
</li>
</ol>
<h2>Priority</h2>
<p>Just as a matter of my opinion: Schnorr seems to provide some nice
advantages over ECDSA for power users, but nobody seems to be begging
for those features---so adding Schnorr signatures is probably low
priority. I'd guess that Schnorr signature support might be one of the
first improvements that will be fully tested in a <a href="http://blockstream.com/sidechains.pdf" rel="nofollow noreferrer">sidechain (PDF
link)</a> before being ported back
to Bitcoin.</p>
<p>P.S. Sorry for the long post, but thanks for asking such a fun question!</p>

CC BY-SA 3.0
2015-01-08T19:30:46.863Z
Do Schnorr signatures support public key recovery from the signature? And are you saying in 13 that Schnorr signatures would be more quantum-safe?
morsecoder
CC BY-SA 3.0
2015-01-08T20:01:07.233Z
@StephenM347 good questions!  I don't know about key recovery; I'll try to do some research.  Schnorr ed25519 is definitely not significantly more quantum safe than ECDSA secp256k1---they're both based on the difficulty of a discrete logarithm problem and are both susceptible to [Shor's quantum factorization algorithm](https://en.wikipedia.org/wiki/Shor%27s_Algorithm); I'll edit that point to make it more clear.  Thanks!
David A. Harding
CC BY-SA 3.0
2015-01-08T20:17:56.553Z
Thanks. And that's what I figured with regards to Schnorr signatures being quantum safe, just wasn't sure if that's what you were saying.
morsecoder
CC BY-SA 3.0
2016-02-02T21:32:59.977Z
RE:  "fix some current malleability-based problems, such as slow micropayment channel creation, but it also be a major hard fork" ... SegWit is a soft fork, and does the same thing, so if you do SeqWit first, or at the same time, you eliminate malleability issues - no hard fork needed.
Erik Aronesty
CC BY-SA 3.0
2016-07-01T13:10:43.063Z
Bitcoin Core has written a post on segwit that covers some Schnorr stuff too: https://bitcoincore.org/en/2016/06/24/segwit-next-steps/ Including some stuff not mentioned in this post, like signature aggregation and its use with coinjoin.
Janus Troelsen
CC BY-SA 3.0
2016-12-01T03:49:27.033Z
How does Ed25519 multi sign work? Can't seem to find any references on it.
Yangrui
CC BY-SA 3.0
2017-07-05T11:04:03.163Z
Would it make sense to also mention cancellation/de-linearization?
Janus Troelsen
CC BY-SA 4.0
2018-08-26T01:21:10.440Z
A lot has changed since this answer was written.  Now that we have SegWit, item # 10 is a non-issue. Also appears item # 1 is a non-issue as Bitcoin script can be upgraded via softfork, correct?  Also seems that sepc256k1 is [considered faster](https://www.reddit.com/r/Bitcoin/comments/7dabe3/why_does_bitcoin_use_ecsda_instead_of_ed25519/dpwauak/) than ed25519, so there doesn't seem to be discussion on changing that.
Jonathan Cross
CC BY-SA 4.0
2015-01-08T00:39:17.757Z
2018-06-13T18:07:07.967Z
2021-10-07T07:05:27.390Z
David A. Harding
<p><a href="https://bitcointalk.org/index.php?topic=511074.msg5727641#msg5727641" rel="nofollow noreferrer">Adam Back (adam3us) explained in March, 2014</a>, but it is all math. There's <a href="https://sourceforge.net/p/bitcoin/mailman/message/31505652/" rel="nofollow noreferrer">another short post with advantages</a>, though.</p>

<p><a href="https://crypto.stackexchange.com/a/5959/12089">This answer</a> on crypto.SE claims that Bitcoin considered using Ed25519 which is based on Schnorr signatures, but decided against it. Even if it is not going to get used, I'd still like to know the implications.</p>

<p>There's <a href="https://github.com/bitcoin/secp256k1/pull/212" rel="nofollow noreferrer">a pull request adding them to libsecp256k1</a>. [edit 2019: that pull request used a <a href="https://github.com/bitcoin-core/secp256k1/pull/425" rel="nofollow noreferrer">flawed approach</a>]</p>

<p>Gavin mentioned them on <a href="http://www.reddit.com/r/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/clfp3xj" rel="nofollow noreferrer">his wish-list for Bitcoin</a>.</p>

CC BY-SA 3.0
2017-06-24T12:15:54.940Z
[advantages listed by the Elements project](https://www.elementsproject.org/elements/schnorr-signatures/)
Janus Troelsen
CC BY-SA 3.0
2017-06-30T14:06:16.770Z
it also enables a more efficient [Lightning Network](https://lists.launchpad.net/mimblewimble/msg00086.html)
Janus Troelsen
CC BY-SA 3.0
2017-07-11T09:19:15.010Z
[non-interactive partial aggregation](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html)
Janus Troelsen
CC BY-SA 4.0
2018-08-01T13:13:48.340Z
See also https://bitcoin.stackexchange.com/a/77235/3347
Janus Troelsen
<signature><multi-signature><gavin-andresen><schnorr-signatures>
What are the implications of Schnorr signatures?
Janus Troelsen
# What are the implications of Schnorr signatures?

(Asked by: username_0 on 2015-01-05)

[username_1 (adam3us) explained in March, 2014](https://bitcointalk.org/index.php?topic=511074.msg5727641#msg5727641), but it is all math. There's [another short post with advantages](https://sourceforge.net/p/bitcoin/mailman/message/31505652/), though.

[This answer](https://crypto.stackexchange.com/a/5959/12089) on crypto.SE claims that Bitcoin considered using Ed25519 which is based on Schnorr signatures, but decided against it. Even if it is not going to get used, I'd still like to know the implications.

There's [a pull request adding them to libsecp256k1](https://github.com/bitcoin/secp256k1/pull/212). [edit 2019: that pull request used a [flawed approach](https://github.com/bitcoin-core/secp256k1/pull/425)]

Gavin mentioned them on [his wish-list for Bitcoin](http://www.reddit.com/r/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/clfp3xj).

**Tags:** signature, multi-signature, gavin-andresen, schnorr-signatures

> **Comments:**
> **username_0**: [advantages listed by the Elements project](https://www.elementsproject.org/elements/schnorr-signatures/)  
> **username_0**: it also enables a more efficient [Lightning Network](https://lists.launchpad.net/mimblewimble/msg00086.html)  
> **username_0**: [non-interactive partial aggregation](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html)  
> **username_0**: See also https://bitcoin.stackexchange.com/a/77235/3347  

---

## 3 answers

### Answer by username_3 on 2015-01-08. Score: 37 | Accepted answer

Warning: I've never actually worked with the Schnorr signature scheme. The
following is my analysis based on reading the [Wikipedia
article](https://en.wikipedia.org/wiki/Schnorr_signature), the [ed25519
page](http://ed25519.cr.yp.to/), and some discussions between devs in
[#bitcoin-dev](https://en.bitcoin.it/wiki/IRC_channels).

## Likely Changes

1. **Changed op code behavior:** we will need an op code to check
   Schnorr signatures. With a hard fork, we can redefine
   [`op_checksig`](https://en.bitcoin.it/wiki/OP_CHECKSIG) and
   `op_checksigverify` to also check Schnorr signatures. With a soft
   fork, we can redefine one of the [reserved no-op op codes](https://en.bitcoin.it/wiki/Script) to check
   Schnorr signatures.
2. **Increased P2SH usage (maybe):** I think it's highly unlikely
   that a new address format will be introduced to do the same thing
   for pubkey scripts paying Schnorr public keys that
   [P2PKH](https://bitcoin.org/en/developer-guide#term-p2pkh) does for
   ECDSA public keys. That means people who want an address to use
   Schnorr even with just one key (non-multisig) will have to use
   P2SH. Of course, for applications that don't need addresses (like for
   mining or when using the
   [BIP70](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki)
   payment protocol), they can just use `op_checksigverify_schnorr` (or
   whatever) directly in their [pubkey scripts](https://bitcoin.org/en/developer-guide#term-pubkey-script).
3. **Smaller multisig transactions:** one of the most widely touted
   advantages of the Schnorr scheme is that it can allow multiple
   signers to combine their signatures into a single signature which can
   be authenticated against a single public key created by all the
   authorized parties. This accomplishes the same thing current Bitcoin
   multisig does but uses fewer bytes. This may be especially useful if
   dozens or hundreds of signatures are required, such as in a
   crowdfunding situation. Note: if I understand correctly, this is
   also possible also with ECDSA, but in a less flexible way. (2018 note: there's now a paper out that details how to do [script-less scripts on ECDSA](https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf), including 2-of-2 multisig)
4. **Slightly smaller for all transactions:** assuming Bitcoin uses the
   [ed25519](http://ed25519.cr.yp.to/) curve, which has a similar key
   strength to the [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) ECDSA curve Bitcoin currently uses,
   compressed Schnorr public keys and signatures will be (respectively)
   32 bytes and up to 64 bytes compared to current compressed Bitcoin
   secp256k1 public keys and (non-compressed) signatures that are 33
   bytes and up to 75 bytes.
5. **Plausible deniability for multisig:** using Schnorr [threshold
   signatures](https://en.wikipedia.org/wiki/Threshold_cryptosystem) it
   may be easier to prevent multiple signers or third-parties from knowing who else
   signed or didn't sign. That's because the individual signatures are
   merged into a unified signature that doesn't directly reveal who
   signed it. This can be used in situations where the signers are
   afraid of reprisals for spending funds in a particular way.
6. **Plausible deniability of authorized parties** using a
   third-party organizer (which doesn't need to be trusted with private
   keys), it's possible to prevent signers from knowing whether their
   private key is part of the set of signing keys. Although not
   directly relevant to Bitcoin transactions, I seem to recall[1] Greg
   Maxwell saying he'd like to see this property used for distributed
   forum moderation: choose a bunch of senior forum members, get a
   public key from each of them, create a threshold public key from
   some of the individual public keys, and then let individuals submit
   a signature when they think a post should be removed. The
   third-party organizer (probably an automated program) will combine
   the signatures without leaking whose signature actually contributed
   towards meeting the threshold. If nobody knows whose signature
   actually matters and the pool of possible moderators is large,
   effective reprisals against moderators become very expensive. [1]: #bitcoin IRC about 4 months ago; unfortunately that chatroom is not
   publicly logged.
7. **Theoretical better security properties:** the experts agree general
   Schnorr signatures have [better theoretical security
   properties](https://en.wikipedia.org/wiki/Schnorr_signature#Security_argument)
   than equivalent ECDSA signatures. The most notable of these
   improvements is that the hash function used in Schnorr doesn't need
   to be as collision resistant as the hash function used in ECDSA.
   (Bitcoin would likely use the same hash function for Schnorr that it
   uses for ECDSA: SHA256.) Also, the ed25519 page linked above
   describes several ways it is resistant to side-channel attacks, which
   can allow hardware wallets to operate safely in less secure
   environments.
8. **Faster signature verification:** it likely takes fewer CPU cycles
   to verify an ed25519 Schnorr signature than a secp256k1 ECDSA
   signature. This is probably only a tiny improvement for Bitcoin:
   Bitcoin Core verifies signatures before adding a transaction to its
   mempool. When a block is received containing transactions already in
   the local mempol, Bitcoin Core does not re-verify those transactions,
   so as long as the local node and the mining node have identical
   mempools, no signature verifications need to be performed. (Recall the
   coinbase transaction doesn't have a signature.) However, signature
   verification is currently a bounding factor for nodes during initial
   blockchain download (assuming a high-speed connection and Bitcoin
   Core 0.10.0), so "faster would be better."
9. **Multi-crypto multisig:** with two (slightly) different
   cryptosystems to choose from, high-security users can create 2-of-2
   multisig pubkey scripts that require both ECDSA and Schnorr
   signatures, so their bitcoins can't be stolen if only one
   cryptosystem is broken. Unless we hardfork in Schnorr (see point #1),
   they won't be able to use standard op\_checkmultisig---but they can do
   something like  `OP_CHECKSIGVERIFY  OP_CHECKSIGVERIFY_SCHNORR`

## Uncertainties (To Me)

10. **Maybe changed TXIDs:** I'm not familiar enough with Schnorr
    signatures to know how they might be malleable (changeable by
    third-parties without invalidating them), but crypto expert [username_1 seems to think](http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02939.html) they'd be pretty malleable. His solution would be to change how [TXIDs](https://bitcoin.org/en/developer-guide#term-txid) are calculated from `hash()` to `hash()`. This would fix some current [malleability](https://bitcoin.org/en/developer-guide#transaction-malleability)-based problems, such as slow [micropayment channel](https://bitcoin.org/en/developer-guide#micropayment-channel) creation, but it also be a major hard fork that affects effectively all Bitcoin software. The last fork of that scale---the soft-fork [P2SH implementation](https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki)---still doesn't have support for it from all Bitcoin programs after three years of discussion, two years of implementation, and fairly widespread use.

* **Public key recovery from signatures:** I don't know whether a Schnorr public key can be recovered from a Schnorr signature the way an ECDSA pubkey can be recovered from an ECDSA signature. This could be important: the Bitcoin Core [`verifymessage` RPC](https://bitcoin.org/en/developer-reference#verifymessage) uses key recovery to verify messages signed with the [`signmessage` RPC](https://bitcoin.org/en/developer-reference#signmessage) or by another client's sign message implementation. (Note: this point left unnumbered because it was added after the original posting.)

## Non-Changes

Just to be clear, here are some things that don't change.

11. **Deterministic signatures:** there has been a drive towards
    [deterministic ECDSA signatures](https://www.rfc-editor.org/rfc/rfc6979)
    in Bitcoin software. For example, Bitcoin Core will begin using them
    in the upcoming 0.10.0 release. Schnorr signatures can also be
    generated deterministically. With deterministic signatures, you
    don't need a high-quality source of entropy (randomness) to create
    secure signatures. However, you do still need high-quality entropy
    to generate private keys or root seeds (see point below).
12. **HD wallets:** it looks to me like the [hierarchical deterministic
    (HD) key generation
    protocol](https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation)
    will work for Schnorr key pairs with a few small modifications. You
    can even use the same root seed for both ECDSA and Schnorr
    hierarchies.
13. **Key (address) reuse:** as with properly-implemented ECDSA, it's
    possible to securely create multiple Schnorr signatures for different
    transactions, meaning it's secure to receive multiple outputs to the
    same address or public key. This is in contrast to
    [some signature
    schemes](https://en.wikipedia.org/wiki/Merkle_signature_scheme) which
    only allow you to securely use a one signature per public key. However, key reuse
    can still be less secure than using unique keys for each transaction,
    and key reuse will always be much less private for you and your
    trading partners.

## Priority

Just as a matter of my opinion: Schnorr seems to provide some nice
advantages over ECDSA for power users, but nobody seems to be begging
for those features---so adding Schnorr signatures is probably low
priority. I'd guess that Schnorr signature support might be one of the
first improvements that will be fully tested in a [sidechain (PDF
link)](http://blockstream.com/sidechains.pdf) before being ported back
to Bitcoin.

P.S. Sorry for the long post, but thanks for asking such a fun question!

> **Comments:**
> **username_4**: Do Schnorr signatures support public key recovery from the signature? And are you saying in 13 that Schnorr signatures would be more quantum-safe?  
> **username_3**: @StephenM347 good questions!  I don't know about key recovery; I'll try to do some research.  Schnorr ed25519 is definitely not significantly more quantum safe than ECDSA secp256k1---they're both based on the difficulty of a discrete logarithm problem and are both susceptible to [Shor's quantum factorization algorithm](https://en.wikipedia.org/wiki/Shor%27s_Algorithm); I'll edit that point to make it more clear.  Thanks!  
> **username_4**: Thanks. And that's what I figured with regards to Schnorr signatures being quantum safe, just wasn't sure if that's what you were saying.  
> **username_5**: RE:  "fix some current malleability-based problems, such as slow micropayment channel creation, but it also be a major hard fork" ... SegWit is a soft fork, and does the same thing, so if you do SeqWit first, or at the same time, you eliminate malleability issues - no hard fork needed.  
> **username_0**: Bitcoin Core has written a post on segwit that covers some Schnorr stuff too: https://bitcoincore.org/en/2016/06/24/segwit-next-steps/ Including some stuff not mentioned in this post, like signature aggregation and its use with coinjoin.  
> **username_6**: How does Ed25519 multi sign work? Can't seem to find any references on it.  
> **username_0**: Would it make sense to also mention cancellation/de-linearization?  
> **username_7**: A lot has changed since this answer was written.  Now that we have SegWit, item # 10 is a non-issue. Also appears item # 1 is a non-issue as Bitcoin script can be upgraded via softfork, correct?  Also seems that sepc256k1 is [considered faster](https://www.reddit.com/r/Bitcoin/comments/7dabe3/why_does_bitcoin_use_ecsda_instead_of_ed25519/dpwauak/) than ed25519, so there doesn't seem to be discussion on changing that.  

---

### Answer by username_1 on 2015-04-16. Score: 9

Yes you can do public key recovery with EC Schnorr. Consider
R = kG, [r = R.x, s = k + H(r, m)d], Q = dG

verify:
sG = ?R + H(r, m)Q

recovery:
sG = kG + H(r, m) dG = R + H(r, m)Q

so
Q = 1 / H(r, m) * (sG - R).

(And to compute R from r if R is point-compressed, R = (r,f(r)) R' = (r,-f(r)) and try both R and R' by checking if the signature is valid with the resultant public key).

> **Comments:**
> **username_0**: but you [can't do key recovery with BIP-Schnorr](https://crypto.stackexchange.com/a/60828/12089)  

---

### Answer by username_2 on 2015-04-16. Score: 4

The primary design goal for DSA was to avoid infringing the Schnorr patent. Now that the patent has expired, there aren't really any good mathematical reasons to go with DSA. With Schnorr, the algorithm and analysis are simpler and often more efficient. It's also easier to split Schnorr private keys, create threshold variants, etc. However, DSA and ECDSA are standards, and have been for a while. As a result, library implementations are everywhere. You can find hardware security module support, etc. Someday the same will hold of either Ed25519 or some other Schnorr variant. People are unlikely to standardize new DSA variants. But for the moment ECDSA is still the algorithm to use if you want something standard and widely supported.


---

