-
Notifications
You must be signed in to change notification settings - Fork 220
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
fix: set wallet start scan height to birthday and not 0 (see issue #4807) #4911
fix: set wallet start scan height to birthday and not 0 (see issue #4807) #4911
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.
We need to implement this logic when the node selects its starting height for a scan, not the ending scan.
The end scan should always be the network tip.
base_layer/wallet/src/utxo_scanner_service/utxo_scanner_task.rs
Outdated
Show resolved
Hide resolved
base_layer/wallet/src/utxo_scanner_service/utxo_scanner_task.rs
Outdated
Show resolved
Hide resolved
f439d24
to
b27c1da
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.
Looks good to me, I would just up the time to be longer to error on the safe side
base_layer/wallet/src/utxo_scanner_service/utxo_scanner_task.rs
Outdated
Show resolved
Hide resolved
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
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.
Just a few nits for clarity, particularly because of unit conversions between the CipherSeed
birthday and Unix time.
Are there tests that exercise the expected behavior? Namely:
- a birthday corresponding to a block that is not the genesis block
- a birthday corresponding to the genesis block
If not, recommend adding them if feasible.
Otherwise, did not specifically test, but the changes to the math appear to be doing what you want.
base_layer/wallet/src/utxo_scanner_service/utxo_scanner_task.rs
Outdated
Show resolved
Hide resolved
Any reason for the large changes to |
May be useful to include a couple of unit tests to hit the saturating subtraction cases. |
f57c801
aaab208
to
f57c801
Compare
Added unit tests and documentation that convey, more precisely, the points made by @AaronFeickert. I tried to make unit tests to be as expressive as possible. In particular, we use hardcoded values for second duration from specific dates. Also added a test on a mocked chain to check consistency of birthday and block timestamps, altogether. |
* fix: updates for SafePassword API change (#4927) Description --- Minor updates for a corresponding [change](tari-project/tari_utilities#52) to the `SafePassword` API. Motivation and Context --- A pending change in `tari_utilities` to the handling of sensitive data includes a new implementation of `SafePassword`. One change removes derived traits for equality testing in favor of equality testing on references to the underlying passphrase data. This work makes the minor but necessary changes to address this API change. How Has This Been Tested? --- Tests pass after applying the linked `tari_utilities` PR. Note that tests will pass using the current `SafePassword` API as well, as the dependency change PR restricts the API. * chore: remove unused methods (#4922) Delete some unused methods * v0.40.0 * fix: set wallet start scan height to birthday and not 0 (see issue #4807) (#4911) Description --- When wallet starts new UTXO scanning service it should start at the birthday. Currently, it starts at height 0. This PR addresses this issue Motivation and Context --- Addresses #4807. How Has This Been Tested? --- * chore: fix naming of ffi functions and comments (#4930) Description --- Fixing the comments of one function in the wallet FFI. Fixes the names of 4 functions in the wallet FFI. * chore: fix depreciated timestamp clippy (#4929) Description --- Fixes depreciated timestamp warnings * feat: implement validator node lmdb store * feat: add stateless vn reg utxo validation rules and merkle root * rename vn validaty period consensus constant * use commitment instead of block hash so that lmdb uses canonical ordering * DRY up vn_mmr calculation, add vn reg utxo validations * fix clippies * wallet: use amount from consensus constants for VN reg * adds validator node signature to common types This is to allow the validator node to use the same signature * remove commitment from signature for now * Remove unneeded validator node kernel feature * ad epoch_length to grpc consensus constants * fix epoch interval check and add test * reduce target time for igor * clippy * change shard key hash label Co-authored-by: Aaron Feickert <[email protected]> Co-authored-by: stringhandler <[email protected]> Co-authored-by: jorgeantonio21 <[email protected]> Co-authored-by: SW van Heerden <[email protected]>
* development: fix: add hidden types and seed words to key manager (tari-project#4925) feat: timestamp validation (tari-project#4887) fix: deleted_txo_mmr_position_to_height_index already exists error (tari-project#4924) feat: add default grpc for localnet (tari-project#4937) first commit (tari-project#4926) v0.40.2 fix(dht): use limited ban period for invalid peer (tari-project#4933) feat: upgrade tari_crypto sign api (tari-project#4932) v0.40.1 chore: fix depreciated timestamp clippy (tari-project#4929) chore: fix naming of ffi functions and comments (tari-project#4930) fix: set wallet start scan height to birthday and not 0 (see issue tari-project#4807) (tari-project#4911) v0.40.0 chore: remove unused methods (tari-project#4922) fix: updates for SafePassword API change (tari-project#4927)
Description
When wallet starts new UTXO scanning service it should start at the birthday. Currently, it starts at height 0. This PR addresses this issue
Motivation and Context
Addresses #4807.
How Has This Been Tested?