[RFC] Sub-cent-precision

[Pieter Wuille]

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:

• 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.

[1715099115]

1715099115

[Gavin Andresen]

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).

[Luke-Jr]

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).

[0x6763]

I also prefer Idea 2.

[grondilu]

Yeah, forget about floating points.  Use integers.

[bitcool]

technically using integer is a better solution; morally it's wrong -- we just inflated our money supply 10^8 times.

[grondilu]

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.

[bitcool]

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.

[ribuck]

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.

[davout]

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...

[grondilu]

Some things in life are worth worrying about, but internal numeric representation is not one of them.

LOOOL

[bitcool]

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.

"The perfect is the enemy of the good", I guess I worried too much.

for a while, I thought I had a Bernanke moment.

[ribuck]

Some things in life are worth worrying about, but internal numeric representation is not one of them.

LOOOL

Grondilu, taken in context it's clear that I'm referring to the psychological aspects of the internal representation, not the technical aspects.

[grondilu]

Grondilu, taken in context it's clear that I'm referring to the psychological aspects of the internal representation, not the technical aspects.

Don't be offended.  I just thought the sentence was itself extremly funny.  I see your point, and it's perfectly valid, even if I think you're overestimating this psychological aspect a lot.

If I own one kilogram of gold, I don't feel richer if I tell myself that I own one thousand grams.

[nanotube]

suggestion:
henceforth, 1e-8 bitcoins will be called "a bitcoin".
all bitcoin amounts will henceforth be integers.
sending 1 "oldbtc" to someone? just send 10million 'newbtc'.

solves all problems very neatly.
and also removes any psychological barriers around having "1 btc = 100usd"

EDIT: that said, i essentially like gavin's proposal, except for the cosmetics.

[grondilu]

suggestion:
henceforth, 1e-8 bitcoins will be called "a bitcoin".
all bitcoin amounts will henceforth be integers.
sending 1 "oldbtc" to someone? just send 10million 'newbtc'.

solves all problems very neatly.
and also removes any psychological barriers around having "1 btc = 100usd"

EDIT: that said, i essentially like gavin's proposal, except for the cosmetics.

I strongly disagree.

We should keep the idea of using standard prefixes.

1 centibitcoin = 10^-2 BTC
1 millibitcoin = 10^-3 BTC
1 microbitcoin = 10^-6 BTC
1 nanobitcoin = 10^-9 BTC

In Satoshi's code, the smaller unit is called "the coin".  We should use this.

1 coin = 10^-8 BTC = 10 nanobitcoins

Even if the nanobitcoin is too small a unit, we can still use it, as long as we only talk about multiples of 10.  10 nanobitcoins, 40 nanobitcoins, and so on...


An other, yet compatible possibility is to start from bottom :

1 coin = 10^-8 BTC
10^3 coins = 1 kilocoin = 10^-5 BTC
10^6 coins = 1 megacoin = 10^-2 BTC
10^9 coins = 1 gigacoin = 10 BTC

So one bitcoin would actually be 0.1 gigacoin, or 100 megacoins


Either way, the bitcoin should keep being "10^8 times the smaller unit"

[Luke-Jr]

We should keep the idea of using standard prefixes.

1 centibitcoin = 10^-2 BTC
1 millibitcoin = 10^-3 BTC
1 microbitcoin = 10^-6 BTC
1 nanobitcoin = 10^-9 BTC

In Satoshi's code, the smaller unit is called "the coin".  We should use this.

1 coin = 10^-8 BTC = 10 nanobitcoins

Even if the nanobitcoin is too small a unit, we can still use it, as long as we only talk about multiples of 10.  10 nanobitcoins, 40 nanobitcoins, and so on...


An other, yet compatible possibility is to start from bottom :

1 coin = 10^-8 BTC
10^3 coins = 1 kilocoin = 10^-5 BTC
10^6 coins = 1 megacoin = 10^-2 BTC
10^9 coins = 1 gigacoin = 10 BTC

