Reported on IRC
<freik> Wow, just accidentally sent 1 BTC, due to a double-paste error. $ bitcoin-cli sendtoaddress 1address 1address
<freik> It parses the 1 from the 2nd '1address' and sent it
<freik> guess i should be glad the next digit was hex
There could be a set of mutation tests for common typos likely to happen with bitcoin-cli. Some of these may not be RPC issues?
This appears to be a problem with bitcoin-cli, not the RPC server. e.g. AmountFromValue calls value.get_real() which will raise an exception if the value is not a number.
But bitcoin-cli's command line to JSON parsing (RPCConvertValues) probably has no proper error handling. If so, I'm surprised this only gets discovered now.
I reproduce this on master:
src/bitcoin-cli -testnet sendtoaddress msj42CCGruhRsFrGATiUuh25dtxYtnpbTx 1.0sds
Paradoxally, it looks like #6121 solves it (the new JSON parser is more thorough?):
src/bitcoin-cli -testnet sendtoaddress msj42CCGruhRsFrGATiUuh25dtxYtnpbTx 1.0sds
error: {"code":-32700,"message":"Parse error"}
I've narrowed it down to the JSON parser. Added the following tests, which should pass, but fail:
BOOST_CHECK_EQUAL(read_string(std::string("1.0sds"), value), false);
BOOST_CHECK_EQUAL(read_string(std::string("1.0]"), value), false);
Somehow trailing characters don't affect it. Prefixing character does. This passes:
BOOST_CHECK_EQUAL(read_string(std::string("[1.0"), value), false);
UniValue does parse JSON more strict and handles some special cases manually. Maybe this is fixed after merging #6121 but it would need at least a fix for 0.11 if we like to get this fixed there. Will also investigate soon.
@jonasschnelli I'm already looking into this - read_string currently doesn't check that it consumed the entire input stream, it's an easy fix, which makes sense to merge into 0.10 and 0.11.