When responding to "mempool" message, do not include the txid of an
expiring soon transaction in the "inv" message reply.
When responding to "getdata" message, do not reply with a "tx" message
for a transaction which is expiring soon.
Don't accept transactions which are about to expire (next 3 blocks).
Don't set a ban score if a peer does propragate these transactions.
See ZEC-013 for more detail.
Load sapling chain value into memory
`CBlockIndex::nSaplingValue` has been correctly set and written to disk since before Sapling activated, meaning that all nodes now are correctly tracking the Sapling shielded pool value on-disk. However, on restart the per-block values are not being read into memory, and so the in-memory pool value appears to be zero on every restart. Setting `nSaplingValue` in-memory during block index loading fixes the problem.
3604 fix sapling default memo - 0xF6 plus zeros
Closes#3604. For Sapling outputs, set the default memo to `no_memo` instead of all zeros. (See section 5.5 of the Sapling protocol specification.)
Better error message when sending to both sprout and sapling
When trying to send to both Sprout and Sapling (not currently supported with z_sendmany) we were getting the following error in our operation result: `general exception: boost::bad_get: failed value get using boost::get`.
This PR changes this to fail with a better error message before the async operation begins:
```
error code: -8
error message:
Cannot send to both Sprout and Sapling addresses using z_sendmany
```
Fix signing raw transactions with unsynced offline nodes
This PR address the issue in two different ways:
- In `signrawtransaction` we determine the consensus branch ID (which we then later use to construct the transaction) using the chain height. We now also consider the `APPROX_RELEASE_HEIGHT` as this is a better estimation than 0 for the height of the chain if we are unsynced. (This in and of itself solves the Overwinter signing issue).
- We have added an additional parameter to `signrawtransaction` to allow manually overriding the consensus branch ID that zcashd determines we are on. This allows users to work around corner cases where the first strategy is still insufficient.
Closes#3327.