Bitcoin Forum

It was wise when creating the BTC specification to allow up to 8 (I think its 8 ) decimal places of divisibility.  Given the natural deflation that will occur barring government intervention, its certainly better than two places of divisibility.  However, a number of theoretical posts on the forums have raised the question of what would happen if that ever was not enough.  

I am amazed at the two categories of answers that I see - A)"That'll never happen," and B)"Well we're screwed then."  How difficult would it be in the future to modify the bitcoin specification to allow for nine, ten, or even an arbitrary number of, points precision?  My guess is that it would be pretty daunting, given that the entire chain would have to change (I think?).

The second option that I can see would be a voluntary currency revaluation.  In essence, we'd release a new chain and a new client.  This new chain wouldn't generate *any* coins.  However, it would be denominated in "BitCoinMillionths" or whatever, and when you imported your old BitCoin wallet, it would apply the exchange rate of 1BTC=1,000,000BTCm, and continue from there.  The BTCm would be divisible to eight or ten or however many decimal places as well.  Thus, people could still generate BTC with the BTC client (assuming we hadn't hit the 21,000,000 mark), but the new client would allow for greater divisibility while not modifying the underlying system.  In fact, the BTCm client could generate bitcoins on the old chain according to the same rules that govern generation today, letting one program handle both issues.

What do you guys think of this idea?

Cross-posted to Tech and Dev to get a response about actually modifying the bitcoin's divisibility.

Even if BitCoin is the hugest smashing success ever and one hundred millionth of a BTC buys you a 10oz gold bar someone can easily invent a payment system for smaller amounts. It can be based on the same sort of cryptography, or better cryptography, or something totally different. And if you like it you can buy some of it with your super valueable hundred millionths.

I agree that reactions to this 'problem' that I've seen are bizarre. It's the farthest possible thing from a problem.

"Nooooo.... what if tomorrow morning all my pennies can buy me mansions and sports cars and I can't find a saw so I can't buy any bread. Noooo..."

Something to consider is that the peer-to-peer network load may end up bogging down well before this becomes a problem or that some other technical flaw may come up that will have to be fixed and may even require restarting the whole network.  This also is an issue where unfortunately most computer data has to be stored in fixed dimension for bit length, which is also a part of the problem.  It doesn't have to be that way, however.

I'd have to look at the overall data packet design, but I do believe there ought to be a technical solution to this issue where some sort of "flag" bit could be applied to indicate that more bits of data storage are required for a coin transfer (hence counting more decimal places to the currency).  In theory, this could end up with genuine infinitely small units to be transferred.  I'm not using the term infinity lightly here either but in a mathematical sense noting that would also require an infinitely large datablock to transmit that sort of data.  There could also be some safety protocols in the network to keep that from getting out of hand too.

In short, I do think that it is something that ought to be of concern, but that there are solutions to the problem.  It is a serious concern and something that should be discussed.  I also strongly disagree with those who think that the potentially 2 quadrillion bitcoin units of the current bitcoin model is sufficient for any possible future of the system, even if it isn't a problem at the moment nor in the foreseeable future.

One easy fix.  If itty bits become overly valuable start a new program.  Works the exact same way, but it's new so it's worth much less.

This ^

There's no need for a new chain. Simply change the default unit to be millibits, nanobits, etc... (as I saw suggested elsewhere).

Increase the precision in the specifications so that the network can support increased precision.

Harder than you think.

Please explain.

Currently the values are stored in the software in a certain way.  In order to store them in a different way you have to get into the software in a way that is not reverse compatible.  For instance, if someone sends a transaction and is charged a tenth of an itty bit as a transaction fee that is a value that his software cannot handle, this could cause all sorts of problems.

Babylon: Not true.  The software stores them in the base bitcoin value.  All transactions are done with this value stored on disk.  However, the client could display "10 nanocoins" when really it means ".00000001 bitcoins".  It's up to the client to do the conversion behind that.

However, to provide additional levels of divisibility, you'd need a structure for arbitrary position.  This would most likely be a breaking change, but it would just mean that everyone needs to update the client.  The old bitcoins could still be converted to the new value system, as long as the new clients still "understood" how the old clients dealt with things.

I don't think it would or would have to be a breaking change either.  It could be implemented right now without having to decide the exact scheme for arbitrary precision and already be in the network so when such precision is needed (if it ever is needed) that nodes would pass on the information in the blocks being agnostic toward whatever system is being used. 

The issue would come if a client would want to transmit bitcoins in even smaller denominations that can be done currently, or to acknowledge receipt of those transfers.... which would encourage an upgrade in the client if that happened.  The current data structure for coin transfers should be able to accommodate a variable length data block for the bitcoins, even if that may not be the case at the moment.  It also shouldn't break existing clients if that change were implemented now.

Of course it should be acknowledged that right now Bitcoins are still experimental and nobody should be putting too much value into them on the off chance that a major flaw in the architecture is found that would require restarting the network.  That, however, is a topic for another thread.

Right, but changing it NOW, regardless of if we use it would still require the users to upgrade ("breaking" change, as it's called), because now the numbers would be stored with arbitrary-precision data format, instead of "regular long" format.  Granted, now's the time to do it if we are, while the community is relatively small, but it'd still be considered breaking.

The total money supply of USD, for instance, is somewhere between  $1 Trillion and $10 Trillion:
http://en.wikipedia.org/wiki/Money_supply

Now imagine the extreme scenario where Bitcoin replaces all USD transactions in the world:

That would mean that each Bitcoin would be worth approx. 1e13/2.1e7 = 480,000 USD.

The smallest possible unit would be worth 480,000/1e8 =  0.48 cents

In other words, even in most wildly optimistic future scenario, a divisibility of 8 figures would more than suffice.

USA isn't the world, now isn't 5 years from now.

I think you made a pessimistic mistake in the calculations.

I get 10 trillion / 21 million BCs = $476/BC. The smallest possible unit would be worth 0.000476 of a cent.

Just buy 100 BTC as insurance against this happening. If the terrible deflationary spiral does happen you will be crazy rich and not particularly care about overpaying because you just can't break that 100millionth down into 10 billionths to buy a sandwhich. just tip 9billionths, be a baller. You can afford it, after all you socked away 100 billion billionths.

Actually, you were right and I was the one that screwed up, by missing 3 zeroes. My bad.

A trillion dollars is truly a huge sum..