So one bitcoin would actually be 0.1 gigacoin, or 100 megacoins


Either way, the bitcoin should keep being "10^8 times the smaller unit"

Please, this is about program internals, nothing that should ever be visible to the end user.

Also, we already have plenty of decimal units, no need for more. A "COIN" (in the code), is defined as 0.01 BTC (1,000,000 base units aka centi-micro-bitcoin aka bitcoin-bong). "One bitcoin" is, regardless of anything discussed here, to remain at 10^8 base units for the short-term (long-term, it's too large to be viable). "An bitcoin" is also to remain at 16^4 for the foreseeable future. Please see https://en.bitcoin.it/wiki/Units

[nanotube]

suggestion:
henceforth, 1e-8 bitcoins will be called "a bitcoin".
all bitcoin amounts will henceforth be integers.
sending 1 "oldbtc" to someone? just send 10million 'newbtc'.

solves all problems very neatly.
and also removes any psychological barriers around having "1 btc = 100usd"

EDIT: that said, i essentially like gavin's proposal, except for the cosmetics.

I strongly disagree.

<snip>

An other, yet compatible possibility is to start from bottom :

1 coin = 10^-8 BTC
10^3 coins = 1 kilocoin = 10^-5 BTC
10^6 coins = 1 megacoin = 10^-2 BTC
10^9 coins = 1 gigacoin = 10 BTC

So one bitcoin would actually be 0.1 gigacoin, or 100 megacoins

so in other words... you agree. ok.

[grondilu]

Please see https://en.bitcoin.it/wiki/Units

Oh this seems cool.   Sorry.

I should look at this wiki more often

[ribuck]

Please see https://en.bitcoin.it/wiki/Units

Oh this seems cool.   Sorry.

I should look at this wiki more often

Did you actually read the wiki page that you're describing as "cool"? This "Tonal Bitcoin" stuff is just stupid. "Bong-BitCoin" indeed!

[davout]

I'm not sure I get people's points right, my opinion, summed up is :
 - GUI and JSON should allow every operation with full precision,
 - It's the responsibility of the miners/clients to decide which transactions they want to include/relay
 - No transaction fee should be auto-set, but not relaying free subcent transactions seems like a reasonable default

[Pieter Wuille]

My original post - though split off from its original thread by gavin - was mainly about the internal representation used by JSON-RPC, and it seems that's also what most discussion here was about. This is a detail, and although my personal opinion is that integer units are preferable, it may or may not be worth sacrificing backward compatibility for.

Concerning sub-cent precision itself, i think gavin's suggestion is very good. The JSON-RPC interface should support all transactions and accounting at full precision, the client should actively avoid creating fee-requiring transactions, and creation of fee-requiring transactions shouldn't occur without the user's knowledge. I would suggest adding an optional maxtxfee argument (overriding the default) to the RPC calls which cause transactions to be sent though - i don't like a global setting shared by possibly more than one JSON-RPC client.

[davout]

Concerning sub-cent precision itself, i think gavin's suggestion is very good. The JSON-RPC interface should support all transactions and accounting at full precision, the client should actively avoid creating fee-requiring transactions, and creation of fee-requiring transactions shouldn't occur without the user's knowledge. I would suggest adding an optional maxtxfee argument (overriding the default) to the RPC calls which cause transactions to be sent though - i don't like a global setting shared by possibly more than one JSON-RPC client.

There is no such thing as a fee-requiring-tx, the default miner won't mine for some transactions, but the warning message should not imply that it is the protocol that prevents very small free transactions but merely the default implementation of the miner.

[grondilu]

Did you actually read the wiki page that you're describing as "cool"? This "Tonal Bitcoin" stuff is just stupid. "Bong-BitCoin" indeed!

Well, this is Nystrom hexadecimal representation (http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29), isn't it?

It doesn't seem stupid to me.  Anyway, it's just a complement to the standard 10^3-based prefix system.

However, it's a bit unfortunate that the smallest amount is not exactly a nanobitcoin, but rather 10 nanobitcoins.  It would have been simpler.

[ribuck]

Well, this is Nystrom hexadecimal representation (http://en.wikipedia.org/wiki/John_W._Nystrom#Tonal_System_.28Hexadecimal.29), isn't it?

It doesn't seem stupid to me.

The Nystrom representation itself isn't stupid, but using it for Bitcoin is. It brings absolutely nothing worthwhile to Bitcoin.

One bitcoin is 100000000 units of bitdust, and the maximum number of bitcoins is 21000000, both of which are convenient decimal numbers. What's the point of having one Bong-Bitcoin equal to 42.94967296 BTC?

If you do want to count bitcoins in hexadecimal, you should simply use the equivalent number in base 16. For example, 255 BTC = 0xFF BTC.

[grondilu]

The Nystrom representation itself isn't stupid, but using it for Bitcoin is. It brings absolutely nothing worthwhile to Bitcoin.

It brings more names to bitcoin subdivisions.

[Luke-Jr]

I'm splitting the Tonal talk to another thread. It doesn't belong here.

although my personal opinion is that integer units are preferable, it may or may not be worth sacrificing backward compatibility for.

Integer units don't break backward compatibility at all, if implemented using a RPC versioning mechanism (eg, bitcoin.<version>. prefix to methods, or--as MT suggested on IRC-- using a different URI path). This way, the old "RPC v0" can continue to function for as long as we care to maintain it, while new code can use RPC v1 with integer units. Given the fact that URIs are used, it might also be possible to simply use a query parameter (eg, "?precision=0", "?precision=1e8", "?precision=65536") to specify a division for all units explicitly (and default to "?precision=1e8" for backward compatibility for a while), while not forcing newer APIs to use base units.

[Pieter Wuille]

There is no such thing as a fee-requiring-tx, the default miner won't mine for some transactions, but the warning message should not imply that it is the protocol that prevents very small free transactions but merely the default implementation of the miner.

Ok, agree. I think conventions for what and where fees are expected are a separate issue. But as long as no different set of rules is designed, and the client enforces those rules in the transactions it creates, no transactions that include a fee should be created beyond the user's (or JSON-RPC client's) control. Gavin's proposal does that nicely.

although my personal opinion is that integer units are preferable, it may or may not be worth sacrificing backward compatibility for.

Integer units don't break backward compatibility at all, if implemented using a RPC versioning mechanism (eg, bitcoin.<version>. prefix to methods, or--as MT suggested on IRC-- using a different URI path). This way, the old "RPC v0" can continue to function for as long as we care to maintain it, while new code can use RPC v1 with integer units.

Ok, agree as well. But again, maybe introducing a new version of the protocol may or may not be worth the effort.

Given the fact that URIs are used, it might also be possible to simply use a query parameter (eg, "?precision=0", "?precision=1e8", "?precision=65536") to specify a division for all units explicitly (and default to "?precision=1e8" for backward compatibility for a while), while not forcing newer APIs to use base units.

That comes close to my "Idea 1", and brings us back to the issue of whether it is the responsibility of the JSON server to provide encoding/formatting of numeric amounts for human readability (and humans with varying tastes).

[Luke-Jr]

Solution to buggy JSON libraries (with base unit amounts): append a ".0" to all amounts, even though fractions are not possible. This should force all libraries with these bugs to treat it as a floating-point type, which is capable of representing the entire range. Embedded systems where floating-point is a problem can still validly ignore the ".0" and use int64.

[teknohog]

However, it's a bit unfortunate that the smallest amount is not exactly a nanobitcoin, but rather 10 nanobitcoins.  It would have been simpler.

Chinese numerals are grouped in terms of 10^4, and the same system is used in Japan. I am not sure if this is the reason behind 10^-8 bitcoins, but at least it would appear simpler in those countries. 10^3 and 10^6 are only simpler for Westerners.

Then again, SI prefixes are by definition the international standard. If only they were actually used, instead of the billions and trillions whose meanings change by the country/continent.