From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WO8H5-00073U-Pg for bitcoin-development@lists.sourceforge.net; Thu, 13 Mar 2014 16:14:27 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.45 as permitted sender) client-ip=209.85.192.45; envelope-from=etotheipi@gmail.com; helo=mail-qg0-f45.google.com; Received: from mail-qg0-f45.google.com ([209.85.192.45]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WO8H4-0007at-T7 for bitcoin-development@lists.sourceforge.net; Thu, 13 Mar 2014 16:14:27 +0000 Received: by mail-qg0-f45.google.com with SMTP id j5so3609851qga.4 for ; Thu, 13 Mar 2014 09:14:21 -0700 (PDT) X-Received: by 10.140.84.200 with SMTP id l66mr3195065qgd.75.1394727261509; Thu, 13 Mar 2014 09:14:21 -0700 (PDT) Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. [76.111.96.126]) by mx.google.com with ESMTPSA id g92sm3861792qge.7.2014.03.13.09.14.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 09:14:20 -0700 (PDT) Message-ID: <5321D95C.2070402@gmail.com> Date: Thu, 13 Mar 2014 12:14:20 -0400 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <52852C2D.9020103@gmail.com> <52853D8A.6010501@monetize.io> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.192.45 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WO8H4-0007at-T7 Subject: Re: [Bitcoin-development] moving the default display to mbtc X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 16:14:27 -0000 On 03/13/2014 10:32 AM, Jeff Garzik wrote: > On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn wrote: >> BitPay should use mBTC as well. Unless you can point to any major wallets, >> exchanges or price watching sites that use uBTC by default? >> >> I think it is highly optimistic to assume we'll need another 1000x shift any >> time soon. By now Bitcoin isn't obscure anymore. Lots of people have heard > Such hand-wavy, data-free logic is precisely why community > coordination is preferred to random apps making random decisions in > this manner. > > mBTC is problematic because you do not need 1000x shift in value to > produce annoyances for major accounting packages that are hard-limited > to two decimal places. Further, spreadsheets hide information if > formatting is configured naively -- that is, if formatting is > configured for bitcoin the way it is configured for other currencies. > > Fundamentally, more than two decimal places tends to violate the > Principle Of Least Astonishment with many humans, and as a result, > popular software systems have been written with that assumption. > I whole-heartedly agree with Jeff. micro-BTC was the way to go to end user confusion and make things easier for software systems which are designed to handle money (i.e. two decimal places). I also echo the sentiment about people being able to handle large numbers well. We've been working with Marty Zigman who's creating a Bitcoin plugin for NetSuite accounting platform, and he was already forced to switch micro-BTC long ago for exactly the reasons described above. I think the system will track up to 3 decimal places without causing all sorts of heartache and automatic rounding. 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.