-
Notifications
You must be signed in to change notification settings - Fork 248
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
zcash_client_sqlite: Ensure that target and anchor heights are relative to the chain tip. #896
Conversation
d3110ae
to
d738088
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #896 +/- ##
==========================================
- Coverage 70.73% 70.70% -0.04%
==========================================
Files 131 131
Lines 12728 12742 +14
==========================================
+ Hits 9003 9009 +6
- Misses 3725 3733 +8
☔ View full report in Codecov by Sentry. |
af33c93
to
f7080a5
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 only reviewed the new commit in this PR (f7080a5).
67029d6
to
69b4d55
Compare
…ve to the chain tip. Prior to the scan-before-sync changes, the wallet was able to assume that the maximum scanned block height at the time of the spend was within a few blocks of the chain tip. However, under linear scanning after the spend-before-sync changes this invariant no longer holds, resulting in a situation where in linear sync conditions the wallet could attempt to create transactions with already-past expiry heights. This change separates the notion of "chain tip" from "max scanned height", relying upon the `scan_queue` table to maintain the wallet's view of the consensus chain height and using information from the `blocks` table only in situations where the latest and/or earliest scanned height is required. As part of this change, the `WalletRead` interface is also modified to disambiguate these concepts.
69b4d55
to
dee4385
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.
utACK dee4385
Prior to the scan-before-sync changes, the wallet was able to assume that the maximum scanned block height at the time of the spend was within a few blocks of the chain tip. However, under linear scanning after the spend-before-sync changes this invariant no longer holds, resulting in a situation where in linear sync conditions the wallet could attempt to create transactions with already-past expiry heights.
This change separates the notion of "chain tip" from "max scanned height", relying upon the
scan_queue
table to maintain the wallet's view of the consensus chain height and using information from theblocks
table only in situations where the latest and/or earliest scanned height is required.As part of this change, the
WalletRead
interface is also modified to disambiguate these concepts.