This removes the path-based dependencies on the `zcash_note_encryption`
crate in favor of using versioned dependencies locally. This better
reflects the future state in which `zcash_note_encryption` is factored
out of the workspace and maintained in a separate repository.
The `halo2_proofs/multicore` flag must be disabled when running wasm
builds; this ensures that we do not accidentally include it as a
transitive dependency when building with `--no-default-features`.
This change makes it possible for wallets using the
`zcash_client_backend::data_api::wallet` module to perform transaction
preparation, including input selection and fee calculation, as an
independent step prior to creating proofs and signatures. This can be
used to improve user experience by making it possible to report the
proposed effects of the transaction to the wallet user (including
privacy implications) prior to authorizing the transaction.
Previously, if a caller wanted to use a block source to perform
scanning from the first available block, they would have to guess
at the block height to start from. Changing this to an optional
argument makes this explicit.
This allows callers to validate smaller intervals of the given
`BlockSourceT` shortening processing times of the function call at the
expense of obtaining a partial result on a given section of interest of
the block source.
`params: &ParamsT` has been removed from the arguments since they were
only needed to fall back to `sapling_activation_height` when `None` as
passed as the `validate_from` argument. Passing `None` as validation
start point on a pre-populated `block_source` would result in an error
`ChainError::block_height_discontinuity(sapling_activation_height - 1, current_height)`
With this new API callers must specify a concrete `validate_from`
argument and assume that `validate_chain` will not take any default
fallbacks to chain `ParamsT`.
The addition of a `limit` to the chain validation function changes the
meaning of its successful output, being now a `BlockHeight, BlockHash)`
tuple indicating the block height and block hash up to which the chain
as been validated on its continuity of heights and hashes. Callers
providing a `limit` aregument are responsible of subsequent calls to
`validate_chain()` to complete validating the remaining blocks stored on
the `block_source`.
Closeszcash/librustzcash#705
The MSRVs of the component crates are left as-is, partly because our
dependencies don't require us to bump them, and partly because those
crates have no pending changes and are relatively stable. We also plan
to split the component crates out into a separate repository, where it
will be easier to have a separate MSRV.
Closeszcash/librustzcash#759.
The change selection algorithm has the most useful information for
determining whether or not a note is dust, so this adds a new error case
to `ChangeError` that allows the change selection to report the presence
of input notes without economic value back to its caller.
This adds a set of abstractions that allow wallets to provide
independent strategies for fee estimation and note selection, and
implementations of these strategies that perform these operations in the
same fashion as the existing `spend` and `shield_transparent_funds`
functions.
This required a somewhat hefty rework of the error handling in
zcash_client_backend. It fixes an issue with the error types whereby
callees needed to have a bit too much information about the error
types produced by their callers.
Reflect the updated note selection and error handling in zcash_client_sqlite.
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.
In 47a0d0d2b7 `WalletWriteTransparent` was
merged into `WalletWrite`, including its associated type `UtxoRef`.
However, `shield_transparent_funds` placed a bound on this associated
type that was not moved to `WalletWrite`. This left the generic
parameter `U` unconstrained, which didn't cause a local failure because
the method has no local tests, but was immediately apparent when trying
to use the method in the mobile SDKs.
This modifies `decrypt_and_store_transaction` to check for inputs
to a transaction being decrypted that correspond to utxos known
to our wallet. For each such UTXO found, it is marked spent.
These traits introduce a problem, in that constraints on a method cannot
be conditionally required based upon the presence or absence of a
feature flag. Instead, we make the methods previously introduced by
the removed traits present in all cases on the `WalletRead` and
`WalletWrite` traits, but ensure that their implementations return
an error if the caller attempts to use them in a wallet that has not
been configured with support for transparent inputs functionality.
Due to how the wallets retrieved unspent transparent outputs from the
light wallet server, the account associated with a particular UTXO may
not be known by the light wallet. Instead of requiring the caller to
perform a separate lookup and match the address of the received UTXO
with a known account, it's simpler to perform this lookup internally at
the time of insertion or update.
In order to make this operation more efficient, the `addresses_table`
migration is modified to add a column to cache the transparent receiver
so that it may be used in the joins in the UTXO insert and update
operations.
The currently deprecated implementations of `insert_sent_utxo`,
`insert_sent_note`, `put_sent_utxo` and `put_sent_note` all store to the
same `sent_notes` table internally. Since there's no immediate plan to
change this arrangement, it's better to have a single pair of internal
`insert_sent_output` and `put_sent_output` methods instead.
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.
Jack Grigg
Kris Nuttycombe
Francisco Gindre
Kris Nuttycombe
Greg Pfeil
str4d
Sean Bowe