within the gap. Also support paging for `get_known_ephemeral_addresses`.
Co-authored-by: Jack Grigg <jack@electriccoin.co>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
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.
The only default-enabled feature flag in `sapling-crypto` is the
`multicore` feature flag, which we re-export in each crate that includes
proof creation. We need to disable it as a default feature of our
dependency in order to enable it to be correctly disabled when a user of
e.g. `zcash_primitives` disables its default features.
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 change makes it easier for third parties to make use of the Unified
key infrastructure without incurring a dependency upon the rest of the
`zcash_client_backend` interfaces.
Jack Grigg
Daira-Emma Hopwood
Kris Nuttycombe
Willem Olding
Kris Nuttycombe