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

add view tags for speeding up scanning #377

Closed
noot opened this issue Aug 11, 2022 · 3 comments
Closed

add view tags for speeding up scanning #377

noot opened this issue Aug 11, 2022 · 3 comments

Comments

@noot
Copy link

noot commented Aug 11, 2022

hey I'm looking at your protocol, from your docs "The final consideration has to do with scanning. Because every single Announcement needs to be scanned, it can take a long time to find your finds."

have you considered something like view tags (implemented in monero) for speeding up this process? it should work w your protocol as far as I can tell. you'd only need to calculate the ECDH key for each Announcement instead of having to decrypt the secret, calculate the shared private key, and derive a_stealth each time. you'd have to add 1 byte to the Announcement event that is the first byte of the ECDH key, so for each announcement, you'd only need to derive the ECDH key and 255/256 times skip the rest of the steps.

here's the original idea: monero-project/research-lab#73

@mds1
Copy link
Collaborator

mds1 commented Aug 12, 2022

Ah this is really clever, thanks! Haven't seen that before.

Adding the 1 byte of the ECDH key to the Announcement would reduce security by 1 byte though, right? In the linked issue they suggest hashing the ECDH key and including the first n bytes (where n was up for discussion), which is interesting:

  • I think hashing is a lot faster than elliptic curve multiplication, so that seems like a worthwhile tradeoff to keep that extra 1 byte of security.
  • Then if you're hashing it, you could safely emit between more than just 1 byte of info and improve the speedup from only computing 1/256 addresses to something even smaller. We have to emit a full 32 byte param in the event anyway, so we get the extra bytes here roughly for free (I don't think LOG costs differentiate zero vs. non-zero bytes).

The main downside is that we need to deploy a new contract which would be a bit of a pain since indexing/scanning now needs to track two contracts, but definitely like the idea.

@noot
Copy link
Author

noot commented Aug 15, 2022

@mds1 yep, hashing it and emitting more than 1 byte seems like a good idea, like you said it'll get packed to 32 bytes anyways. would reduce potentially a lot of scanning :)

I guess for the downside, could you slowly migrate to the newer version and deprecate the old one if you decide to implement this feature? not sure if this is feasible as I haven't looked fully into your architecture.

@garyghayrat garyghayrat moved this to 🆕 New in Umbra Oct 11, 2022
@garyghayrat garyghayrat moved this from 🆕 New to 📋 Backlog in Umbra Oct 11, 2022
@mds1
Copy link
Collaborator

mds1 commented Feb 6, 2023

Going to close this since view tags will not be implemented in this version of Umbra, but will be implemented once the stealth address EIP is finalized and we upgrade to support it:

  • EIP itself can be found here
  • Most recent version, not yet upstreamed, can be found in the open PR in this repo

Thanks again for the suggestion @noot!

@mds1 mds1 closed this as completed Feb 6, 2023
@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in Umbra Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

2 participants