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>
In the event that the pool to which change should be sent cannot
automatically be determined based upon the inputs and outputs of a
transaction, it is up to the caller to specify where change should
be sent.
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 default only made sense in the context of what was supported by
`zcash_client_sqlite`, and not in any other context. Unified address
requests no longer have their parts conditioned by what feature flags
are available; instead, if a request is constructed for which the
required key parts are not supported under a particular selection of
feature flags, address generation will raise a runtime error.
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.