This implements the necessary state machine for taking a wallet in some
arbitrary synchronization status, and fully scanning (the remainder of)
the chain.
Closeszcash/librustzcash#1169.
In order to support constructing the anchor for multiple pools with a
common anchor height, we must be able to checkpoint each note commitment
tree (and consequently compute the root) at that height. Since we may
not have the information in the tree needed to do so, we require that it
be provided.
As a bonus, this change makes it possible to improve the UX around
spendability, because we will no longer require subtree ranges below
received notes to be fully scanned; the inserted frontier provides
sufficient information to make them spendable.
Neither of these should have been feature flags, as they gate breaking
changes to the Zcash consensus rules (and in some ways are incompatible
with each other), while feature flags should be additive.
This enables us to activate Sapling and NU5 at the same height, to
simplify reuse of test logic between Sapling and Orchard.
As a side-effect, `zcash_extensions` is removed from the workspace
because it enables the `zfuture` feature flag unconditionally, which
breaks workspace-level builds because this causes the `zfuture` feature
flag on `zcash_protocol` to be enabled without the corresponding feature
flag on `zcash_client_sqlite` being enabled. We will fix this by moving
from feature flags to config flags for unstable features.
This inverts the dependency relationship between `zcash_protocol` and
`zcash_address`, permitting the network constants (primarily the HRPs)
defined in `zcash_protocol` to be used directly in `zcash_address`
instead of being duplicated.
This adds a mechanism that allows a caller to verify that a given seed
generates the viewing key that is stored in the wallet for a specified
account.
Fixes#1189
str4d
Kris Nuttycombe
oscar-pepper
Andrew Arnott
Kris Nuttycombe