Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.172 as permitted sender)
	client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f172.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAJHLa0PB-V+KgEr5uCj+mceESggp8G4MmLGHHpz2UD_R_w-zfQ@mail.gmail.com>
References: <CAKaEYhK4oXH3hB7uS3=AEkA6r0VB5OYyTua+LOP18rq+rYajHg@mail.gmail.com>
	<52852C2D.9020103@gmail.com> <52853D8A.6010501@monetize.io>
	<CAJHLa0M6CkoDbD6FFixf9-mmhug7DvehSWCJ+EHWVxUDuwNiBg@mail.gmail.com>
	<EE02A310-8604-4811-B2D0-FC32C72C20F3@grabhive.com>
	<CAJHLa0OMcTCgGESi-F4jT2NA3FyCeMYbD_52j47t3keEYBfK8g@mail.gmail.com>
	<CA+s+GJBSGPBQWWYR1NYSc2E4Y1BWAn8zf7xsu4wQ1O8cA8OWbw@mail.gmail.com>
	<CAJHLa0NEEppHg_Lmi_Oxnz_gPSHZPfQpeg+-8MrvFYDmdM83-g@mail.gmail.com>
	<CANEZrP2O4hDBiCNvO1oV5X7OtnQ4xVDD=RtozQY8ESRHgXQu9w@mail.gmail.com>
	<CAJHLa0PB-V+KgEr5uCj+mceESggp8G4MmLGHHpz2UD_R_w-zfQ@mail.gmail.com>
Date: Thu, 13 Mar 2014 16:50:14 +0100
Message-ID: <CANEZrP1sJKGP5A82HbUU+v3oTsc5=U5Gq4Z5TrJ4=2FXLZq4yQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=089e0141ab82b7e38c04f47ee880
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Wendell <w@grabhive.com>
Subject: Re: [Bitcoin-development] moving the default display to mbtc
Precedence: list

--089e0141ab82b7e38c04f47ee880
Content-Type: text/plain; charset=UTF-8

On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> Such hand-wavy, data-free logic is precisely why community
> coordination is preferred to random apps making random decisions in
> this manner.
>

That ship sailed months ago. If you wanted a big push for uBTC, then would
have been the time. Though given that it'd have made lots of normal
balances incredibly huge, perhaps it's a good thing that didn't happen.
Also "milli" is a unit people encounter in daily life whereas micro isn't.
Is it milli / micro / nano or milli / nano / micro? I bet a lot of people
would get that wrong.

If you have to export to financial packages that can't handle fractional
pennies, then by all means represent prices in whatever units you like for
that purpose, but in software designed for ordinary people in everyday life
mBTC is a pretty good fit.

Besides, fractional pennies crop up in existing currencies too (the famous
Verizon Math episode showed this), so if a financial package insists on
rounding to 2dp then I guess it may sometimes do the wrong thing in some
business cases already.

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.


Lots of people use currencies that don't have any fractional components at
all ! So perhaps all prices should be denominated in satoshis to ensure
that they're not surprised :)

The (number) line has to be drawn somewhere. Wallets are free to suppress
more than 2dp of precision and actually Andreas' app lets you choose your
preferred precision. So I think in the end it won't matter a whole lot, if
the defaults end up being wrong people can change them until wallet authors
catch up.

--089e0141ab82b7e38c04f47ee880
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 13, 2014 at 3:32 PM, Jeff Garzik <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bitpay.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">Such hand-wavy, data-free lo=
gic is precisely why community<br></div>
coordination is preferred to random apps making random decisions in<br>
this manner.<br></blockquote><div><br></div><div>That ship sailed months ag=
o. If you wanted a big push for uBTC, then would have been the time. Though=
 given that it&#39;d have made lots of normal balances incredibly huge, per=
haps it&#39;s a good thing that didn&#39;t happen. Also &quot;milli&quot; i=
s a unit people encounter in daily life whereas micro isn&#39;t. Is it mill=
i / micro / nano or milli / nano / micro? I bet a lot of people would get t=
hat wrong.</div>
<div><br></div><div>If you have to export to financial packages that can=
9;t handle fractional pennies, then by all means represent prices in whatev=
er units you like for that purpose, but in software designed for ordinary p=
eople in everyday life mBTC is a pretty good fit.</div>
<div>=C2=A0</div><div>Besides, fractional pennies crop up in existing curre=
ncies too (the famous Verizon Math episode showed this), so if a financial =
package insists on rounding to 2dp then I guess it may sometimes do the wro=
ng thing in some business cases already.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">Fundamentally, more than two =
decimal places tends to violate the<br>
Principle Of Least Astonishment with many humans, and as a result,<br>
popular software systems have been written with that assumption.</blockquot=
e><div><br></div><div>Lots of people use currencies that don&#39;t have any=
 fractional components at all ! So perhaps all prices should be denominated=
 in satoshis to ensure that they&#39;re not surprised :)</div>
<div><br></div><div>The (number) line has to be drawn somewhere. Wallets ar=
e free to suppress more than 2dp of precision and actually Andreas&#39; app=
 lets you choose your preferred precision. So I think in the end it won&#39=
;t matter a whole lot, if the defaults end up being wrong people can change=
 them until wallet authors catch up.</div>
</div></div></div>

--089e0141ab82b7e38c04f47ee880--