Remove ristretto255 trait implementations about curv

[omershlo]

Hey @str4d, thanks for looking into the code!
For Ristretto we are using curve25519-dalek which I belive is an instantiation of Ristretto for curve25519.

curve25519-dalek is a library providing group operations on the Edwards and Montgomery forms of Curve25519, and on the prime-order Ristretto group.

What am I missing?

About the x/y coordinates - I agree, there's an error there. In practice we never use the coordinates so I think we will make it unimplemented as well. However, I don't see how it relates to your first point?

[str4d]

For Ristretto we are using curve25519-dalek which I belive is an instantiation of Ristretto for curve25519.

curve25519-dalek is implementing ristretto255 as specified in the RFC draft. It happens to use the Edwards form of Curve25519 as its internal representation, but that is an internal implementation detail, not exposed as part of the Ristretto API.

curve25519-dalek is a library providing group operations on the Edwards and Montgomery forms of Curve25519, and on the prime-order Ristretto group.

What am I missing?

Exactly as that documentation says, it provides group operations on the Curve25519 elliptic curve, and on the prime-order Ristretto group.

I strongly recommend reading the ristretto255 RFC draft, but quoting two relevant sections:

Ristretto implements an abstract prime-order group interface that exposes only the behavior that is useful to higher-level protocols, without leaking curve-related details and pitfalls.

ristretto255 is an abstraction which implements a prime-order group, and ristretto255 elements are represented by curve points, but they are not curve points.

In short, ristretto255 not an elliptic curve, and therefore the ECPoint trait should not be implemented for it, as that trait is intended for elliptic curves (as documented in this crate). A more generic group trait (such as the one I am currently working on for the group crate) would make sense for both ristretto255 and the various elliptic curves, but users of the ECPoint trait can reasonably assume that they will only be given elliptic curves, not generic groups.

[omershlo]

I see your point. You are concerned because we named the trait in this library ECPoint, is that right?
This is probably a bad naming issue because this trait aims to offer an interface for generic group element (I admit that it might not be the most accurate set of operation required but this is what we needed for our generic ECC [put aside the issue with coordinates for a second]).

When you use this outside this is the names you see:

pub type GE = Secp256k1Point;
pub type FE = Secp256k1Scalar;

If we were to rename ECPoint to something more generic over groups, would it solve the issue?