<blockquote>
<p>Couldn't it have used other curves, like Curve25519 and its signature schemes that are being used by many other projects?</p>
</blockquote>
<p>Curve25519 is a key agreement scheme, but if you're referring to the (related) Ed25519 system (which uses a variant of the same curve), yes, it could have.</p>
<blockquote>
<p>Wouldn't that come with a lot of advantages -- like key aggregation, signature aggregation and threshold signature schemes already well-developed and deployed in other projects?</p>
</blockquote>
<p>To the best of my knowledge, at the time, none of these things existed. Even the research aspect of practically usable key aggregation and threshold schemes like MuSig and FROST is very new. Standardization of those is underway now for multiple curves, but that was not the case back then.</p>
<p>Schemes predating BIP340:</p>
<ul>
<li>The <a href="https://eprint.iacr.org/2018/068" rel="nofollow noreferrer">MuSig1 paper</a> is from Jan 2018 (but it was broken, and fixed in May 2018).</li>
<li>The <a href="https://eprint.iacr.org/2020/852" rel="nofollow noreferrer">FROST paper</a> is from Jul 2020</li>
<li>The <a href="https://eprint.iacr.org/2020/1261" rel="nofollow noreferrer">MuSig2 paper</a> is from Oct 2020</li>
</ul>
<p>Standardization efforts postdating BIP340:</p>
<ul>
<li>A <a href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/" rel="nofollow noreferrer">standardization effort for FROST</a> is underway since Feb 2021, which includes Ed25519 and secp256k1 support (but not BIP340 compatible).</li>
<li><a href="https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki" rel="nofollow noreferrer">BIP327</a> and <a href="https://github.com/jonasnick/bip-frost-dkg" rel="nofollow noreferrer">bip-frost-dkg</a> are BIP340-compatible, but are very recent.</li>
</ul>
<p>There exist (much) older multisignature schemes too, but none that were ever deployed in production as far as I know, due to various issues that made them hard to use in the real world.</p>
<blockquote>
<p>Aren't these schemes generally faster on Curve25519?</p>
</blockquote>
<p>Yes, implementations of Ed25519 exist that are somewhat faster than secp256k1.</p>
<hr />
<blockquote>
<p>What was the advantage of sticking to secp256k1?</p>
</blockquote>
<p>Quoting BIP340:</p>
<blockquote>
<p>By reusing the same curve and hash function as Bitcoin uses for ECDSA, we are able to retain existing mechanisms for choosing secret and public keys, and we avoid introducing new assumptions about the security of elliptic curves and hash functions.</p>
</blockquote>
<p>So the reasons are:</p>
<ul>
<li>Reusability of existing key derivation infrastructure, including BIP32.</li>
<li>Not changing security assumptions. Bitcoin's security already relies on ECDLP not being broken for secp256k1. BIP340 doesn't change anything about that. Bringing in a new curve would involve an additional assumption.</li>
</ul>

CC BY-SA 4.0
2024-03-13T18:03:53.653Z
2024-03-13T19:44:16.030Z
2024-03-13T19:44:16.030Z
Pieter Wuille
<p>If the entire Taproot/Schnorr soft-fork was going to implement an entirely new signing scheme anyway that was completely independent from the previous ECDSA scheme, why did it use secp256k1?</p>
<p>Couldn't it have used other curves, like Curve25519 and its signature schemes that are being used by many other projects? Wouldn't that come with a lot of advantages -- like key aggregation, signature aggregation and threshold signature schemes already well-developed and deployed in other projects? Aren't these schemes generally faster on Curve25519?</p>
<p>What was the advantage of sticking to secp256k1?</p>

