📅 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.
>
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 15:15:36
in reply to nevent1q…rp3t
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 15:15:36Event JSON
{
"id": "af8dbd2beeac2640eeded348e4b727d95f96a049af250fd13bc478cad2c6df12",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686150936,
"kind": 1,
"tags": [
[
"e",
"a5889b6003c7241c893062a271bfd01eb179b582d390c0baf2198e69cbfe2d2d",
"",
"root"
],
[
"e",
"37b33930fcf51959a36fa00375df3224e6213a89730da1232b259535984a5e26",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2014-03-13\n📝 Original message:This ship may have already sailed, but...\n\nUsing milli- and micro- notation for currency units is also not very\nwell supported. Last time this thread was active, I believe there was a\nsuggestion to use 1 XBT == 1 uBTC. This would bring us completely within\nthe realm of supported behavior in accounting applications.\n\nOn 03/13/2014 09:29 AM, Jeff Garzik wrote:\n\u003e On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner \u003cetotheipi at gmail.com\u003e wrote:\n\u003e\u003e Of course, as Mike said, this ship may have already sailed, but if\n\u003e\u003e there's any way to revisit this, I'm there. We're just about to do\n\u003e\u003e another Armory release and could support this very easily.\n\u003e \n\u003e mBTC now just means the issue -will- be revisited in the future. Just\n\u003e a question of when, not if.\n\u003e \n\u003e People and software in various nations handle big numbers for small\n\u003e values (e.g. Yen) just fine.\n\u003e People and software do -not- handle extra decimal places well, field\n\u003e experience shows.\n\u003e \n\u003e \u003cvendor hat: on\u003e To roll out QuickBooks support --without converting\n\u003e any numbers, a key financial attribute-- mBTC is simply insufficient\n\u003e today, not in the future.\n\u003e \n\u003e I also argue that it is a security risk, as follows: To support\n\u003e accounting packages limited to 2 decimal places, decimal point\n\u003e conversion must be performed. This produces a situation where your\n\u003e accounting system shows numbers that do not visually match the numbers\n\u003e in the bitcoin software. That, in turn, making auditing more\n\u003e difficult, particularly for outsiders.\n\u003e \n\u003e Shipping with mBTC defaults was decidedly unwise, considering that --\n\u003e like BTC -- it fails to solve existing, known problems that uBTC can\n\u003e solve, and considering the inevitable mBTC-\u003euBTC switch.\n\u003e",
"sig": "125417ff2dd03ee8cbd0ab948dfc5ec024e191594c1c78167c7124cacfbd8d5765012cbb2637a5c4220c1ad3b027ff2eda6dc9b6a8502a0e35d72dd3bece3b85"
}