{"type":"rich","version":"1.0","author_name":"npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","author_url":"https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-13\n📝 Original message:On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e Of course, as Mike said, this ship may have already sailed, but if\n\u003e there's any way to revisit this, I'm there.  We're just about to do\n\u003e another Armory release and could support this very easily.\n\nmBTC now just means the issue -will- be revisited in the future.  Just\na question of when, not if.\n\nPeople and software in various nations handle big numbers for small\nvalues (e.g. Yen) just fine.\nPeople and software do -not- handle extra decimal places well, field\nexperience shows.\n\n\u003cvendor hat: on\u003e  To roll out QuickBooks support --without converting\nany numbers, a key financial attribute-- mBTC is simply insufficient\ntoday, not in the future.\n\nI also argue that it is a security risk, as follows:  To support\naccounting packages limited to 2 decimal places, decimal point\nconversion must be performed.  This produces a situation where your\naccounting system shows numbers that do not visually match the numbers\nin the bitcoin software.  That, in turn, making auditing more\ndifficult, particularly for outsiders.\n\nShipping with mBTC defaults was decidedly unwise, considering that --\nlike BTC -- it fails to solve existing, known problems that uBTC can\nsolve, and considering the inevitable mBTC-\u003euBTC switch.\n\n-- \nJeff Garzik\nBitcoin core developer and open source evangelist\nBitPay, Inc.      https://bitpay.com/"}