<p>Schnorr will replace ECDSA, the signing algorithm, but both still use the same elliptic curve and thus the same public and private keys, etc. </p>

<p>Regardless, compatibility with ECDSA must be kept too even if Schnorr is used, because otherwise all old nodes would see the schnorr signatures as invalid signatures, and all old transactions would be seen as invalid by new nodes, creating a hard fork. It's likely that a new OP code would be introduced for schnorr signature checking, perhaps introduced in a new witness version, to keep it as a soft fork. If introduced, it will need a new type of address, to distinguish it from the addresses which should be checked using ECDSA. So both types of address would be compatible with all new nodes, in the same way that new <code>bc1</code> native witness addresses are compatible with new nodes alongside P2SH and legacy addresses</p>

CC BY-SA 3.0
2017-11-29T20:34:07.577Z
2017-11-29T23:55:32.897Z
2017-11-29T23:55:32.897Z
meshcollider
<p>On March 23, 2017 the Bitcoin Core team published a technology roadmap, expressing their intent to replace ECDSA (SECP256k1) with Schnorr signatures: <a href="https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/" rel="noreferrer">https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/</a>.</p>

<p>Pardon my naive understanding, but we currently use ECDSA (SECP256k1) to generate public keys, and by extension- addresses. How does replacing the signing algorithm with a new signing algorithm not affect today's addressing? Does it? Where does backward compatibility fit in with this?</p>

<address><signature><address-generation><ecdsa><schnorr-signatures>
Replacing ECDSA (SECP256k1) with Schnorr signatures
shmuli
# Replacing ECDSA (SECP256k1) with Schnorr signatures

(Asked by: username_0 on 2017-11-29)

On March 23, 2017 the Bitcoin Core team published a technology roadmap, expressing their intent to replace ECDSA (SECP256k1) with Schnorr signatures: <https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/>.

Pardon my naive understanding, but we currently use ECDSA (SECP256k1) to generate public keys, and by extension- addresses. How does replacing the signing algorithm with a new signing algorithm not affect today's addressing? Does it? Where does backward compatibility fit in with this?

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


---

## 1 answers

### Answer by username_1 on 2017-11-29. Score: 10 | Accepted answer

Schnorr will replace ECDSA, the signing algorithm, but both still use the same elliptic curve and thus the same public and private keys, etc.

Regardless, compatibility with ECDSA must be kept too even if Schnorr is used, because otherwise all old nodes would see the schnorr signatures as invalid signatures, and all old transactions would be seen as invalid by new nodes, creating a hard fork. It's likely that a new OP code would be introduced for schnorr signature checking, perhaps introduced in a new witness version, to keep it as a soft fork. If introduced, it will need a new type of address, to distinguish it from the addresses which should be checked using ECDSA. So both types of address would be compatible with all new nodes, in the same way that new `bc1` native witness addresses are compatible with new nodes alongside P2SH and legacy addresses


---

