This could in future be refactored to be generic over PaymentAddress and
NotePlaintext in the return type, but for now let's be explicit about which
returned notes are for Sprout vs Sapling, and handle them separately.
Co-authored-by: Sean Bowe <ewillbefull@gmail.com>
Track Sapling notes and nullifiers in the wallet (in-memory only, no persistence to disk)
Part of #3061. Add in-memory tracking of Sapling notes and nullifiers to the wallet.
Set Sapling mainnet activation height
In mainnet, block #419200 is expected to appear on October 28, 2018, Zcash's birthday.
In testnet, block #280000 is expected about a week from now. (Current height is ~275249, plus 4032 blocks for a week, plus a little more just to make the number nice.)
These are the activation heights for Sapling in mainnet and testnet, respectively. Protocol version is also changed.
Always write the empty root down as the best root, since we may roll back
In [`3577de83`](3577de83aa) we started not writing the Sapling empty root down as the "best" anchor because we had changed the encodings and didn't want users who compiled from master to have inconsistent coindb's in the future if the encoding changed again for some reason.
However, if we don't write the empty root down then during rollbacks to Sapling activation we leave the best anchor on disk different from what's in the cache, which will trigger an assertion.
This reverts the change from `3577de83` since we've settled on the encodings.
We need separate functions for checking Sprout and Sapling nullifiers,
because they are in separate domains and aren't guaranteed to be
collision-resistant (otherwise there is a possibility of a nullifier
collision, however remote, between Sprout and Sapling causing the spend
of one to prevent the spend of the other).
When diversified addresses are supported, iterating over
mapSaplingIncomingViewingKeys will be inefficient as the mapping will
be addresses->ivk (n:1).
