This adds a fee calculation strategy abstraction that can be used to
dynamically compute fees so that the total fees required may be taken
taken into account during note selection, and also removes automatic
change creation from the transaction builder.
Change outputs must now be directly created by the caller by the caller.
This is a necessary prerequisite for permitting fees to adjust based
upon the contents of the transaction being constructed.
The initial implementation of the fee strategy simply uses the current
default fee.
Previously, `shield_transparent_funds` was only shielding funds
associated with the legacy default transparent address. This meant
that transparent funds sent to unified addresses could not reliably
be shielded, as a unified address will frequently be constructed
using a diversifier index greater than zero.
This modifies the `get_transparent_receivers` method to return address
metadata containing the account ID and diversifier index used to derive
each address along with the receiver.
As of zcash/librustzcash#633, `SaplingDomain::IncomingViewingKey` now
allocates memory internally, and this memory persists as long as the
`BatchRunner` is alive. Now that we have decoupled the measurement of
heap usage for batch tasks from their internals, we can add bounds to
all of the generic parameters of `Batch` to enable correctly measuring
their actual heap usage.
We also add `DynamicUsage` impls for a bunch of `zcash_primitives` types
that will be used with `BatchRunner` (or its equivalent implementation
in `zcashd`) by callers.
This updates `shield_transparent_funds` to look up the internal
(change) address for the account specified, and use that as the
destination for shielding transparent funds.
Fixed#614
Nullifier computation only requires the nullifier deriving key,
not the entire Sapling viewing key. This separation of concerns
will be needed for batch decryption when wallet-internal keys
will need to be considered.
This also adds a new semantically different `address` method which
attempts to produce an address given the specified diversifier index,
and returns `None` if that index does not produce a valid diversifier.
It is then up to the caller to search the diversifier index space if
the diversifier index that they are attempting to use does not result in
a valid diversifier.
`PublicKey::verify` now always uses post-ZIP 216 validation rules, which
is fine in non-consensus contexts.
`SaplingVerificationContext` is used by `zcashd`'s consensus rules.
Kris Nuttycombe
Sean Bowe
Kris Nuttycombe
Jack Grigg
Daira Hopwood
Kris Nuttycombe
Jack Grigg