Address @str4d's comment on #1965 about the case where -gen is not set
https://github.com/zcash/zcash/pull/1965#discussion_r100414069
Note that the case of calling the ``setgenerate true`` RPC with the wallet disabled was already handled correctly.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
Convert entire source tree from json_spirit to UniValue
This PR cherry-picks bitcoin/bitcoin#6121 and then migrates the Zcash-specific code to UniValue.
Also cherry-picks:
- bitcoin/bitcoin#6241
- bitcoin/bitcoin#6234
Closes#1985.
JSON makes no distinction between numbers and reals, and our code
doesn't need to do so either.
This removes VREAL, as well as its specific post-processing in
`UniValue::write`. Non-monetary amounts do not need to be forcibly
formatted with 8 decimals, so the extra roundtrip was unnecessary
(and potentially loses precision).
Zcash: cherry-picked from commit 7650449a6777710cf818d41862626164da0cd412
Dropped changes to qa/rpc-tests/rest.py pending addition of /rest/headers/
This is the format that was always returned to JSON clients.
The difference was not noticed before, because VREAL values
are post-processed by univalue.
By implementing the functionality directly it breaks the dependency
of rpcserver on utilmoneystr. FormatMoney is now only used for debugging
purposes.
To test, port over the formatting tests from util_tests.cpp to
rpc_tests.cpp.
Add a function `ParseFixedPoint` that parses numbers according
to the JSON number specification and returns a 64-bit integer.
Then this in `AmountFromValue`, rather than `ParseMoney`.
Also add lots of tests (thanks to @jonasschnelli for some of them).
Fixes issue #6297.
- Add an accept test for zero amounts, and a reject test for negative
amounts
- Remove ugly hack in `settxfee` that is no longer necessary
- Do explicit zero checks in wallet RPC functions
- Don't add a check for zero amounts in `createrawtransaction` - this
could be seen as a feature
My prime gripe with JSON spirit was that monetary values still had to be
converted from and to floating point which can cause deviations (see #3759
and https://bitcoin.stackexchange.com/questions/22716/bitcoind-sendfrom-round-amount-error).
As UniValue stores internal values as strings, this is no longer
necessary. This avoids risky double-to-integer and integer-to-double
conversions completely, and results in more elegant code to boot.
Strict parsing functions for other numeric types.
- ParseInt64 analogous to ParseInt32, but for 64-bit values.
- ParseDouble for doubles.
- Make all three Parse* functions more strict (e.g. reject whitespace on
the inside)
Also add tests.
Simon
Jay Graber
Leo Arias
zkbot
Jack Grigg
Cory Fields
Wladimir J. van der Laan
Jonas Schnelli
Jonas Schnelli