Quote from: austonst on May 31, 2013, 06:31:51 PM

We already have multiple threads discussing this exact same topic. I guess the poll is new, but let's all keep in mind that there's a lot of other threads to read through for finding thorough discussion. I guess I'll reiterate what I said earlier (more complete post at https://bitcointalk.org/index.php?topic=220322.msg2330960#msg2330960 )

I voted for none of the above. Using BTC for everything is crazy, and while metric is nice, BTC should probably get phased out in favor of something more ISO compliant. Though, to defend alternative 2 and metric in general, is it really all that complex for newcomers and non-engineers? Are we not already comfortable referring to weights in kilograms and distances in kilometers and millimeters? We still should solve ISO compliance and database storage, though. Bitcoin should try to conform to published standards, so I support a change to XBT, but I do not agree with XBT's re-denomination to µBTC. I do not believe it is the burden of Bitcoin to work with current financial software. There are two ways databases can support current BTC usage.

1) Databases themselves can be changed. Their precision can be increased and 3-character boxes can be changed to have 4 (I wouldn't be surprised if many systems already have support for more characters), or to ease transition, a new table could be added to store a metric prefix for each listed currency. With existing currencies, not much would have to change. Let's keep in mind that Bitcoin is not the only new currency to be growing. What if Litecoin, along with many of the others, all began being listed in databases? Financial systems would have to adapt to support the variety of names, abbreviations, and denominations. Even the ISO standards should probably be adjusted in the future to accommodate the now common idea of non-national currencies.

2) In case for some reason the databases cannot be modified, we can use an abstraction layer between the database and the presentation. Already, very few end users are going to be typing in straight-up SQL to pull from a database; there's always some sort of software that performs the query, parses it, and displays it in a nice way to the user. Why not have the database store an entry labeled BTC, but storing an amount of µBTC? Whatever software parses the information can present it to the user in any way they want: BTC, mBTC, µBTC, etc. This would really only be a temporary solution until the software itself changes to support the wide variety of currencies that are emerging.

So the way I see it, grau's XBT causes a good thing (ISO compliance) and a not-so-good thing (unnecessary re-denomination). What benefits would we get from denominating XBT as µBTC, aside from compatability with outdated databases (which I don't see as an issue)? With the current exchange rate, we'd probably want to use kXBT anyway so that 1 USD = 7.7 kXBT. Why not go for the ISO compliance without the unnecessary re-denomination? Let's have XBT = BTC, use the metric system which we all are comfortable with, and be done with it. We can still use mBTC (mXBT) and µBTC (µXBT) for the handy comma separators.

I agree with most of what you are saying, but I definetly think mBTC at least (or mXBT) should be the PRIMARY denomination. The thing I like about re-denomination though is not having to use those unwieldy prefixes. What naturally follows then, is that IF XBT was to be anything but full BTCs, it should be uBTC so that we never have to move again. mBTC may be enough, but I'm not sure. Also, it should not be lower than uBTC so we can still have to two-place precision divisibility.