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 change makes it easier for third parties to make use of the Unified
key infrastructure without incurring a dependency upon the rest of the
`zcash_client_backend` interfaces.
This modifies the `compute_balance` method to operate in a
bundle-oriented fashion, which simplifies the API and makes it easier to
elide Orchard functionality in the case that the `orchard` feature is
not enabled.
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.
`ReceivedNote` now allows Orchard notes to be represented as received
notes. As part of this change, received notes now track whether they
were received using internally- or externally-scoped viewing keys.
This eliminates the need to trial-regenerate notes using the wallet's
IVKs to determine scope at spend time.
Public methods for mutation of these fields have been provided that
perform checking for overflow of the valid monetary range as part
of their operation.
Prior to this change, it's necessary to implement the entirety of the
`WalletRead` trait in order to be able to use the input selection
functionality provided by `zcash_client_backend::data_api::input_selection`.
This change factors out the minimal operations required for transaction
proposal construction to better reflect the principle of least authority
and make the input selection code reusable in more contexts.
In order to minimize the operations of the newly-created `InputSource`
and `ShieldingSource` traits, this change also removes the
`min_confirmations` field from transaction proposals, in favor of
storing explicit target and anchor heights. This has the effect of
limiting the lifetime of transaction proposals to `PRUNING_DEPTH -
min_confirmations` blocks.
This fixes an API issue whereby it was possible to execute a `Proposal`
with a different value of `min_confirmations` than that with which the
`Proposal` was constructed.
Kris Nuttycombe
Kris Nuttycombe
Andrew Arnott
str4d