| ○ | uBTC | Microbitcoin | 0.00000100 BTC |
I think you mean
| ○ | µBTC | Microbitcoin | 0.00000100 BTC |
(It's a greek mu, not a letter u)
Topic: Add option to display mBTC instead of BTC (Read 1966 times)
I think you mean
(It's a greek mu, not a letter u)
(1) Yes, it's all UI. But we risk alienating users by making Bitcoin even more complicated and confusing than it already is. If everyone (and every wallet app) uses different units, and they can't convert in their head easily, and it's even the slightest bit feasible to enter incorrect values... it's becomes a serious usability problem.
You are right, yet this problem too can be taken care of if done in the right way.
I suggest it defaults to BTC on first startup of Armory. Then, on the Settings menu (which should ideally be separated into tabs), there is a "Display" tab with a section for Display Scale and a small table with radio buttons for each row similar to:
| Abbreviation | Name | Scale | |
| • | BTC | Bitcoin | 1.00000000 BTC |
| ○ | mBTC | Millibitcoin | 0.00100000 BTC |
| ○ | uBTC | Microbitcoin | 0.00000100 BTC |
Why should it be done like that? Because it explains to a new user what the different scales are in enough detail to fully understand the display abbreviation (BTC / mBTC / uBTC), pronunciation of the unit, and the relation to the 1.0 BTC scale and yet also concise enough not to take up a ton of space in the Settings window.
Perhaps there are better ideas? Maybe it could even ask you to choose a display scale with the same table + radio buttons setup when you start up Armory for the first time?
Also, this might be something to consider:
http://www.reddit.com/r/Bitcoin/comments/1rmto3/its_bits/
But I assume that people using Armory will be somewhat accustomed to using SI-units.
http://www.reddit.com/r/Bitcoin/comments/1rmto3/its_bits/
But I assume that people using Armory will be somewhat accustomed to using SI-units.
(1) Yes, it's all UI. But we risk alienating users by making Bitcoin even more complicated and confusing than it already is. If everyone (and every wallet app) uses different units, and they can't convert in their head easily, and it's even the slightest bit feasible to enter incorrect values... it's becomes a serious usability problem.
(2) Making a concerted effort to have everyone changing units will cause confusion even if we "do it right". And there will be resistence. And disagreement. Let's decide it's a good idea, then do it once and push it hard.
(3) Now that I'm a business owner, I can tell you that there are a plethora of tools out there for helping manage and track financials. And there's no guarantee they handle anything more than 2 decimal places, because they don't need to. I don't know if there's any currencies that use more than two.
And I recently talked to a guy about using NetSuite for our company which is used by multi-billion dollar companies, and it doesn't handle more than two decimal places. He had to implement everything he did in microbitcoins because of that.
(2) Making a concerted effort to have everyone changing units will cause confusion even if we "do it right". And there will be resistence. And disagreement. Let's decide it's a good idea, then do it once and push it hard.
(3) Now that I'm a business owner, I can tell you that there are a plethora of tools out there for helping manage and track financials. And there's no guarantee they handle anything more than 2 decimal places, because they don't need to. I don't know if there's any currencies that use more than two.
And I recently talked to a guy about using NetSuite for our company which is used by multi-billion dollar companies, and it doesn't handle more than two decimal places. He had to implement everything he did in microbitcoins because of that.
There was some discussion recently on the mailing list about this. The general consensus was that:
(1) This needs to be done carefully to avoid people sending 1000x what they intended
(2) It is difficult to change an established system. So we want to do it once.
(3) It'd be nice to only have two digits after the decimal since most accounting software can't handle more
Therefore, we go straight to micro-BTC. It solves all of this in one fell swoop. At the current Bitcoin price (~$1,000) that would be 1,000 uBTC per $1 USD. That's a totally reasonable, human-usable system. And accommodates all future non-hardforking growth (i.e. if we never need more than 8 decimal places, this will be last forever).
(1) This needs to be done carefully to avoid people sending 1000x what they intended
(2) It is difficult to change an established system. So we want to do it once.
(3) It'd be nice to only have two digits after the decimal since most accounting software can't handle more
Therefore, we go straight to micro-BTC. It solves all of this in one fell swoop. At the current Bitcoin price (~$1,000) that would be 1,000 uBTC per $1 USD. That's a totally reasonable, human-usable system. And accommodates all future non-hardforking growth (i.e. if we never need more than 8 decimal places, this will be last forever).
I admit, I've yet to read through the source code of Armory (Sorry...), but:-
(1) Wouldn't it all just be in the UI? The backend would still be the exact same, dealing with BTC. You wouldn't magically have to start processing mBTC.
(2) Nothing really to say, I agree.
(3) Unfortunately, I don't see the relevance here, I assume you're talking about one of the exporting options I don't use.
It strikes me that whatever units we use, the only way to avoid errors of sending orders of magnitude too many coins is to confirm the value in (approximate) fiat. We're a long way from a situation where most Bitcoin users have an inuitive feel for sums of Bitcoin - and this is only in part due to the rapid price moves. This is true even without a unit change - the latter will just add confusion.
Assuming we're agreed that fiat confirmations are useful as a sanity check (Bitcoin Wallet for Android has them and tbh I think all online clients should) - it does raise the question as to what rates to use, but moreover how to obtain trusted exchange rates.
Although, with offline wallets ideally you'd want trusted sources of signed exchange rate data. If the offline computer could verify the signature and timeliness of exchange rate date saved along side the unsigned transaction, then you could guarantee that the user would be presented with accurate information when verifying the transaction.
roy
Assuming we're agreed that fiat confirmations are useful as a sanity check (Bitcoin Wallet for Android has them and tbh I think all online clients should) - it does raise the question as to what rates to use, but moreover how to obtain trusted exchange rates.
Although, with offline wallets ideally you'd want trusted sources of signed exchange rate data. If the offline computer could verify the signature and timeliness of exchange rate date saved along side the unsigned transaction, then you could guarantee that the user would be presented with accurate information when verifying the transaction.
roy
There was some discussion recently on the mailing list about this. The general consensus was that:
(1) This needs to be done carefully to avoid people sending 1000x what they intended
(2) It is difficult to change an established system. So we want to do it once.
(3) It'd be nice to only have two digits after the decimal since most accounting software can't handle more
Therefore, we go straight to micro-BTC. It solves all of this in one fell swoop. At the current Bitcoin price (~$1,000) that would be 1,000 uBTC per $1 USD. That's a totally reasonable, human-usable system. And accommodates all future non-hardforking growth (i.e. if we never need more than 8 decimal places, this will be last forever).
(1) This needs to be done carefully to avoid people sending 1000x what they intended
(2) It is difficult to change an established system. So we want to do it once.
(3) It'd be nice to only have two digits after the decimal since most accounting software can't handle more
Therefore, we go straight to micro-BTC. It solves all of this in one fell swoop. At the current Bitcoin price (~$1,000) that would be 1,000 uBTC per $1 USD. That's a totally reasonable, human-usable system. And accommodates all future non-hardforking growth (i.e. if we never need more than 8 decimal places, this will be last forever).
Sounds awesome!
There was some discussion recently on the mailing list about this. The general consensus was that:
(1) This needs to be done carefully to avoid people sending 1000x what they intended
(2) It is difficult to change an established system. So we want to do it once.
(3) It'd be nice to only have two digits after the decimal since most accounting software can't handle more
Therefore, we go straight to micro-BTC. It solves all of this in one fell swoop. At the current Bitcoin price (~$1,000) that would be 1,000 uBTC per $1 USD. That's a totally reasonable, human-usable system. And accommodates all future non-hardforking growth (i.e. if we never need more than 8 decimal places, this will be last forever).
(1) This needs to be done carefully to avoid people sending 1000x what they intended
(2) It is difficult to change an established system. So we want to do it once.
(3) It'd be nice to only have two digits after the decimal since most accounting software can't handle more
Therefore, we go straight to micro-BTC. It solves all of this in one fell swoop. At the current Bitcoin price (~$1,000) that would be 1,000 uBTC per $1 USD. That's a totally reasonable, human-usable system. And accommodates all future non-hardforking growth (i.e. if we never need more than 8 decimal places, this will be last forever).
Hi.
Could it be time to switch to mBTC as default in the client, or at least to add a switch allowing the user to choose what to display?
Thanks for your awesome work. Best there is.
Could it be time to switch to mBTC as default in the client, or at least to add a switch allowing the user to choose what to display?
Thanks for your awesome work. Best there is.
Jump to: