ZIP 212 alters the note plaintext to store a seed from which rcm is
derived, rather than storing rcm directly. In the mobile SDKs we only
need rcm, so for post-ZIP 212 notes, we derive rcm from the seed and
store rcm in the data DB.
However, when selecting notes to spend, `create_to_address` was using the
transaction's target height to determine if Canopy is active, and parsing
the rcm value as the seed if so. This effectively applied a seed->rcm
derivation to all selected notes' rcms once Canopy activated on the
chain. As a result, the note commitments were incorrect, and thus the
anchors derived from the witness paths were also incorrect. This caused
two kinds of observed failures:
- If more than one note was selected, the builder would fail with
"anchor mismatch", as the note commitments would be effectively
randomised, causing the derived anchors to also randomise.
- If a single note was selected, the transaction would be built using
the randomised anchor, and then rejected when sent to the network.
The fix is to "pretend" in `create_to_address` that all notes are
pre-ZIP 212 notes. This works fine because we never need to serialize
back to the note plaintext while spending a note.
In the interest of making the library usable for both
testnet and mainnet without recompilation, static resolution
of network parameters has been replaced with a parameter passed
to the relevant functions. This also moves addres prefix constants
into the network parameters.
We don't need to check if epk is in the prime-order subgroup before we
trial-decrypt, which saves a third of the cost of trial-decrypting
outputs that are not ours.
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.
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.