Don't go through double in AmountFromValue and ValueFromAmount

[laanwj]

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. By using fixed-point parsing and formatting already available, this avoids risky double-to-integer and integer-to-double conversions completely, and results in more elegant code to boot.

Also contains a related dead code cleanup commit for FormatMoney.

[jgarzik]

Indeed - that was the intention RE stored as strings - great work @laanwj

"it works" tested ACK

[laanwj]

I just noticed that there is a slight change of semantics here. The old check dAmount <= 0.0 || dAmount > 21000000.0 did not allow zero amounts, whereas MoneyRange allows nValue >= 0 && nValue <= MAX_MONEY.

Unsure what to do here. The no-brainer solution would be to restore the old behavior, however

• There is one place in the source where this is worked around with an ugly hack: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcwallet.cpp#L2172
• The other places where AmountFromValue is used are sendtoaddress movecmd sendfrom sendmany

The alternative would be to handle zero-ness at the other call sites, which is feasible as they are few. It would be less surprising to handle specific constraints like this at the call side instead of the parser function. Whatever is decided there should be a test for this in rpc_parse_monetary_values.

[Diapolo]

Just wanted to mention that PaymentServer::verifyAmount() also uses MoneyRange().

[laanwj]

@Diapolo True, but not relevant here, I'm not intending to change MoneyRange's semantics.

[jonasschnelli]

Nice!
Tested and reviewed ACK.

[laanwj]

@jonasschnelli What do you think about the range issue mentioned in my comment above?

[jonasschnelli]

@laanwj: If we take a closer look at a AmountFromValue, than i think, CAmount can be 0 so AmountFromValue() should also be able to handle 0ness. Even, a single function must not/should not represent the behavior of the whole system (if someone would define our system behavior to reject 0 values everywhere).
AmountFromValue is also used in createrawtransaction and there i could imaging usecases for 0 value in/outputs (to replace later by some hex/further manipulating, etc.).

Therefore ACK this solution (even if it's a slightly API change).
And yes, adding a test for a 0 value would probably be a good idea.

[laanwj]

Thanks. Pushed a commit that adds the checks to caller sites where needed, and adds tests.