Open davidrusu opened 3 months ago
That is because here g
is an element of the full group, not the prime subgroup, although the Group
trait emphasizes that the generator()
method should be returning an element of the prime subgroup which is quite confusing given the current implementation of Jubjub.
You can see for instance in the implementation of Group
for SubgroupPoint
(an actual representation of the prime subgroup) that we explicitely call ExtendedPoint::generator()
and then clear the cofactor, to end up with a torsion free element.
Here, rather than clarifying the documentation, I'd suggest updating the implementation of the Group
trait for ExtendedPoint
, to perform what the trait is expecting, i.e. outputting a prime-order generator of the associated subgroup (of scalar field Fr
).
Aha! got you.
Is there any reason to provide a Group implementation for ExtendedPoint if we don't change the scalar field? After it's fixed, won't it be essentially identical to the Group impl. for SubgroupPoint?
At that point we could simply drop Group
for ExtendedPoint
and guide folks to use SubgroupPoint
.
I was running into some issues with broken homomorphic pederson commitments when I subtracted point values. I've reduced it down to this case:
Am I holding it wrong?
Output