-
Notifications
You must be signed in to change notification settings - Fork 111
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
Implement RFC5: State updates Chain
type
#1069
Conversation
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.
Looks good, but needs a few tweaks and bug fixes.
I don't understand enough about transactions to review that part of the code, let's get @dconnolly or @hdevalence to review it as well.
In particular, I don't know if every post-Sapling block is guaranteed to have a Sprout and Sapling anchor. If they don't, that will affect this PR:
#902 (review)
There are also a few outstanding design issues, which were part of my final review of the RFC, but didn't get included. I don't think they affect this PR, but please check:
#1090
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: teor <teor@riseup.net>
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.
Looks great!
I'm not sure if you'd like to merge now, or do some more work, and then merge.
I think it's ok to merge the partial PR, as long as someone else has reviewed the transaction parts.
I want to get the two proptests that henry mentioned implemented before merging, just having a bit of trouble figuring out how to make arbitrary fake chains 😅 |
Let me know if you need help with that - you might want to start at genesis, and then add various forks. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
452a241
to
c4b8a4d
Compare
Chain
structure
Chain
structureChain
type
Just following up on the sprout and sapling roots - it doesn't look like we'll need to change the RFC design or implementation: |
- (non-finalized) if any `Chains` contain an `OutPoint` in their `created_utxos` and not their `spent_utxo` get the `transparent::Output` from `OutPoint`'s transaction | ||
- (finalized) else if `OutPoint` is in `utxos_by_outpoint` return the associated `transparent::Output`. |
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.
My original utxo_is_available
was meant for contextual verification, not prospective verification. Since a chain can fork at any non-finalized block, I don't think we should check spent_utxo
here.
Instead, we should check spent_utxo
using the original utxo_is_available
logic during contextual verification.
- (non-finalized) if any `Chains` contain an `OutPoint` in their `created_utxos` and not their `spent_utxo` get the `transparent::Output` from `OutPoint`'s transaction | |
- (finalized) else if `OutPoint` is in `utxos_by_outpoint` return the associated `transparent::Output`. | |
- (non-finalized) if any `Chains` contain `OutPoint` in their `created_utxos`, get the `transparent::Output` from `OutPoint`'s transaction | |
- (finalized) else if `OutPoint` is in `utxos_by_outpoint` return the associated `transparent::Output`. |
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.
applied this in the test PR to avoid needing a new test and approval
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're looking pretty good to merge here.
We just need a tweak to the state design, and maybe we also want to get the separate tests PR working?
No description provided.