More divisibility required - move the decimal point

Hi,

With the latest price jumps, one bitcent is now worth more than the american currency’s lowest divisible unit - cent. It’s also been the case for other currencies for a while already.

I believe this is the correct time to increase bitcoin’s divisibility - i.e. move the decimal point right by one, or something similar.

The transaction fee could also be decreased in the process - e.g. to 0.001 bitcoin for oversized transactions, but that’s maybe not a very good idea due to possible spam. Perhaps charge 0.001 for transactions less than 0.001, and charge around 0.005 for oversized transactions?

That should allow more possibilities for representation of real-world currencies.

It’s easy to say “let’s just move the decimal point”. But this part of BitCoin is unusual in that it has not been well thought out by Satoshi in advance. Given he is absent, I guess it’s up to us to come up with a good plan.

What does this mean? Effectively, it means we need global consensus on where the decimal point should be. If some people move it and others don’t, it becomes difficult to trade because prices and payments become hopelessly confusing.

BitCoin is already very good at establishing global consensus on things. So how about this plan:

1. bitcoind gets a new RPC called “getNanosPerCoin” or something like that which returns the number of nanocoins that make up the arbitrary unit we call a “bitcoin”.

2. Everyone who mines can configure their copy of BitCoin to say where they think the decimal point should be. This data could be embedded into the coinbase transaction. I’d have to check the code carefully but I think it’s possible to stuff arbitrary extra data onto the end of the coinbase tx and not have the client complain or reject the block. Adding a regular new field means bumping the version number and I think that might be difficult, so what I’d suggest is if we do start appending stuff to the coinbase.in[0].scriptSig that it be a protocol buffer or some other binary data structure that supports versioning built in. Otherwise we might want to do it again later and find it hard.

3. At the end of each two week adjustment period, the client scans backwards to calculate the new nanosPerCoin based on the collective votes of the network. If >80% of the network agree on a new value for nanosPerCoin then the BitCoin client accepts this and begins reporting it in the RPC.

4. Existing software that renders “X.Y BTC” type strings would have to be changed to fetch the current nanosPerCoin value from a server somewhere. To make this simpler perhaps the JSON RPC port could accept an unauthenticated HTTP request like

http://server:1234/renderAmount?nanocoins=15000000,300000&style=unicode

and return a nicely formatted string like “Ⓑ15.00\nⒷ0.03” as a text/plain UTF-8 response. This HTTP call can just be wrapped into library functions in most languages so rendering BitCoin amounts wouldn’t be too difficult, and it could be exposed via bitcoin.org so websites could simply say

<script src="http://www.bitcoin.org/render-amounts.js"></script>

This will cost you <script>bitcoin.render(15000000)</script>

and it would print out the amount as agreed on by the consensus. If stating “true prices” in terms of nanocoins is too inconvenient, prices could be specified as a natural amount and a date:

This will cost you <script>bitcoin.render(1.50, "2011-02-10 17:00:00 UTC")</script>

So when the decimal point moves this would then be rendered as Ⓑ15.00 automatically.

It’s out of the question to literally move the decimal point, and goblin didn’t mean it literally.

Two things we can do are to (a) expose more of the existing precision in the user interface, and (b) see if we can agree on terminology and notation.

We have previously discussed notation without an apparent conclusion. I would like to suggest an alternative notation that has not yet been proposed.

I suggest the following:

One bitcoin equals 100 bitcents
One bitcent equals one thousand millicents
One bitcent equals one million microcents

By subdividing the bitcent rather than the bitcoin, we neatly end up with a name for the tiniest piece of bitdust, i.e. 1/100000000 of a bitcoin.

No doubt in time nicknames would arise for these small units. I like “austrian” and “satoshi” as possible nicknames

WAY too many issues being mixed up here… I’m sorry I ever framed this as “moving the decimal point”

I think the next release of Bitcoin should:

• Show full-precision bitcoins in the GUI. If you have 1.5 BTC, it will display as it does now (“1.50”).
  If you have 1.50001 BTC, it will display the extra precision.

• Allow you to send full-precision from the GUI and from JSON. If you have 1.500001 BTC, you will see
  you have that many and can send that many.

• Incorporate luke-jr’s patch to avoid losing “dust change”, when possible. (e.g. if you have received transactions of 1.5000001 and 20 BTC, and then send 1.5, Bitcoin shouldn’t choose just the 1.5000001 input transaction).

Those issues are being driven by pooled mining— a lot of people are getting sub-cent bitcoins from their pooled mining shares.

Then there’s the issue of “what is a micro-transaction for which you should be forced to pay a fee.” Currently, it is any transaction with an output less than 0.01 BTC.

And the issue of “what is the minimum fee” (also currently 0.01 BTC).

Ideally, transaction fees should reflect real-world costs… although just making them hidden costs that are spread between everybody running bitcoin might work perfectly well. Still, I’d like to get a rough idea of the real-world cost of a transaction.

It is too early to be worried about “paying 0.001 bitcoins for a pair of socks”.

Lots of good ideas here!

I like Gavin’s idea to display full precision in the UI and allow it on payments.

I like ribuck’s terminology: 100 bitcents in a bitcoin, 1000 millicents in a bitcent, 1000 microcents in a Millicent.

I like [mike]‘s suggestion to allow miners to store information relating to costs and policies, and to adapt network behavior from that information. I’d suggest using it specifically to normalize the “anti-spam” limits: the 0.01 minimums for large-transaction fees and for free transactions. Clearly Bitcoin needs a way to adjust these values, and Mike’s proposal seems like a good candidate.

I also wonder if the anti-spam rule shouldn’t be changed, to trigger if the largest output is tiny, rather than for any output. In Gavin’s example, outputs of 1.5 and 0.000001 change seem ok to me.

RQuote from: ribuck on February 10, 2011, 4:53:35 PM UTC

I suggest the following:

One bitcoin equals 100 bitcents
One bitcent equals one thousand millicents
One bitcent equals one million microcents

By subdividing the bitcent rather than the bitcoin, we neatly end up with a name for the tiniest piece of bitdust, i.e. 1/100000000 of a bitcoin.

No doubt in time nicknames would arise for these small units. I like “austrian” and “satoshi” as possible nicknames

That’s an interesting proposal, but I have one strong argument against it: the mixing of a three-order of magnitude scale (1 bitcent = 10^3 millicents = 10^6 microcents) with a two-order scale (1 bitcoin = 100 bitcent) is almost guaranteed to lead to confusion down the road. Moreover, the fixation on cents is largely an artifact derived from the current versions of the Bitcoin GUI using by default two decimal places. Should a future version switch to a three decimal default (a move I think is wise) then this anchoring on cents will go away.

We should pick a scale that uses a uniform jump in orders of magnitude all the way from the tiniest amount to the largest. And the number of orders of magnitude should be three, since it’s the one most familiar to people. Granted, speaking of millicoins and microcoins could get tiresome, so choosing nicknames for the multiples and submultiples is a good idea. I agree that “Satoshi” is a good candidate, but I’ll have to disagree with you on the “Austrian”… :-)

My suggestions:

1 satoshi = 1000 BTC
1 BTC = 1000 koishi (‘koishi’ being Japanese for ‘pebble’)
1 koishi = 1000 suna (‘suna’ being japanese for ‘sand’)