Topic: Subcent Payments; RPC ver 0 vs 1 (Read 1439 times)
Whoever voted "Other" could please offer another solution?
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.
The GUI sucks, so I am fine pretending it doesn't exist.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.
Both solutions fix the other problem you do care about, except possibly that the .000001 fraction is not representable accurately by binary floats.
It's fine if you don't personally care about no-FPU or TBC, but please don't actively fight/interfere with progress.
(FWIW, many older ARM do /not/ have a FPU, and even with systems that do have a FPU, integer is usually faster)
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.
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.
Maybe we can use the same exponent-style encoding we invented for the URI Scheme for manual user input on the commandline and use raw int64 in JSON? It's too easy to append 9 zeros instead of 8 on a keyboard.
RPC results should then return raw int64 values.
RPC results should then return raw int64 values.
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..", 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
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.
Jump to: