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.
During wallet migration in particular, the absence of _any_ accounts is
expected, and all seeds should be treated as relevant (because accounts
cannot be added before a wallet is initialized).
In order to support constructing the anchor for multiple pools with a
common anchor height, we must be able to checkpoint each note commitment
tree (and consequently compute the root) at that height. Since we may
not have the information in the tree needed to do so, we require that it
be provided.
As a bonus, this change makes it possible to improve the UX around
spendability, because we will no longer require subtree ranges below
received notes to be fully scanned; the inserted frontier provides
sufficient information to make them spendable.
Neither of these should have been feature flags, as they gate breaking
changes to the Zcash consensus rules (and in some ways are incompatible
with each other), while feature flags should be additive.
This enables us to activate Sapling and NU5 at the same height, to
simplify reuse of test logic between Sapling and Orchard.
As a side-effect, `zcash_extensions` is removed from the workspace
because it enables the `zfuture` feature flag unconditionally, which
breaks workspace-level builds because this causes the `zfuture` feature
flag on `zcash_protocol` to be enabled without the corresponding feature
flag on `zcash_client_sqlite` being enabled. We will fix this by moving
from feature flags to config flags for unstable features.
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
Now that the release commits are created, we can unhide this ahead of
the subsequent Orchard-supporting releases.
This reverts commit zcash/librustzcash@6161709441.
This default only made sense in the context of what was supported by
`zcash_client_sqlite`, and not in any other context. Unified address
requests no longer have their parts conditioned by what feature flags
are available; instead, if a request is constructed for which the
required key parts are not supported under a particular selection of
feature flags, address generation will raise a runtime error.
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.
`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
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.
Kris Nuttycombe
Jack Grigg
Andrew Arnott
Kris Nuttycombe
Daira Emma Hopwood
Sean Bowe