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
Rather than generating salts and secrets randomly, if could probably be better for the client to be initialized with a random number, from which to start incrementing each salt for the nullifier (same for the secrets), to keep track/store all nullifiers and secrets more easily.
The text was updated successfully, but these errors were encountered:
If the secret and salt are incremented, then providing any secret to anybody else (as required by the protocol) would reveal all future secrets that the person will use, which is... possibly needs some re-thought?
One thing i want to add here is that if a user sends two deposits with the same nullifier then only a single payment can be withdrawn. This is a little annoying when i want to pay someone else. Its very unlikely it will get blocked but its still possible. So i thought about using an incremental nullifier here. But discarded it because of race conditions.
Rather than generating salts and secrets randomly, if could probably be better for the client to be initialized with a random number, from which to start incrementing each salt for the nullifier (same for the secrets), to keep track/store all nullifiers and secrets more easily.
The text was updated successfully, but these errors were encountered: