Context? Zero explanation of "why"

Useful from JSON-RPC implementations where it's not possible to have direct control over the text of numbers (e.g. where numbers are always doubles), and it's still desired to send an exact value.

See also #3759 for previous discussion - I hadn't thought any more context was necessary here.

@laanwj Someone looking at the git commit will have no idea about any of that background context...

Commit messages should answer "why?" not just "what?"

Ok, don't feel like this discussion, closing...

Hmm.. i think this is useful.
For the new wallet i did implement something similar (val.setNumStr(val.get_str()); see -> https://github.com/jonasschnelli/bitcoin/blob/2015/05/corewallet/src/corewallet/corewallet_rpc.cpp#L109).

This would allow users to post JSON content with encoded numbers like {"value": "0.00000001"} instead of "value": {0.00000001} which some php/python encoders wrap into 1e-8.

@jonasschnelli Yes, that's exactly the idea.

As a reminder, the conclusion from #3759 was to use satoshi/integer Numbers, not to stringify...

@luke-jr But that would be a major API change, while this could be used today and does not introduce any 1 satoshi versus 1 BTC magnitude risk.

I think using int Satoshis for all values in RPC would make sense. But as @laanwj said, this would be a major API change with many risks. And i also think that people are "thinking" in BTC rather then in Satoshis. Somehow this is a legacy we have to deal with.

Nevertheless this PR would also be a slightly API change. In the current releases (before UniValue) and in the current master, numbers encapsulated in string did made bitcoind throwing an exception.

UniValue internally stores everything as a string, that's why i think this PR makes sense and can be seen as a save solution. The only risk i see is that it could be possible that API users/apps expect that sending a string where a btc value is required should throw an error.

I like this pull as well. We fixed the JSON parsing in #6379 , but what's to say somebody won't be dealing with a broken JSON composer on their end. This provides a nice safe alternative.

ACK

ACK. Thanks for updating the commit.

ACK. We shouldn't forget to mention this in release notes if it gets merged.

Yes, and needs to be exercised at least once in the RPC tests as well.

Tested ACK.
RPC test extension for wallet.py : jonasschnelli@39b4437

Cherry-picked @jonasschnelli 's test. Thanks!

Added small mention in release notes.

reACK