-
Notifications
You must be signed in to change notification settings - Fork 296
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
UIP-4 Spend Backreferences #4922
Conversation
There's a new branch |
c94b30d
to
24de4dd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should make encryption non-fallible, otherwise LGTM
&self, | ||
brk: &BackreferenceKey, | ||
nullifier: &Nullifier, | ||
) -> Result<Option<Backref>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think having Result is smart here, because then you can distinguish between having not put in a back reference, in which case maybe the reference would have pointed to a spend of yours, and a reference you know doesn't belong to you because you can't decrypt it.
This is safe because we know the arrays that have been allocated are the correct size
## Describe your changes This implements UIP-4 as described in penumbra-zone/UIPs#2 ## Issue ticket number and link penumbra-zone/UIPs#2 ## Checklist before requesting a review - [ ] I have added guiding text to explain how a reviewer should test these changes. - [x] If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:
Describe your changes
This implements UIP-4 as described in penumbra-zone/UIPs#2
Issue ticket number and link
penumbra-zone/UIPs#2
Checklist before requesting a review
I have added guiding text to explain how a reviewer should test these changes.
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: