Melvin Carvalho [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-13 📝 Original message:On 13 March 2014 16:50, ...
📅 Original date posted:2014-03-13
📝 Original message:On 13 March 2014 16:50, Mike Hearn <mike at plan99.net> wrote:
> 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.
>
+1 agree with Mike on everything
A couple of points:
1. bitcoinity already switched to mbtc aka millitbits (
https://en.bitcoin.it/wiki/MilliBit ) and it was positively recieved, they
got quite a few donations
2. If you watch Gavin's talk at the CFR he suggests the community comes to
a consensus through implementations rather than top down decision making
(If I understood correctly)
I think it's up to wallet maintainers whether to switch the default.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/8d9f087b/attachment.html>;
📝 Original message:On 13 March 2014 16:50, Mike Hearn <mike at plan99.net> wrote:
> 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.
>
+1 agree with Mike on everything
A couple of points:
1. bitcoinity already switched to mbtc aka millitbits (
https://en.bitcoin.it/wiki/MilliBit ) and it was positively recieved, they
got quite a few donations
2. If you watch Gavin's talk at the CFR he suggests the community comes to
a consensus through implementations rather than top down decision making
(If I understood correctly)
I think it's up to wallet maintainers whether to switch the default.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140313/8d9f087b/attachment.html>;