rich1.0npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uhttps://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0unjumphttps://nostr.ae📅 Original date posted:2014-03-13 📝 Original message:This ship may have already sailed, but... Using milli- and micro- notation for currency units is also not very well supported. Last time this thread was active, I believe there was a suggestion to use 1 XBT == 1 uBTC. This would bring us completely within the realm of supported behavior in accounting applications. On 03/13/2014 09:29 AM, Jeff Garzik wrote: > On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner <etotheipi at gmail.com> wrote: >> Of course, as Mike said, this ship may have already sailed, but if >> there's any way to revisit this, I'm there. We're just about to do >> another Armory release and could support this very easily. > > mBTC now just means the issue -will- be revisited in the future. Just > a question of when, not if. > > People and software in various nations handle big numbers for small > values (e.g. Yen) just fine. > People and software do -not- handle extra decimal places well, field > experience shows. > > <vendor hat: on> To roll out QuickBooks support --without converting > any numbers, a key financial attribute-- mBTC is simply insufficient > today, not in the future. > > I also argue that it is a security risk, as follows: To support > accounting packages limited to 2 decimal places, decimal point > conversion must be performed. This produces a situation where your > accounting system shows numbers that do not visually match the numbers > in the bitcoin software. That, in turn, making auditing more > difficult, particularly for outsiders. > > Shipping with mBTC defaults was decidedly unwise, considering that -- > like BTC -- it fails to solve existing, known problems that uBTC can > solve, and considering the inevitable mBTC->uBTC switch. >