You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that in Module bls12_381, the implementation of trait ECPoint for struct G1Point is kept from v0.7.0 till the current v0.10.0, while since v0.8.0, the wrapper Point<E: Curve> has been recommended instead of the low-level trait ECPoint. Also, the significant function hash_to_curve still outputs a struct G1Point.
Seemingly, there is some convenience when choosing Point<Bls12_381_1> over G1Point. For example, the traits Serialize and Deserialize are implemented for Point<E: Curve> but not G1Point.
I am wondering if there is any reason to keep the specific notation G1Point (as well as the implementation of trait ECPoint for it) for BLS12-381 when there is a generic struct Point<E: Curve> (namely Point<Bls12_381_1> as an instantiation)?
The text was updated successfully, but these errors were encountered:
I noticed that in Module
bls12_381
, the implementation of traitECPoint
for structG1Point
is kept from v0.7.0 till the current v0.10.0, while since v0.8.0, the wrapperPoint<E: Curve>
has been recommended instead of the low-level traitECPoint.
Also, the significant functionhash_to_curve
still outputs a structG1Point
.Seemingly, there is some convenience when choosing
Point<Bls12_381_1>
overG1Point
. For example, the traitsSerialize
andDeserialize
are implemented forPoint<E: Curve>
but notG1Point
.I am wondering if there is any reason to keep the specific notation
G1Point
(as well as the implementation of traitECPoint
for it) for BLS12-381 when there is a generic structPoint<E: Curve>
(namelyPoint<Bls12_381_1>
as an instantiation)?The text was updated successfully, but these errors were encountered: