This will cost you 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 So when the decimal point moves this would then be rendered as Ⓑ15.00 automatically."}
Bitcoin Institute

Re: More divisibility required - move the decimal point

Figures: Mike Hearn
Mike Hearn February 10, 2011 16:09 UTC

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.