{"type":"rich","version":"1.0","author_name":"npub12rkw0jajmsck4uwdtksdvtswrlkypusfryjzera7m4fhqta6jhdsz3aqxc","author_url":"https://nostr.ae/npub12rkw0jajmsck4uwdtksdvtswrlkypusfryjzera7m4fhqta6jhdsz3aqxc","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-13\n📝 Original message:I agree with you Jeff. The unit switch needs to happen once and once only,\nbut that is exactly why I said the defaults really need to change in\nBitcoin-Qt since that is still the main reference implementation and it\nwill influence others.\n\nBitpay could also take the lead here and make the switch to their defaults.\nThat would greatly assist the uBTC movement.\n\nRegardless of what anyone says, Bitcoin-Qt is still the main reference\nimplementation and the best way to encourage a change in the community at\nlarge is for the default units to be changed here. Core devs can surely\ngarner enough consensus among themselves to accept and merge a PR to that\neffect. That will send a message, more than anything else that can be done.\n\nMy two satoshi.\n\nDrak\n\n\nOn 13 March 2014 16:29, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\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\n\u003e --\n\u003e Jeff Garzik\n\u003e Bitcoin core developer and open source evangelist\n\u003e BitPay, Inc.      https://bitpay.com/\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Graph Databases - Download FREE O'Reilly Book\n\u003e \"Graph Databases\" is the definitive new guide to graph databases and their\n\u003e applications. Written by three acclaimed leaders in the field,\n\u003e this first edition is now available. Download your free book today!\n\u003e http://p.sf.net/sfu/13534_NeoTech\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/ed4f62d7/attachment.html\u003e"}