Topic: Divisibility Adjustment - Technical Feasibility (Read 10084 times)

This is a UI problem, and it can be solved form the UI - if transactions start getting small the UI can simply have fields for sending Bitcoins, millicoins, nanocoins etc.

Why not use the already existing metric system,

1 = bitcoin
10 = decabits

or

0.1 = decibits
0.01 = centibits
0.001 = millibits

or

Spell bitcoin with some strange/different spelling that people can visually know means the bitcoin currency so they don't confuse it with computer bits

bitsc (decibitsc, kilobitsc, etc.)

or

bitc (decibitc or kilobitc, etc.)

BitDollar, perhaps, when "contracting" the monetary unit (1000 -> 1)?  BitCent or BitPenny if expanding it (1 -> 1000)?

As far as arbitrary precision goes, I just see an inherent unattractiveness in having to type .0000000000237 and the like for everyday transaction values.  From an HCI standpoint, not only is this clunky, but it is well known that the probability of data entry errors increases as the square of the length of the string being entered.  Thus, a conversion to a new unit would be more favorable.  As for "change the name or leave it," I think one previous poster made that point perfectly.  The new name would just be the same thing - a bitcoin - with values multiplied or divided.  However, the name change is necessary so as to avoid confusion in the using public.  It could be as simple as "Bitcoin" and "New Bitcoin," etc, but calling both by an identical name is inherently confusing.

Arbitrary precision mathematics seems like the perfect solution to me, since we are in fact after arbitrary precsion! I guess you could say the clue is in the name

Well, no, it's not changing the backing value of the bitcoin.  If 1000 bitcoins is worth 1000 dollars at said point, and there's a public announcement that now, every 1000 bitcoins is equivalent to 1 bitcoin, then each bitcoin would be worth 1000 dollars.  The only issue is making sure the message/notification is high-profile enough so that all the major exchanges re-price themselves accordingly.  Making a new unit solve the same problem with less confusion, but they're essentially the same thing.  As for distinguishing between "old" and "new" bitcoins, the coins are timestamped, so that wouldn't be too difficult.  The advantage of the "new unit" system, I guess, is that it eliminates confusion among the users.

As for the arbitrary precision data structure:  Having thought about it some more, I guess it wouldn't be too difficult, too inefficient, etc.  However, to me it seems like an ugly/hacky solution, and just gripes my "sense of the world" a bit.

This is precisely what I was saying could be a solution.  In fact, I was taking Brazil and several other nations as template.  What I was saying was that you couldn't chop off the leading zeros and still call it the "Bitcoin," which seemed to be what another poster was advocating.  If you did this, you'd have no way to distinguish between pre-conversion and post-conversion Bitcoins.  I suggested a revaluation with a name change - The basic unit would go from one Bitcoin to one BitcoinMillionth, where 1BTCm = .000001BTC.  The client, whenever faced with an old Bitcoin wallet, would convert it to a BitcoinMillionth wallet.  Since this (in reverse, for inflation rather than deflation) has been done successfully numerous times with various currencies, I figured it would be a decent solution to having .0000001BTC=100USD exchange rates and the requisite need for more precision and less leading zeros from a human error standpoint.

The issue is with a huge mantissa where 1000 bitcoins are mixed with 0.00000000000000000001 bitcoins in the same block, or at least with the same fiscal transfer.  Why that would be done is another matter, and is part of what I'm arguing about would generally not happen except for somebody gaming/attacking the network or for exceptional kinds of transfers.

If 0.001 bitcoins ever became as valuable as a dollar, there would be in theory several million dollars worth of bitcoins in the network and some serious attention to this issue anyway.  That is sort of the argument about this being a non-issue so far as when it becomes important to have beyond the current subdivision of bitcoins, that the quantities of value in comparison to a loaf of bread or an hour's worth of work would also be huge for the number of coins being transferred with a huge mantissa.


I've lived in a country (Brazil) where due to massive inflation the basic monetary unit was reset with zeros chopped off and the monetary unit renamed.  It actually happened a couple of times, although I was there for only one of those conversions.  The ordinary people using the currency were able to adapt to the change, as were most of the markets.

If such a change did happen it should be a new monetary unit like a "Network Mark" or some other name to make it very clear that a change has happened.

We wouldn't want to say "1000BTC is now 1 BTC."  This would create all sorts of issues.  For one, imagine the dismay of those individuals who had not yet converted when they called up their "suddenly wealthy" friends.  Rather, we would create a new unit, and convert bitcoins into that unit at some fixed exchange rate.  The change I was talking about would be the equivalent of taking everyone's dollars and giving them back cents - an equal number value-wise, just easier to deal with because of eliminating leading 0s

Arbitrary precision arithmetic isn't particularly difficult, using a system like that with variable length integer encoding could result in a fairly efficient packet layout.

I am not suggesting that we use IEEE floating point here, but something that could be put together to ensure the accuracy required for making this work.  Yes, I'm aware of the limitation of the standard binary floating point and how it can impact precision.  It would have to be something very, very different.

