We do not need to be able to calculate multiple SignatureHash versions for a
single transaction format; instead, we use the transaction format to determine
the SigVersion.
The consensus branch ID *does* need to be passed in from the outside, as only
the caller knows the context in which the SignatureHash is being calculated
(ie. mempool acceptance vs. block validation).
JoinSplit signature verification has been moved into ContextualCheckTransaction,
where the consensus branch ID can be obtained.
The argument to the sign command for zcash-tx has been modified to take a height
in addition to the optional sigtype flags.
Fixes#2480 where missing map entry would cause a segfault.
`wtxHeight = mapBlockIndex[wtx.hashBlock]->nHeight;` results in undefined behaviour when the block hash is not present in the map, returning a null value which is dereferenced via `->nHeight`. This error is triggered by a zero-conf wallet transaction which has not been mined yet. As discussed in #2480, on some systems there is a segfault whilst on others there is a silent exit. This makes it difficult to write a test, but the fix has been tested empirically to confirm an exception is thrown. This PR fixes the segfault and complements #2525 which prevents a user from sending from a zaddr with minconf 0.
Add ability for node to reject tx from mempool by number of tx inputs
Implement short-term solution described in #2343 so that users can respond promptly to critical short-term problems caused by quadratic validation scaling, such as the getblocktemplate latency, block propagation latency, and mempool size inflation issues described in #2333.
after a successful sign and send, meaning that the logged hash fragment
would be different from the txid logged by "AddToWallet". This issue
occured when sending from transparent addresses, as utxo inputs must be
signed. It did not occur when sending from shielded addresses.
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.
