CreateJoinSplit: add start_profiling() call
This solves the problem of profiling output from the CreteJoinSplit benchmarking binary displaying nonsensical large time values.
Only increment new notes on reindex
Addresses another issue in #1904.
When an existing one of our notes was found again, its cache was reset and it was re-witnessed. This would cause encountered notes to get out-of-sync with the otherwise-ignored newer notes, which could be a problem if the wallet data happens to be written out during a reindex.
Additional well-formedness check for G2 elements
libsnark currently checks that G<sub>1</sub> and G<sub>2</sub> elements are well-formed by ensuring that they satisfy their respective curve equations, and although this is enough for G<sub>1</sub> (which is instantiated as an order r curve E/F<sub>p</sub>: y^2 = x^3 + b), G<sub>2</sub> is the order r *subgroup* of the composite order r(2q-r) curve E'/Fp<sup>2</sup>: y^2 = x^3 + b/e constructed via a sextic twisting isomorphism. This means we need to ensure these points are order r as well.
None of the proofs on the Zcash blockchain violate this check, and it may not even be possible for them to violate this check (bilinearity is not preserved). Let's be cautious and do it anyway.
Write witness caches when writing the best block
For steady-state operation, this reduces the average time between wallet disk
writes from once per block to once per hour.
On -rescan, witness caches are only written out at the end along with the best
block, increasing speed while ensuring that on-disk state is kept consistent.
Witness caches are now never recreated during a -reindex, on the assumption that
the blocks themselves are not changing (the chain is just being reconstructed),
and so the witnesses will remain valid.
Part of #1749.
Gather release notes from previous release to HEAD
Release-notes.py used to depend on release already being tagged--now gathers release notes from previous tagged release up to current HEAD.
Closes#1857. Fixes bug where a transaction sending from a zaddr would have a priority of zero.
Transactions sent from a zaddr should now be mined sooner as they no longer have a priority of zero
Isolate verification to a ProofVerifier context object that allows verification behavior to be tuned by the caller.
This is an alternative foundation for #1892, i.e., #1892 will have to be changed if this PR is accepted.
I think this is a safer approach because it allows us to isolate verification behavior to a single object. This will come in handy when @arielgabizon finishes the batching code.
