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.
Assets:
change tokeninfo to return "supply" in satoshis
Max description length to 4096
Rewards:
Fix rewardsunlock without giving it a locked txid always gives error
Fix (nonconsensus) allow anybody to unlock only AFTER maxtime
Fix rewards unlock to use mempool
fix could you add a locked_funds value to rewardsinfo?
Fix i deposited 100000 at 20% apr for one day i only got back
100000.01140669 seems like too little for 20% APR
Faucet:
Fix txid with 0x00 at beginning and end required for faucetget txid
(65536 average iterations needed)
Change reduce faucet get to 0.1 coins
Can’t reproduce: it seems that if you re-run faucetget twice in the
same block is when it pegs the cpu to max
Dice:
fix Dice status always returning loss
Wont fix Profit margin for dice plan sounds good. -> use -ac_commission
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).
