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.
Rpc test cleanup
The main purpose of this PR was to inline the method 'wait_for_async_operation_id' from util.py in tests where we were doing this manually. To make it work in all cases, I had to change the method to return the result in the case where the call failed. I also did a bit of general clean up (removing semicolons) in the files which I changed.
Sapling keys generated from the seed are not yet persisted, so we don't
want to persist the seed or chain state either, otherwise the wallet
could end up in an inconsistent state.
Some tests are temporarily disabled because commenting out HDSeed
persistence breaks invariants inside CCryptoKeyStore.
Revert this commit during the PR for #3388.
generalize mininode.py protocol versioning
Fixes#2982 -- replace `overwintered` boolean argument to NodeConn constructor with a protocol version integer, so that adding Sapling (and beyond) will be easier.
Fix absurd fee bug reported in #3281, with tests
This was ported from the Hush `absurd_fee_bug` PR: https://github.com/MyHush/hush/pull/136
Tests executed with `./qa/pull-tester/rpc-tests.sh wallet` and pass on Ubuntu 16.04. Some tests were added for previously untested behavior as well.
Closes#3281.
Add change indicator
This adds to the json returned when calling z_listreceivedbyaddress and z_listuspent an additional field entitiled 'change' which will be either true or false depending on whether or not the note was change from another transaction.
(rpc-test) accurately account for fee without rounding error
Fix for #2807, this test compares balances after doing key exports and imports, and expects these balances to be equal. But they are not exactly equal due to transaction fees, so the test makes them "equal" by rounding a value that has had fees taken out up to the nearest hundredth of a unit (which is much more than the default fee). This obviously is somewhat sloppy. It also converts a balance to float, which really should never be used due to loss of precision (use Decimal instead).
This change makes the test accurately account for the fee using precise comparisons, and removes the use of float. This test doesn't depend on the default fee (0.0001) but instead sets the fee (to that value). This way, if the default fee changes in the future, this test will continue to run. While testing these changes, I set the fee to various values (up to the max, 0.0190), and the test still passes.
