been deprecated, because in general it can calculate fees that violate
ZIP 317, which might cause transactions built with it to fail. Maintaining
the generality of the current implementation imposes ongoing maintenance
costs, and so it is likely to be removed in the near future.
Use `transaction::fees::zip317::FeeRule::standard()` instead to comply
with ZIP 317.
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
`zcash_primitives::legacy::Script::serialized_size`. Use the latter in
`zcash_primitives::transaction::fees::transparent::OutputView::serialized_size`.
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.
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 modifies the `compute_balance` method to operate in a
bundle-oriented fashion, which simplifies the API and makes it easier to
elide Orchard functionality in the case that the `orchard` feature is
not enabled.
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.
As a side-effect, we remove the ability to verify individual
transactions with pre-ZIP 216 rules (which we already removed from
`zcashd` consensus nodes in zcash/zcash#6000 and zcash/zcash#6399, as
all pre-ZIP 216 transactions on mainnet are also valid under ZIP 216).
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.