<p>Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the <a href="https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki" rel="nofollow noreferrer">Taproot soft-fork</a> using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.</p>
<p>ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. All outputs having the OP_CHECKSIG opcode will continue to use the legacy ECDSA signing algorithm and verification.</p>
<p>So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not native v1 SegWit. According to <a href="https://txstats.com/dashboard/db/bech32-statistics" rel="nofollow noreferrer">txstats.com</a> only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.</p>

CC BY-SA 4.0
2019-10-28T19:25:54.470Z
"a soft-fork [...] cannot remove ECDSA"  This is phrased confusingly.  I think you're trying to say that we can't allow legacy OP_CHECKSIG operations to be satisfied by a schnorr signature using a soft fork, which is correct.  However, when I first read your sentence, it sounded like you were saying that we couldn't remove ECDSA altogether via a soft fork, which is incorrect---we could make legacy OP_CHECKSIG always fail via a soft fork since that would be simply making the rules more strict.
David A. Harding
CC BY-SA 4.0
2019-10-29T05:08:24.347Z
@DavidA.Harding Yes you are correct. I think that was a poor choice of words on my part.
Ugam Kamat
CC BY-SA 4.0
2019-10-07T12:22:35.680Z
2021-07-08T18:12:45.853Z
2021-07-08T18:12:45.853Z
Ugam Kamat
<p>I stumbled upon the fact that schnorr signatures will most probably replace the current ECDSA system in a future <a href="https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki" rel="noreferrer">BIP</a>.</p>

<p>Is it worth learning about ECDSA or this will become obsolete/useless/confusing knowledge ?</p>

<p>Or should I go straight into schnorr signatures, for example how will it impact a model like <a href="http://static.righto.com/images/bitcoin/bitcoinkeys.png" rel="noreferrer">this</a></p>

<signature><ecdsa><schnorr-signatures>
Will Schnorr Multi-signatures completely replace ECDSA?
Saxtheowl
# Will Schnorr Multi-signatures completely replace ECDSA?

(Asked by: username_0 on 2019-10-07)

I stumbled upon the fact that schnorr signatures will most probably replace the current ECDSA system in a future [BIP](https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki).

Is it worth learning about ECDSA or this will become obsolete/useless/confusing knowledge ?

Or should I go straight into schnorr signatures, for example how will it impact a model like [this](http://static.righto.com/images/bitcoin/bitcoinkeys.png)

**Tags:** signature, ecdsa, schnorr-signatures


---

## 1 answers

### Answer by username_1 on 2019-10-07. Score: 13 | Accepted answer

Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the [Taproot soft-fork](https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki) using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.

ECDSA will continue to be used for spending current non-SegWit and v0 SegWit outputs. All outputs having the OP\_CHECKSIG opcode will continue to use the legacy ECDSA signing algorithm and verification.

So, understanding ECDSA is important for understanding the signature verification behind spending all outputs that are not native v1 SegWit. According to [txstats.com](https://txstats.com/dashboard/db/bech32-statistics) only over 2% of all the BTC value locked belong to native SegWit scripts, that too after almost 2 years of implementation. So it can be safely assumed that V1 implementation might not completely replace all current output locking scripts, needing you to understand ECDSA signing algorithm as well if you plan to build products that would accept Bitcoin that require ECDSA signatures to spend.

> **Comments:**
> **username_2**: "a soft-fork [...] cannot remove ECDSA"  This is phrased confusingly.  I think you're trying to say that we can't allow legacy OP_CHECKSIG operations to be satisfied by a schnorr signature using a soft fork, which is correct.  However, when I first read your sentence, it sounded like you were saying that we couldn't remove ECDSA altogether via a soft fork, which is incorrect---we could make legacy OP_CHECKSIG always fail via a soft fork since that would be simply making the rules more strict.  
> **username_1**: @username_2 Yes you are correct. I think that was a poor choice of words on my part.  

---

