This should achieve similar performance gains to "fat" LTO (which we
were previously using) while taking substantially less time to run
(over 20s saved on a Ryzen 9 5950X).
Part of zcash/zcash#6065.
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.
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.
Jack Grigg
Kris Nuttycombe
Jack Grigg
Daira Hopwood
Alex Wied