I'm creating this thread to discuss two branches I have, titled RPCv0SubcentInputs and 'neutral'.

RPCv0SubcentInputs merely removes the code which rounds RPC inputs to centi-BitCoins. This breaks compatibility slightly, specifically with any code that assumes the RPC inputs will be rounded. There is also a possibility that if the system's FPU cannot accurately represent the fraction, the input might be interpreted slightly differently than it should be. For example, 0.1 BTC cannot be represented as a binary floating-point number.

"Neutral" bumps the BitCoin RPC version from 0 to 1, prepending (over-the-wire only) methods with "bitcoin.<version number>.", and removes (in principle) all the methods which were marked as "deprecated" in the source. Instead of using floating-point Decimal BitCoin values (BTC), int64 raw/base Bitcoin values are used for all inputs/outputs. This achieves 1) better efficiency, especially on systems without a FPU, 2) no possible floating point precision issues, and 3) low-level is now unit-neutral (BTC vs TBC vs etc). By default, for backward compatibility, the command line arguments default to version 0. To make version 1 calls, prepend the commandline with -rpcversion=1

Can you back up and describe what problems your patches solve?

Here are the problems I care about:

+ If a user receives 1.000001 bitcoins, there is currently no way to transfer the entire amount somewhere else using either the GUI or the RPC.

+ If a user receives 1.000001 bitcoins, the GUI will tell them they have 1.00.

I don't care about systems without a FPU-- are there any such systems that bitcoin actually runs on?

I don't care about BTC vs TBC.

Whoever voted "Other" could please offer another solution?