BTW this same design can be trivially used to send monetary values via RPC in any desired way. For example, a mode that returns and takes satoshis as integer is just a matter of adding the necessary option parsing and updating ValueFromAmount and AmountFromValue.

Something like

--rpcamountsmode=double (default, legacy)
--rpcamountsmode=string
--rpcamountsmode=int

@laanwj I was thinking the same thing, RE outputting satoshis rather than strings or decimal numbers.

JSON has no native integer type. Outputting satoshi counts is no better than outputting Bitcoin amounts (they'll be interpreted as floating point in both case).

@sipa The former is true -- no integer type -- but the latter is not.

Outputting satoshi amounts does not automatically imply interpretation as floating point. Most libs, including our own, provide integer or Decimal interpretations without an intermediate floating point conversion step.

The options should be more bitcoin-specific, though, and are really a matrix of four possibilities:

1. JSON number, decimal (default)
2. JSON number, satoshis
3. JSON string, decimal
4. JSON string, satoshis

Well I like strings (with the . in the right place), so I want to keep that option. I'm fine with adding more possibilities of course.

-rpcamounttype=[number | string] --- JSON string or number
-rpcamountdecimal=[yes | no] --- satoshis, or no

Hmm... can we still combine it into one option somehow? I don't like two separate options affecting the monetary format, one in one place is confusing enough :-)

-rpcamount=[number-decimal, number-satoshis, string-decimal, string-satoshis]

meh. Open to suggestions... it is a quad-state.

That looks good to me.

s/decimal/btc/ (in case someone wants to do mbtc or ubtc in the future)?

@luke-jr Hmm... It was never my intention to add different units to the RPC. It's waay too easy to introduce thousandfold errors this way by having the client and server use a different setting.

Integer (in lowest possible denomination) and decimal (BTC proper) is enough IMO.

Confusion can be avoided with these four options by enforcing a . in decimal types and rejecting .. in the integer types (and rejecting strings when a number is expected and vice versa).

Edit: not that I'm against using btc instead of decimal here, it may be more consistent nevertheless.

OK implemented all four modes + added tests for them

• number-btc: Format as number in decimal BTC (default)
• number-satoshis: Format as number in satoshis
• string-btc: Format as string in decimal BTC
• string-satoshis: Format as string in satoshis

If we're seriously thinking about making such pervasive changes to the RPC interface, I'd like to go all the way, and overhaul some other things:

• Consistent method names.
• Group method names based on the subsystem(s) they interfact with; for example prefix every wallet rpc with 'wallet.' (json-rpc allows arbitrary strings as method node), others with 'util.' (no subsystems), 'blockchain.' / 'validation.', ...
• Stop using position arguments for optional flags, as they accumulate over time and become unwieldly. Instead either use a flags object (['prvikey', {'rescan': false}] instead of ['privkey', false]), or use JSON-RPC 2.0 named arguments (a larger change...).

@sipa Those all sound like good ideas to me.

I would also like to see a full blown overhaul with proper REST versioning and grouped and prefixed method names along the same lines as what sipa suggests. I'm particularly keen on the idea of using named arguments. Positional arguments are not conducive to optional arguments at all. Having spent quite a bit of time on the RPC interface, I concur that the current positional design with optional parameters is already less than ideal.

Also, I would suggest that all numeric values in regards to BTC are in satoshi. First, this would make the API more consistent since you would know any time you're dealing with a bitcoin amount, it is satoshi and not some other variant like full BTC, mBTC, uBTC, etc. Second, it would eliminate the need for using a value with a decimal in it altogether. The client would then be responsible for converting to and from satoshi depending on its particular set of needs or user preferences.

@sipa +1 to all that

@davecgh See existing pull req #2844 for a REST interface (though it is for something different, not an RPC replacement)

+1

• JSON V2 may also be a good opportunity to remove getwork.
• Regarding the wallet.* methods: it should be possible to specify which wallet they apply to in the case of multiwallet

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/f3f8460fe51be719231612a921dd37af638df46a for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

No longer going to maintain this, at some point I suppose we'll want to do a RPC overhaul and the money amounts should just be integers in satoshis.

JSON has no native integer type. Outputting satoshi counts is no better than outputting Bitcoin amounts (they'll be interpreted as floating point in both case).

@sipa luckily there are other implementations of JSON readers e.g. the world is not really always using JavaScript to parse JSON data. See also http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf (page 4):

JSON is agnostic about numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult.
JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange.

This is a closed/pretty old issue now, I don't want to do much necromancy but maybe the improvements proposed by @sipa can get their own separate PR and this one be kept about the single incremental improvement proposed in OP?