BTW, I don't think that building a data structure to hold this kind of data would be all that inefficient, as for most "normal" transactions there wouldn't be more than a few digits of accuracy needed in the "mantissa".  There could be some problems if those involved in trades insist upon 20-30 digits in the mantissa.... at which time that is all information which needs to be stored and would still be a problem if we needed more digits of accuracy.

Variable sized data structures exist for things like UTF-8, that in theory holds potential values for a unicode character with a number in the trillions, but only occupies a single 8-bit byte for each ordinary Latin-1 characters.  It is something like this that I'm talking about for storing this information, that would only require a single bit in the current implementation that could flag between an "extended" data structure and more ordinary transactions that are currently happening.  I am quite certain that there is a bit that until now has not been used and would not have broken nor will break any current clients.  All I'm proposing is that this bit be officially marked as "reserved" at the moment for future expansion so it doesn't break the network if that day ever comes where we may have to come up with some kind of alternative data storing procedure.

And yes, UTF-8 is inefficient for seldom used Chinese characters such as family names and ancient words not commonly used even within Chinese culture (i.e. Unicode points well above 65k).  That should be an exception rather than the rule, and if the pressing need is in place for very high precision data.

The need for growing this will come when the value of the minimum currency unit starts to become valuable enough that a desire to have a fractional unit will come up to deal with micro transactions.... where that would also have the value of what is roughly about a cent on a U.S. Dollar currently.  We've already seen massive deflation relative to the U.S. Dollar and Euros already, and the question is if 0.00000001 bitcoins would ever be worth a dollar on the standard bitcoin exchanges?  Of course I don't know what would be more shocking if that happens.... the value of a dollar or a bitcoin?

Currently, Bitcoins are stored as a 64-bit integer. The number of Bitcoins is multiplied by 100000000 to give eight decimals of precision. Exactly where the decimal point is placed in this large number is completely up the UI, so this can be easily changed. Extending this precision (by turning it into a 128-bit integer or whatever) is possible, but all clients that did this would be incompatible with old clients. It could be changed gradually in the same way SHA-256 could be:

https://bitcointalksearch.org/topic/m.1585

Actually implementing an arbitrary size decimal number class isn't that difficult, I wouldn't be surprised if there already is one for C++ which could just be picked up and used.

As for increasing packet size, that's not a problem either, if you use a single variable length encoded integer to indicate how many bytes the number consists of, and then that many bytes, you're not going to increase packet sizes much - in fact for small transactions (ones transferring < 255 butcoins), only 2 bytes will be used, which makes some packets smaller I imagine!

The main concern, I suspect, is that such a change will be difficult to implement without breaking the network into 2 - the old fixed precision part and the new arbitrary precision part. This may or may not be a problem (I imagine all the new style transactions would be rejected, until a majority of the network ran the new version, at which point all old style transactions would be rejected).

Floating point and double precision have precision issues.  Which is something that you do NOT want to deal with in money.  If you were, for example, to have 1.0000000000000000000000000000000000000000000000000000001 bitcoins in a floating point, the actual stored value would be either 1, or 0.00000000000000000000001 (can't remember which off the top of my head).

Building a data-structure to hold arbitrary precision would be cumbersome and space inefficient. (There'd be a lot of overhead to talk about how big the number is, as well as the data about the number.  Similar to how strings/vectors work).

It could be done, and isn't very difficult, but it'd be a breaking change to the protocol, and increase the packet size for ALL transactions, not just very small/very large. (Because you'd still have that overhead for "regular sized" numbers).

Also, I realize my original post didn't address the technical feasibility, but was tangentially related.  It wasn't so much a "here's an answer to your question", more so a "Oh, hey, that reminds me..."

While I think that resetting the unit value may have merit in itself, that doesn't address the technical issue of the data storage issues related the number of decimal places needed for keeping track of this currency.  In theory, you need to have a large number of bits to keep track of the largest transactions.

There is no reason, however, for the number of bits used for storing this number to be fixed in length and in theory could be extended to any arbitrary length.  If the time came for routine transactions to be one billionth or even one trillionth of a bitcoin, such data structures to hold that information could be developed as either a floating point number (decimalized floating point or more) or an extended number that would combine the very large with the very small.

In short, I don't believe this to be a really huge technical hurdle other than there is no practical reason to be worrying about this issue at the moment.  The only thing that should be done is to put in some reserved bits in the data structure that shouldn't be used right now but could be used in the future to define these more exotic data structures if/when such a need arises.

I was thinking about this the other day.  IMO, if we ever get to such low levels of transactions for a long period of time, a "split" could occur, whereby we say "Alright, everyone who was operating with .0001 bitcoins, that now acts as 1 bitcoin, and you have another 8 decimal places after that to divide up".  It wouldn't change the value of the bitcoin, it's simply a "relabeling" for sanity's sake.  Likewise, if the economy improved after that, a relabeling the other way could occur, saying "Alright, 1000 bitcoins is now 1 bitcoin".

Not sure how this would be implemented in a decentralized fashion (some globally agreed upon threshold, I would assume).  I haven't put too much thought into it, just an idea I had while walking to work the other day.

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 the generation follows at present, letting one program handle both issues.

Cross-posted to Economics for the obvious non-technical portion of this.