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
Some differences in the serialization format (e.g. a serialized kfrag has flags of whether delegation and receiving key were signed in two separate bytes instead of one)
Differences in API (e.g. a capsule does not include cfrags, they come separately)
NON_INTERACTIVE and X_COORDINATE constants are different (in PyUmbral they are taken from constant_sorrow)
kfrag ID is a CurveScalar and not just 32 random bytes
Maybe something else
Except for the difference in hash function implementation (if any), the rest is theoretically fixable. The question is, do we want to do it? Seems like it would be better to handle this difference at the protocol level, by implementing versioning.
The text was updated successfully, but these errors were encountered:
From the discussion: define NON_INTERACTIVE and X_COORDINATE as simpler values instead of bigger constants. Byte-sized, for example, for ease of implementation. But we do need to keep them.
fjarri
added a commit
to fjarri/rust-umbral
that referenced
this issue
Mar 6, 2021
At the moment
rust-umbral
is not binary compatible withPyUmbral
:NON_INTERACTIVE
andX_COORDINATE
constants are different (inPyUmbral
they are taken fromconstant_sorrow
)CurveScalar
and not just 32 random bytesExcept for the difference in hash function implementation (if any), the rest is theoretically fixable. The question is, do we want to do it? Seems like it would be better to handle this difference at the protocol level, by implementing versioning.
The text was updated successfully, but these errors were encountered: