Don't write this. Some people might be silly enough to think you're serious, and we'll have to explain them again.
You can't be serious... 
Topic: [RFC] Sub-cent-precision - page 2. (Read 6240 times)
I understand it's only an internal representation of the same thing, but there can be subtle but long term psychological effect, especially to those who deal with the APIs.
Many financial libraries deal with whole cents instead of decimal dollars and cents, but there has been no long term psychological effect.Some things in life are worth worrying about, but internal numeric representation is not one of them.
Don't write this. Some people might be silly enough to think you're serious, and we'll have to explain them again.
I was only half-joking. Seriously, I understand it's only an internal representation of the same thing, but there can be subtle but long term psychological effect, especially to those who deal with the APIs. technically using integer is a better solution; morally it's wrong -- we just inflated our money supply 10^8 times.
Don't write this. Some people might be silly enough to think you're serious, and we'll have to explain them again.
technically using integer is a better solution; morally it's wrong -- we just inflated our money supply 10^8 times.
Yeah, forget about floating points. Use integers.
I also prefer Idea 2.
This thread already existed in https://www.bitcoin.org/smf/index.php?topic=3028.0
sipa's "Idea 2" sounds exactly like "RPC v1", while gavin's "counter-proposal" sounds like "RPC v0 without rounding".
Of the voters, 3 prefer to not fix the problem at all, while 6 want it fixed. Of those 6:
- 3 want RPC v1 (base bitcoin integers; aka sipa's "Idea 2")
- 2 want RPC v0 without rounding (gavin's "counter-proposal")
- 2 voted for another (unspecified) solution (maybe sipa's "Idea 1"?)
I personally prefer RPC v1/sipa's Idea 2. This is already written in a backward-compatible form in my "neutral" branch. This way, the old/current method of centi-BTC precision BTC values can be supported by default for another N months while new code is concurrently designed for the newer API, and old code ported gradually. After that time, the default can be changed to RPC v1. After more time, especially if someone is having problems porting the old code (I'm not sure what the deprecated functions did), the older RPC v0 can be removed so as to not clutter the code for future development.
vladimir: RPC v1/sipa's Idea 2 *is* moving all APIs to centi-micro-BTCs (the low-level cannot support nano-BTC precision).
sipa's "Idea 2" sounds exactly like "RPC v1", while gavin's "counter-proposal" sounds like "RPC v0 without rounding".
Of the voters, 3 prefer to not fix the problem at all, while 6 want it fixed. Of those 6:
- 3 want RPC v1 (base bitcoin integers; aka sipa's "Idea 2")
- 2 want RPC v0 without rounding (gavin's "counter-proposal")
- 2 voted for another (unspecified) solution (maybe sipa's "Idea 1"?)
I personally prefer RPC v1/sipa's Idea 2. This is already written in a backward-compatible form in my "neutral" branch. This way, the old/current method of centi-BTC precision BTC values can be supported by default for another N months while new code is concurrently designed for the newer API, and old code ported gradually. After that time, the default can be changed to RPC v1. After more time, especially if someone is having problems porting the old code (I'm not sure what the deprecated functions did), the older RPC v0 can be removed so as to not clutter the code for future development.
vladimir: RPC v1/sipa's Idea 2 *is* moving all APIs to centi-micro-BTCs (the low-level cannot support nano-BTC precision).
I split this into it's own thread.
Here's a counter-proposal:
All RPC methods dealing with amounts take and report full-precision bitcoins.
E.g. if you have 1 BTC getbalance reports 1.00000000 (as it does now)
The send and move methods will be changed to NOT round to two decimal places.
luke-jr's patch that makes bitcoin avoid creating sub-cent change (when possible) will be applied.
The GUI will be modified to display full precision amounts, and will allow full-precision sends.
(if you have 1 BTC, GUI should show balance: 1.00
if you have 1.0001 BTC, GUI should show balance: 1.0001
...etc)
A new setting: maxtxfee will be added, default will be 0.01 BTC. RPC methods will fail with a new error message if a send/sendfrom would generate a transaction fee larger than maxtxfee.
A new RPC method to change maxtxfee setting (maybe a generic RPC method to change any run-time option that can be changed on the fly?)
The code should be checked and all references to CENT which really mean "minimum transaction fee" should be changed to reference a new "minimum transaction fee" constant (==CENT for now).
Here's a counter-proposal:
All RPC methods dealing with amounts take and report full-precision bitcoins.
E.g. if you have 1 BTC getbalance reports 1.00000000 (as it does now)
The send and move methods will be changed to NOT round to two decimal places.
luke-jr's patch that makes bitcoin avoid creating sub-cent change (when possible) will be applied.
The GUI will be modified to display full precision amounts, and will allow full-precision sends.
(if you have 1 BTC, GUI should show balance: 1.00
if you have 1.0001 BTC, GUI should show balance: 1.0001
...etc)
A new setting: maxtxfee will be added, default will be 0.01 BTC. RPC methods will fail with a new error message if a send/sendfrom would generate a transaction fee larger than maxtxfee.
A new RPC method to change maxtxfee setting (maybe a generic RPC method to change any run-time option that can be changed on the fly?)
The code should be checked and all references to CENT which really mean "minimum transaction fee" should be changed to reference a new "minimum transaction fee" constant (==CENT for now).
Part of the problem is that the JSON-RPC interface is used for both communication with humans (most of whom prefer a decimal representation in bitcoin), and other software which may benefit from having an easier/safer representation as integers (because it does its own formatting/parsing when communicating with humans).
Idea 1:
Idea 2
On the other hand, maybe it is not the responsibility of the server to support different encodings of amounts. Since the primary purpose of the JSON RPC interface is imho a standard way of communication with software (not people) interacting with bitcoin, it should be as simple/safe as possible, and use integers (since this has the least chance of causing rounding errors in client software, as explained by others in this thread), and give the responsibility of formatting numbers to client software (which should use integers to represent amounts internally anyway, if it does any form of processing on them). The CLI interface could then take care of providing the optional-encodings scheme outlined above.
Personally, I prefer the second idea.
Idea 1:
- by default, all communication uses JSON numbers representing the interger count of bitcoin units (1E-8 BTC)
- The JSON-RPC server (being bitcoin, bitcoind, some proxy, some other implementation) may optionally support input using other encodings for numbers, which must be represented as a JSON string, ending in a suffix denoting the encoding (eg. ending the string with " BTC" means decimal bitcoin representation - which can by the way be parsed perfectly to units without any floating-point code). Using a non-supported encoding should cause a clear error message.
- The JSON-RPC client can ask the server for a particular encoding as an argument to the RPC function called, causing an error if that encoding isn't supported.
- The CLI bitcoin interface could use the " BTC" encoding by default.
- Additional encodings can easily be added, or provided by a wrapper script, ..., by only requiring that all servers and clients must support number-encoded integers.
- Some names of functions or arguments would need to be changed, to ensure that no program using the old API accidentaly sends 0.00000050 BTC instead of 50 BTC.
Idea 2
On the other hand, maybe it is not the responsibility of the server to support different encodings of amounts. Since the primary purpose of the JSON RPC interface is imho a standard way of communication with software (not people) interacting with bitcoin, it should be as simple/safe as possible, and use integers (since this has the least chance of causing rounding errors in client software, as explained by others in this thread), and give the responsibility of formatting numbers to client software (which should use integers to represent amounts internally anyway, if it does any form of processing on them). The CLI interface could then take care of providing the optional-encodings scheme outlined above.
Personally, I prefer the second idea.
Jump to: