During wallet migration in particular, the absence of _any_ accounts is
expected, and all seeds should be treated as relevant (because accounts
cannot be added before a wallet is initialized).
The blanket `impl Account<A> for (A, Option<UnifiedFullViewingKey>)` is
removed because we cannot know the UIVK for `(A, None)`. We instead
provide a blanket impl for `(A, UnifiedIncomingViewingKey)`. We also
move both of them behind `test-dependencies` because they are only
intended for testing purposes.
This should never have had the behavior of returning an error on a
missing txid in the first place; doing so conflates database corruption
or connectivity errors with the ordinary case where data may not be
available.
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.
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
In the process of making the internals of `scan_block_with_runner`
reusable across Sapling and Orchard, it became evident that key
identifier abstraction along the lines of #1175 is needed more
generally. This commit refactors the use of ZIP 32 account identifiers
and key scopes to better separate scanning concerns from ZIP 32 key
derivation. In the process, this removes a fair amount of unnecessary
polymorphism from `zcash_client_backend::wallet::WalletTx` and related
types.
This PR was extracted from https://github.com/zcash/librustzcash/pull/1175
in order to make the changes to `zcash_client_backend` usable without
the additional generalizations to `zcash_client_sqlite` made by that PR.
Co-authored-by: Andrew Arnott <andrewarnott@live.com>
It needn't return the account id that was given as an input, and it shouldn't return an 11-byte diversifier index when a 31-bit child index is more appropriate.
This unification allows us to better isolate transparent-input dependent
functionality. Previously, `TransparentInputSource` could not be placed
under a feature flag because the interface was needed for proposal
deserialization; by instead making the transparent input source methods
flag-dependent, we can correctly produce an error when proposal
deserializaiton attempts to select transparent inputs and the feature
flag is off.
We plan to also introduce a similar flag to gate access to Sapling
functionality. Since introduction of Orchard functionality is still
nascent, it's the correct time to introduce this isolation, before
there's more functionality that needs to be isolated in this fashion.
Kris Nuttycombe
Jack Grigg
Kris Nuttycombe
Andrew Arnott
Kris Nuttycombe