CC BY-SA 4.0
2024-03-20T12:40:07.590Z
Is there evidence of a signature aggregation scheme that is well developed and deployed in other projects (and uses a pairing-unfriendly curve like Curve25519)?
nickler
CC BY-SA 4.0
2024-03-20T15:35:23.117Z
Sorry, I had this impression from looking at a stupid comparison table in some website some time ago, but now I can't find that table nor any other evidence, I think the table probably mentioned just key aggregation, not signature aggregation.
fiatjaf
CC BY-SA 4.0
2024-03-25T12:19:53.700Z
@fiatjaf Are you talking about https://safecurves.cr.yp.to/ by any chance?
Vojtěch Strnad
CC BY-SA 4.0
2024-03-25T17:47:09.683Z
No, not that one.
fiatjaf
<cryptography><taproot><secp256k1><schnorr-signatures><bip>
Why does BIP-340 use secp256k1?
fiatjaf
# Why does BIP-340 use secp256k1?

(Asked by: username_0 on 2024-03-13)

If the entire Taproot/Schnorr soft-fork was going to implement an entirely new signing scheme anyway that was completely independent from the previous ECDSA scheme, why did it use secp256k1?

Couldn't it have used other curves, like Curve25519 and its signature schemes that are being used by many other projects? Wouldn't that come with a lot of advantages -- like key aggregation, signature aggregation and threshold signature schemes already well-developed and deployed in other projects? Aren't these schemes generally faster on Curve25519?

What was the advantage of sticking to secp256k1?

**Tags:** cryptography, taproot, secp256k1, schnorr-signatures, bip

> **Comments:**
> **username_1**: Is there evidence of a signature aggregation scheme that is well developed and deployed in other projects (and uses a pairing-unfriendly curve like Curve25519)?  
> **username_0**: Sorry, I had this impression from looking at a stupid comparison table in some website some time ago, but now I can't find that table nor any other evidence, I think the table probably mentioned just key aggregation, not signature aggregation.  
> **username_2**: @username_0 Are you talking about https://safecurves.cr.yp.to/ by any chance?  
> **username_0**: No, not that one.  

---

## 1 answers

### Answer by username_3 on 2024-03-13. Score: 7 | Accepted answer

> Couldn't it have used other curves, like Curve25519 and its signature schemes that are being used by many other projects?

Curve25519 is a key agreement scheme, but if you're referring to the (related) Ed25519 system (which uses a variant of the same curve), yes, it could have.

> Wouldn't that come with a lot of advantages -- like key aggregation, signature aggregation and threshold signature schemes already well-developed and deployed in other projects?

To the best of my knowledge, at the time, none of these things existed. Even the research aspect of practically usable key aggregation and threshold schemes like MuSig and FROST is very new. Standardization of those is underway now for multiple curves, but that was not the case back then.

Schemes predating BIP340:

* The [MuSig1 paper](https://eprint.iacr.org/2018/068) is from Jan 2018 (but it was broken, and fixed in May 2018).
* The [FROST paper](https://eprint.iacr.org/2020/852) is from Jul 2020
* The [MuSig2 paper](https://eprint.iacr.org/2020/1261) is from Oct 2020

Standardization efforts postdating BIP340:

* A [standardization effort for FROST](https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/) is underway since Feb 2021, which includes Ed25519 and secp256k1 support (but not BIP340 compatible).
* [BIP327](https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki) and [bip-frost-dkg](https://github.com/jonasnick/bip-frost-dkg) are BIP340-compatible, but are very recent.

There exist (much) older multisignature schemes too, but none that were ever deployed in production as far as I know, due to various issues that made them hard to use in the real world.

> Aren't these schemes generally faster on Curve25519?

Yes, implementations of Ed25519 exist that are somewhat faster than secp256k1.

---

> What was the advantage of sticking to secp256k1?

Quoting BIP340:

> By reusing the same curve and hash function as Bitcoin uses for ECDSA, we are able to retain existing mechanisms for choosing secret and public keys, and we avoid introducing new assumptions about the security of elliptic curves and hash functions.

So the reasons are:

* Reusability of existing key derivation infrastructure, including BIP32.
* Not changing security assumptions. Bitcoin's security already relies on ECDLP not being broken for secp256k1. BIP340 doesn't change anything about that. Bringing in a new curve would involve an additional assumption.


---

