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

[Bug?] Client 'incoming-viewing-key' potential issue #1434

Open
fullkomnun opened this issue Jun 21, 2023 · 0 comments
Open

[Bug?] Client 'incoming-viewing-key' potential issue #1434

fullkomnun opened this issue Jun 21, 2023 · 0 comments

Comments

@fullkomnun
Copy link
Contributor

For nightfall client's 'incoming-viewing-key' request, it stores given 'zkpPrivateKeys' and 'nullifierKeys' in memory,
then it tries to use these to sync client commitments using nightfall-client/src/services/commitment-sync.mjs's clientCommitmentSync exported function.

clientCommitmentSync implementation

given a ‘zkpPrivateKey’ and a ‘nullifierKey’ get all transactions, for each transaction:

  1. get all non-zero commitments
  2. conditional: only for ‘transfer’ transaction (identifies by compressedSecrets being not [ZERO,ZERO]) where we have the first non-zero commitment stored
  3. try to decrypt that commitement using the provided ‘zkpPrivateKey’ and ‘nullifierKey’

However, the condition is:

countCommitments([nonZeroCommitments[0]]) === 0

where countCommitments returns a Promise but is comapred to a numeric literal so condition will never be met (supposedly) which means it will not decrypt any commitments already stored prior to the 'incoming-viewing-key' request.

Mitigation

  • Probably should 'await' the call to countCommitments
  • Maybe create a test-case for that use-case
  • The call to decryptCommitment is also not awaited for which could be intentional but will resume before sync is over and has implications with regards to error handling
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