Ristretto Basepoint issues on Compression/Decompression process.

[CPerezz]

The standard behavior of the RistrettoPoint works like:

RistrettoPoint --> compression --> CompressedRistretto
CompressedRistretto --> decompression --> RistrettoPoint

Obviously, the expected behavior for a point compression followed by a point decompression is to obtain the same exact point in Twisted Edwards Extended Coordinates.
We should obtain the same RistrettoPoint we used as input.

Also, with the equality formulas that appear on:
https://ristretto.group/formulas/equality.html this statement mentioned above should happen always.

So after making some tests, I verified that:

 #[test]
 fn point_comp_decomp_equivalence() {
        // This should give the RISTRETTO_BASEPOINT. 
        assert!(constants::RISTRETTO_BASEPOINT.compress().decompress().unwrap() ==       constants::RISTRETTO_BASEPOINT);
    }

//This test does not pass and it should.

This happened on: e8066b5 and my ideas are:

• The Basepoint is not the one on it's 4-coset that would be encoded as RistettoPoint.
• The compression/decompression processes are not working as expected.
• The point really pertains to the coset and current equalty does not catch it.

[CPerezz]

Product of previous discussions with @Bounce23 and a discussion with @bellesmarta where we were checking that the 4coset listed on https://ristretto.group/details/isogeny_encoding.html#torquing-points-to-lift-mathcal-e--mathcal-e4-to-mathcal-e--mathcal-e2- was right doing something like:

Maybe the problem is that the Basepoint we choose was not the right one in terms of:

The Basepoint is inside a 4-coset with 3 other points, but as we know, only one of them satisfies the Ristretto constraints and then, only one can be the correct RistrettoPoint.
Then, we should maybe generate the 4coset where the Basepoint lives and check which is the one of the 4 that will be the Ristretto complaint.
Because if it's not the one we chose and knowing that is hardcoded in

dusk-zerocaf/src/constants.rs

Line 57 in e8066b5

pub const RISTRETTO_BASEPOINT: RistrettoPoint = RistrettoPoint(DOPPIO_BASEPOINT);

It might be the source of this unexpected behavior.

[LukePearson1]

Furthering the above comment, including the talks, the base point has been proven to be the correct one. However, there is an issue with point selection. As each Edwards/Tedwards curve admits certain formulae, we are searching for the one that has xy as non-negative and x not equal to zero.

These requirements are satisfied by the base point selection in #76 but still fail the decompression process.

There are a couple of reasons this could be the case, the most likely is the equivalence of inverse square root shown here. This will be addressed this evening and fixed to create correct equivalence in the coset.

[CPerezz]

Since, the only way to get a 100% valid RistrettoPoint (only using the library as it is right now) is basically getting the identity and add it to itself, which will produce a valid RistrettoPoint that we will be able to encode and decode, closing #79 will be a huge advance in order to know what happens with the Basepoint.

Because all of the conditions that Ristretto/Decaf give to a point that lives on a 4-coset to be the one chosen as the RistrettoPoint valid encoding are:

• xy is negative.
• y is zero.
  And can be seen here: https://ristretto.group/details/isogeny_encoding.html#torquing-points-to-lift-mathcal-e--mathcal-e4-to-mathcal-e--mathcal-e2-

The basepoint satisfies this but does not work. So being able to get other points from the lib itself will be nice (checking them correctness obviously).

[LukePearson1]

I'll obtain other working values that satisfy the basepoint and its a case of trial and error from the coset values. I will obtain all 4 from the coset from which I gave you last time.

[CPerezz]

For mi 284c394 closed this since all of the validity tests for Compression and Decompression of the basepoint passed.

This may also close #76