I think use floating-point numbers in JSON is not safe. Especially in the case of expressing prices.

I think use floating-point numbers in JSON is not safe. Especially in the case of expressing prices.

If not, it may be knida confusing for users when invoking calculatenetworkfee in RPCServer.

We should uniformly use long to ensure accuracy.

We should uniformly use long to ensure accuracy.

But currently we use float value for json output like json["gasconsumed"].

But currently we use float value for json output like json["gasconsumed"].

I think we should use long for JSON output.

So should we uniform both the user input and the JSON output in long type?

For JSON, I think we should use long for both requests and responses.

For JSON, I think we should use long for both requests and responses.

The asset amount(fees and NEP-17 tokens) is now in decimal format in both neo-cli and RpcServer.
e.g.

"sysfee": "0.0900799",
"netfee": "0.0124845",
"amount": "30000046.99999955",
"balance": "30000016.38985890"

neo-cli command:
deploy
invoke
balanceof
totalsupply
transfer
etc.

RpcServer：
calculatenetworkfee
getapplicationlog
getblock
getblockheader
getrawtransaction
getunclaimedgas
getwalletunclaimedgas
invokecontractverify
invokefunction
invokescript
sendfrom
sendmany
sendtoaddress
getnep17balances
getnep17transfers
getwalletbalance

I think use floating-point numbers in JSON is not safe.

They really are, we had problems with rounding errors.

For JSON, I think we should use long for both requests and responses.

But we can wrap them into strings, returning "value": "0.12345678" instead of "value": 0.12345678. This representation is much more convenient to me (especially for everything that is not GAS or NEO where the number of decimals is well-known, it's not for $RANDOM_TOKEN). And it avoids any losses when converting to/from JSON.

I mean BigDecimal.ToString() doesn't introduce any rounding errors and neither does TryParse(), so we just need to avoid going through floating point everywhere we're dealing with these values and we'll be fine.

Wrapping BigInteger into string in JSON is okay for me.

move to #505