As part of this, we migrate to `secp256k1 0.27`. This version does not
bump `secp256k1-sys`, so remains compatible with the `libsecp256k1`
revision used in `zcashd`.
The `zcash_primitives::legacy::keys::AccountPrivKey` encoding also
changes to preserve the transparent extended key metadata. Previously
the type was documented as such, but only encoded the private key and
chain code; the new encoding now matches the documentation. As a side
effect, the unstable encoding of `zcash_keys::keys::UnifiedSpendingKey`
also changes.
Closeszcash/librustzcash#1407.
Closeszcash/librustzcash#1408.
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 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.
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.