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.
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.
This breaks the link between the concrete `Sender<Progress>` channel
used by the main builder in `zcash_primitives`, and the proof creation
APIs in what will become the `sapling-crypto` crate.
Part of zcash/librustzcash#1044.
The note provided to `add_sapling_spend` contains the recipient address,
and we can extract the diversifier from this address, so we should not
pass it separately.
`fetch_params.sh` is now deprecated and the bundled proving parameters
from `wagyu-zcash-parameters` are used everywhere, so the tests should
follow suit.
Fixes#1016
In order to use `uint64` for amounts that must be nonnegative in the
`proposal.proto` file, it is useful to update fee and change computation
to use `NonNegativeAmount` where possible.
The MSRV for the main crates is 1.65, which is higher than the Rust
version that stabilised workplace dependencies (1.64). The implicit MSRV
for the component crates is still lower than this, so we don't migrate
these crates.
This removes the `CommitmentTree`, `IncrementalWitness`, and
`MerklePath` types in favor of equivalent versions available
from the `incrementalmerkletree` crate.
This is in preparation for extraction into the `incrementalmerkletree`
crate, which is not Sapling-specific and therefore cannot hard-code
the depths of these data structures.
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`.
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 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.
Kris Nuttycombe
Daira Emma Hopwood
Jack Grigg
Tomek Piotrowski
Hazel OHearn