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
Every address that registers will, by default, be visible. This can be solved by symmetrically encrypting the address in the user data. A zk proof for this would:
Calculate ethereum address from private key (500k constraints)
Encrypt the address using chacha (use semaphore private key as password) (~15k constraints)
Output the encrypted address
This proof would be given to the attester, and the attester would give the encrypted address to the user as user data (after verifying the proof).
Then, when a user wants to join an application they can prove they control an address in zk by:
Prove they have the encrypted address as user data
Decrypt the address (~15k constraints)
Prove the address exists in a tree with root R
This scheme would be fully private, but would require the user to make a single large proof. Once the user has the user data all future proofs of address control would be small (< 30k constraints).
The text was updated successfully, but these errors were encountered:
Every address that registers will, by default, be visible. This can be solved by symmetrically encrypting the address in the user data. A zk proof for this would:
This proof would be given to the attester, and the attester would give the encrypted address to the user as user data (after verifying the proof).
Then, when a user wants to join an application they can prove they control an address in zk by:
This scheme would be fully private, but would require the user to make a single large proof. Once the user has the user data all future proofs of address control would be small (< 30k constraints).
The text was updated successfully, but these errors were encountered: