1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WO7tk-00085A-GW
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Mar 2014 15:50:20 +0000
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;
Received: from mail-ob0-f172.google.com ([209.85.214.172])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WO7tj-0007EN-Jl
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Mar 2014 15:50:20 +0000
Received: by mail-ob0-f172.google.com with SMTP id wm4so1234336obc.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 13 Mar 2014 08:50:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.219.167 with SMTP id pp7mr842229obc.85.1394725814262;
Thu, 13 Mar 2014 08:50:14 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 13 Mar 2014 08:50:14 -0700 (PDT)
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
X-Google-Sender-Auth: r5TrebQYP4nN7lLNe7cx-gSYodQ
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
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1WO7tj-0007EN-Jl
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Wendell <w@grabhive.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 13 Mar 2014 15:50:20 -0000
--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"><<a href=3D"m=
ailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bitpay.com</a>></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'd have made lots of normal balances incredibly huge, per=
haps it's a good thing that didn't happen. Also "milli" i=
s a unit people encounter in daily life whereas micro isn'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't have any=
fractional components at all ! So perhaps all prices should be denominated=
in satoshis to ensure that they'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' 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.</div>
</div></div></div>
--089e0141ab82b7e38c04f47ee880--
|
