Requires the bundled-prover feature, which enables the
wagyu-zcash-parameters crate and adds around 50 MiB to the overall
binary size. That crate bundles the same Sapling parameter files we
normally obtain from disk, so we constrain them to match the same
hard-coded hashes.
This enables an SQLite light client to specify whether recipient history
can be recovered from the block chain (and by what outgoing viewing key)
with per-transaction granularity.
The canonical verification API from Heartwood activation is the
recursive API exposed through is_valid_solution. We retain
is_valid_solution_iterative internally for testing.
This provides a way to expose a more fine grained measure of scan progress. For example, by scanning in batches of 100 blocks, rather than everything that is pending.
Wnaf was originally generic over CurveProjective; in the prior refactor
commit, we renamed this to CofactorCurve. But w-NAF only requires scalar
multiplication, which is provided by the Group trait, so we relax the
bounds on Wnaf to enable it to be used with any group. We move the
generic w-NAF helper methods from the Curve trait to a new WnafGroup
extension trait, to keep the w-NAF API surface self-contained, and not
expose it to users who aren't using it.
Instead of having the Group crate hold a Subgroup associated type (and
thus needing to define the subgroup of a prime-order group as itself),
we specify two separate sets of traits for prime-order groups and ones
with a cofactor.
Protocol implementors can either restrict their implementations to only
work with PrimeGroup, or can explicitly choose to support CofactorGroup
and then explicitly handle the subgroup edge cases with e.g.
CofactorGroup::mul_by_cofactor (which would be a no-op for PrimeGroup).
Protocol implementors can also choose to specialise to elliptic curves
if they want to leverage an affine representation and mixed addition in
their protocol for efficiency, or they can ignore those traits and stick
with the simpler group-focused traits.