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
If an account's keys are not valid points on the curve, then it will not be possible to use them. This is mostly an issue for the owner (e.g. they won't be able to show their nullifier private key), but it also affects senders: they won't be able to encrypt messages for the owner.
This could lead to denial of service attacks in which users are unable to produce valid proofs due to malicious recipients (sometimes called a King of the Hill attack). To prevent this, we must provide an escape-hatch for accounts that prove the recipient's keys are not valid, which might be as simple as:
assert(!is_infinity);
x_sq = x * x;
rhs = x_sq * x - 17;
y_sq = y * y;assert(y_sq == rhs);
The escape-hatch would very likely be to allow the sender to skip note creation entirely. This scenario should only occur as a result of malicious users, user error (e.g. sending tokens to a contract), or bad wallets (that create bad keys). It seems fine to allow the caller to not send notes in all of these cases - none of these scenarios seem abusable. Additionally, non-point keys are unusable, so there is no harm done in skipping note creation.
The text was updated successfully, but these errors were encountered:
If an account's keys are not valid points on the curve, then it will not be possible to use them. This is mostly an issue for the owner (e.g. they won't be able to show their nullifier private key), but it also affects senders: they won't be able to encrypt messages for the owner.
This could lead to denial of service attacks in which users are unable to produce valid proofs due to malicious recipients (sometimes called a King of the Hill attack). To prevent this, we must provide an escape-hatch for accounts that prove the recipient's keys are not valid, which might be as simple as:
The escape-hatch would very likely be to allow the sender to skip note creation entirely. This scenario should only occur as a result of malicious users, user error (e.g. sending tokens to a contract), or bad wallets (that create bad keys). It seems fine to allow the caller to not send notes in all of these cases - none of these scenarios seem abusable. Additionally, non-point keys are unusable, so there is no harm done in skipping note creation.
The text was updated successfully, but these errors were encountered: