Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-13 📝 Original message:On Thu, Mar 13, 2014 at ...
📅 Original date posted:2014-03-13
📝 Original message:On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik <jgarzik at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/70575f0a/attachment.html>;
📝 Original message:On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik <jgarzik at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/70575f0a/attachment.html>;