Prior to this change, the recipient of a sent transaction would always
be shown as the protocol-level address, instead of any unified address
intended as the recipient. Now, instead of reencoding the recipient
address, we use the original `ZcashAddress` value from the payment
request.
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.
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
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 was necessary as of `orchard 0.7`, but due to CI not checking with
the `orchard` feature flag at the time the crate was updated, CI did not
catch this.
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.