Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use serialized PublicKey directly #12

Open
burdges opened this issue Apr 4, 2020 · 0 comments
Open

Use serialized PublicKey directly #12

burdges opened this issue Apr 4, 2020 · 0 comments

Comments

@burdges
Copy link
Collaborator

burdges commented Apr 4, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant