📅 Original date posted:2014-03-13
📝 Original message: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.
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 17:15:36
in reply to nevent1q…lfp8
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Seen on
wss://relay.noswhere.comPublished at
2023-06-07 17:15:36Event JSON
{
"id": "37b33930fcf51959a36fa00375df3224e6213a89730da1232b259535984a5e26",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686150936,
"kind": 1,
"tags": [
[
"e",
"a5889b6003c7241c893062a271bfd01eb179b582d390c0baf2198e69cbfe2d2d",
"",
"root"
],
[
"e",
"8954f1150813276505e41f58f16f34721a01867b7ac74ae900a0f249b35b0f1b",
"",
"reply"
],
[
"p",
"c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7"
]
],
"content": "📅 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/",
"sig": "e5c4c9cdfe3fe8775db3c769d6c1ac19968552aa85b3602948090f26cf0c061e751324dbb905571d818ce6074322f6aef806bc06729a3e3a525724e677b318ec"
}