Since the wallet ecosystem may not be fully updated to handle
v5 transaction parsing at the point of NU5 activation, some
nodes may prefer to construct V4 transactions when not including
Orchard transaction components.
This change adds a CLI flag that allows node users to specify
that preference.
This changes anchor selection and Orchard authentication path generation
to default to select anchors at a the depth specified by the
`-orchardanchorconfirmations` CLI argument, with a default anchor
selection depth of 10 blocks.
If the value of `minconf` used for a particular call to `z_sendmany` is
less than the the set number of Orchard anchor confirmations, `minconf`
will be used instead for the Orchard anchor confirmations depth,
so that the selected anchor will be certain to contain any notes
selected to be spent.
Fixes#5644
The merge commit includes changes to address direct merge conflicts.
This commit makes the remaining changes necessary to integrate the
Orchard wallet changes with the NU5 consensus changes.
The addition of `OrchardRawAddress` to `RecipientAddress` drives most of
the changes in this commit, which enable `z_sendmany` to send funds to
addresses in the Orchard pool once NU5 activates.
This also alters `TransactionBuilder::SendChangeTo` to take a
`libzcash::ChangeAddress` value and thus avoids the invalid
t-addr case of CTxDestination.
When creating randomized JoinSplits, the caller passes in references to
arrays in which the mapping from original to randomised position is
stored. However, in the old JSDescription constructors, the caller also
passed the inputs and outputs themselves by reference, and those arrays
were also randomised. The JSDescriptionInfo constructor was instead
taking these by value, meaning that its internal copies were being
randomised, but not the caller's arrays. This caused the Sprout payment
disclosure logic to (with 1/2 probability) store the incorrect output
in a payment disclosure key.
This commit restores the previous behaviour, by storing references to
the input and output arrays in JSDescriptionInfo instead of copying them.
This matches the existing transaction builder structs:
- SpendDescriptionInfo
- OutputDescriptionInfo
- TransparentInputInfo
It also removes the dependency of the transaction format on the proving
system.
Refactor ProofVerifier
`ProofVerifier` was previously used to conditionally verify pre-Sapling Sprout
proofs (based on `ProofVerifier::Strict` or `ProofVerifier::Disabled` being
used), but hybrid Sprout proofs bypassed it (so were being verified multiple
times during block verification), and once `libsnark` was removed in
zcash/zcash#4060 `ProofVerifier::check` was doing nothing.
This PR refactors `ProofVerifier`, moving it out of the `libzcash` compilation
unit (so that it can depend on `primitives/transaction.h`), and moving Sprout
verification from `JSDescription::Verify` to `ProofVerifier::VerifySprout`.
Verification-skipping for Sprout proofs is re-introduced.
Additionally, the `ZCJoinSplit` global is removed from the codebase, and
`ZCJoinSplit::prove` is converted into a static function. We load the hybrid
Sprout parameters dynamically at proving time within the Rust code, and no
longer require a C++ global for any proving parameters.
As a side-effect, `libzcashconsensus.la` building with `--with-libs` is fixed,
as `primitives/transaction.cpp` no longer depends on `librustzcash.h`.
We don't support making pre-Sapling JoinSplit proofs, and we load the
parameters for post-Sapling JoinSplit proofs at proving time, so there
is no need for a global ZCJoinSplit to be passed through the APIs.
Add funding streams to consensus parameters.
Add funding stream payments to coinbase txns generated by the miner.
* Reduce valueBalance for shielded outputs to funding streams.
* Ensure we produce binding signatures in any case where shielded
outputs go to either a funding stream or the miner.
This change improves usability across network upgrades, by informing
users when their new transactions are being created with the consensus
branch ID from the previous epoch.
We only check failing signatures against the previous epoch to minimise
the extra computational load on nodes.
This reduces the amount of information that is leaked by the choice of anchor.
In future we will make a protocol change to enforce that all inputs use the
same anchor.
Jack Grigg
Kris Nuttycombe
str4d
Kris Nuttycombe
Homu
Eirik Ogilvie-Wigley
Daira Hopwood