As of zcash/librustzcash#633, `SaplingDomain::IncomingViewingKey` now
allocates memory internally, and this memory persists as long as the
`BatchRunner` is alive. Now that we have decoupled the measurement of
heap usage for batch tasks from their internals, we can add bounds to
all of the generic parameters of `Batch` to enable correctly measuring
their actual heap usage.
Ported from zcash/librustzcash@913aa0a988.
Currently supports Zcash blocks, block headers, and transactions. Some
consensus rules are also checked, and a JSON context object can be
optionally passed to provide any necessary details for extra contextual
consensus checks.
The primary purpose of this commit is an exercise in using `cargo vet`
for tracking audits of our Rust dependency updates. `cargo update` was
run, and then a simple-to-audit subset of the dependency updates were
audited and committed.
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
We still depend on it indirectly, but we don't use it directly anymore
since we upstreamed our patch to `metrics-exporter-prometheus`.
`thiserror` is also only used by the wallet tool, so has been reordered
accordingly.
`hyper 0.14.18` stops building the C libraries by default (after opt-in
support was added via a new flag in nightly Cargo), which means we no
longer have the problem of the `cdylib` build requiring a linker to be
hooked up to the Rust build when all we want is a `staticlib`.
For consistency, we serialize the `finalState` field in the
same (sparse) encoding as Sapling and Sprout use. In the future
we may want to update this to the dense encoding that
incrementalmerkletree::bridgetree::Frontier uses, but that's not
necessary for the moment.
When initializing a new Orchard wallet after NU5 activation, it is
not valid to start from the empty note commitment tree; instead,
the note commitment tree needs to be initialized from the state of
the global Orchard Merkle frontier.
In addition, this change necessitates a change to how rewinds work,
such that in a rollback scenario with a newly initialized wallet
that does not have sufficient checkpoints to fully satisfy a requested
rewind, the rewind is allowed to proceed so long as it does not
invalidate any persisted witness data.
This includes:
- `orchard =0.1.0-beta.3` which includes the final circuit changes.
- The new NU5 consensus branch ID.
- Updated ZIP 244 test vectors (which use the NU5 consensus branch ID).
This method detects and returns metadata for any notes belonging to the
wallet that are spent in the transaction. It also trial-decrypts the
Orchard outputs of a transaction using the wallet's incoming viewing
keys along a set of OVKs provided by the caller, and returns metadata
about the notes that were successfully decrypted.
Jack Grigg
Jack Grigg
Kris Nuttycombe
Daira Hopwood
Alex Wied
therealyingtong