This fixes an issue wherein transparent outputs of transactions added to
the wallet via `decrypt_and_store_transaction` would not be properly
recorded as UTXOs belonging to the wallet.
Part of #1434
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>
This now only supports a single ephemeral input and/or output when
constructing a proposal (multiple ephemeral outputs are still supported
when creating transactions).
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 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.
It needn't return the account id that was given as an input, and it shouldn't return an 11-byte diversifier index when a 31-bit child index is more appropriate.