Implements a type to enclose a Seed Fingerprint byte sequence
called `SeedFingerprint`
implements a public function to create a `SeedFingerprint` from
seed bytes
Closes#792
Credits for PR Suggestions by Daira and Kris
Edit: Added suggestions from Daira Emma and a test for returning `None`
Added test refactor suggestions as well
removed reference to test vectors
This removes our reliance on the following out-of-date transitive
dependencies that are duplicative of more recent versions of crates
we depend on:
- bls12_381 v0.7
- ff v0.12
- group v0.12
- jubjub v0.9
- pasta_curves v0.4
- reddsa v0.3
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 `Domain::Note` type is now expected to contain information about the
recipient of the note, eliminating the need to pass this information in
via the encryption context.
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 actions-rs/* actions are unmaintained. See actions-rs/toolchain#216
for more information.
- actions-rs/toolchain is replaced by rust-toolchain.toml.
- actions-rs/cargo is replaced by direct cargo usage.
- actions-rs/tarpaulin is replaced by the cargo-tarpaulin container.
We currently retain a few usages due to a current lack of alternatives:
- actions-rs/toolchain to enable beta (for Clippy warnings) and nightly
(for building the book).
- actions-rs/clippy-check so Clippy results are published as annotations
on PRs.
We also now require via rust-toolchain.toml that people building from
the repo have the clippy and rustfmt components installed. This is fine
because they will need to ensure these pass when making PRs.
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
Kris Nuttycombe
Francisco Gindre
str4d
dependabot[bot]
Francisco Gindre