Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-13 📝 Original message:This ship may have already ...
📅 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.
>
📝 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.
>