4

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?

Improve this question
4
  • 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)?
    – nickler
    Commented Mar 20 at 12:40
  • 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
    Commented Mar 20 at 15:35
  • @fiatjaf Are you talking about safecurves.cr.yp.to by any chance?
    – Vojtěch Strnad
    Commented Mar 25 at 12:19
  • No, not that one.
    – fiatjaf
    Commented Mar 25 at 17:47

1 Answer 1

Reset to default
7

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:

Standardization efforts postdating BIP340:

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.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.