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
SecretKey should include a [u8; 32] serialized PublicKey, not the PublicKey elliptic curve point it currently includes, becuse Schnorr proofs only require the serialized version. In schnorrkel, we handle CompressedRistretto(pub [u8; 32])s for this, so commit_point takes those directly, but zcash using Read and Write makes this messy. We'll see if ZEXE fixed their serialization.
AuthPath should include a [u8; 32] serialized PublicKey too. We only use AuthPath in the SNARK prover where we already have, and do not use, the PublicKey inside SecretKey, but it'll make the library more robust if AuthPath compares it's serialized PublicKey with the SecretKey. We never transmit AuthPath increasing the serialization by 32 bytes sounds harmless.
As an alternative, we should consider adding some pub struct RingSecretKey(SecertKey, AuthPath) type for usage with the SNARK prover. We'd create this with custom read methods that take a SecretKey and auth_depth, well unless #10 gets fixed, not sure if that's easier. We could even store and test the root instead of storing the serialized PublicKey.
We're introducing new convenience errors here so easiest to do #11 first
The text was updated successfully, but these errors were encountered:
SecretKey
should include a[u8; 32]
serializedPublicKey
, not thePublicKey
elliptic curve point it currently includes, becuse Schnorr proofs only require the serialized version. In schnorrkel, we handleCompressedRistretto(pub [u8; 32])
s for this, socommit_point
takes those directly, but zcash usingRead
andWrite
makes this messy. We'll see if ZEXE fixed their serialization.AuthPath
should include a[u8; 32]
serializedPublicKey
too. We only useAuthPath
in the SNARK prover where we already have, and do not use, thePublicKey
insideSecretKey
, but it'll make the library more robust ifAuthPath
compares it's serializedPublicKey
with theSecretKey
. We never transmitAuthPath
increasing the serialization by 32 bytes sounds harmless.As an alternative, we should consider adding some
pub struct RingSecretKey(SecertKey, AuthPath)
type for usage with the SNARK prover. We'd create this with custom read methods that take aSecretKey
andauth_depth
, well unless #10 gets fixed, not sure if that's easier. We could even store and test the root instead of storing the serializedPublicKey
.We're introducing new convenience errors here so easiest to do #11 first
The text was updated successfully, but these errors were encountered: