Re: moving the default display to mbtc

Re: moving the default display to mbtc
2013-11-14 18:18 ` Luke-Jr
                   ` (3 more replies)
  
From: Melvin Carvalho @ 2013-11-14 11:45 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

Rationale
=======

Given the recent rise in value there seems to be anecdotal evidence that 1
bitcoin being so high is putting off a lot of normal buyers, because they
feel that putting down $400+ and only getting "1 coin", or having to buy in
multiples of 1 whole coin, is too much.. only after it being explained that
they can buy fractional amounts to they regain interest, apparently
happening increasingly.


Straw Poll
========

6 months ago there was a straw poll on this

https://bitcointalk.org/index.php?topic=220322.0

Roughly 2/3 of respondents favoured switching

A further 20% said to switch after it hits 1000

Satoshi's comments:
================

Eventually at most only 21 million coins for 6.8 billion people in the
world if it really gets huge.

But don't worry, there are another 6 decimal places that aren't shown, for
a total of 8 decimal places internally.  It shows 1.00 but internally it's
1.00000000.  If there's massive deflation in the future, the software could
show more decimal places.

If it gets tiresome working with small numbers, we could change where the
display shows the decimal point.  Same amount of money, just different
convention for where the ","'s and "."'s go.  e.g. moving the decimal place
3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.

https://bitcointalk.org/index.php?topic=44.msg267#msg267


Would now be a good time to start thinking about changing the default
display in the software.  Perhaps initially it could be a dropdown display
option, then at some point mbtc becomes the default?

[-- Attachment #2: Type: text/html, Size: 2005 bytes --]

 permalink raw reply	[|nested]
2013-11-14 11:45 Melvin Carvalho

  2013-11-17  3:22   ` Jacob Lyles
  2013-11-14 20:01 ` Alan Reiner
                   ` (2 subsequent siblings)
  
From: Luke-Jr @ 2013-11-14 18:18 UTC (permalink / raw)
  To: bitcoin-development

On Thursday, November 14, 2013 11:45:51 AM Melvin Carvalho wrote:
> Would now be a good time to start thinking about changing the default
> display in the software.  Perhaps initially it could be a dropdown display
> option, then at some point mbtc becomes the default?

There's already a dropdown display option...



 permalink raw reply	[|nested]
2013-11-14 11:45 Melvin Carvalho
  2013-11-14 18:18 ` Luke-Jr

  2013-11-14 21:15   ` Mark Friedenbach
  2013-11-15 10:45   ` Wladimir
  2013-11-14 22:27 ` Drak
  2014-05-02 14:29 ` Melvin Carvalho
  
From: Alan Reiner @ 2013-11-14 20:01 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 3459 bytes --]

I highly recommend that if we make any move towards this, that the
software show verification in both/all units.

For instance, there should be 3 input fields, one for "BTC", one for
"mBTC" one for "uBTC".  As the user enters a value in one of the fields,
it would automatically update the other fields with the converted value
as they type.  This makes it really difficult to get it wrong... if
you're typing "10" into the BTC field, thinking it's mBTC, you'll see
10,000 mBTC showing up in the other box as you type.  Similarly, it
should display all units on all verification windows.  Users may also
use it for sanity checking conversion between units.

Personally, I'm of the opinion that this change is important in the long
run:  the current price makes Bitcoin *intimidating* to new users.  But
I'm also of the opinion that it's freakin' hard to change the base unit
in such an established system.  There is no easy way to do this that
doesn't cause more heartache than it's worth.  But it's possible if you
make it idiot-proof enough, and roll it out in the least inconvenient way.

-Alan


On 11/14/2013 06:45 AM, Melvin Carvalho wrote:
> Rationale
> =======
>
> Given the recent rise in value there seems to be anecdotal evidence
> that 1 bitcoin being so high is putting off a lot of normal buyers,
> because they feel that putting down $400+ and only getting "1 coin",
> or having to buy in multiples of 1 whole coin, is too much.. only
> after it being explained that they can buy fractional amounts to they
> regain interest, apparently happening increasingly.
>
>
> Straw Poll
> ========
>
> 6 months ago there was a straw poll on this
>
> https://bitcointalk.org/index.php?topic=220322.0
>
> Roughly 2/3 of respondents favoured switching
>
> A further 20% said to switch after it hits 1000
>
> Satoshi's comments:
> ================
>
> Eventually at most only 21 million coins for 6.8 billion people in the
> world if it really gets huge.
>
> But don't worry, there are another 6 decimal places that aren't shown,
> for a total of 8 decimal places internally.  It shows 1.00 but
> internally it's 1.00000000.  If there's massive deflation in the
> future, the software could show more decimal places.
>
> If it gets tiresome working with small numbers, we could change where
> the display shows the decimal point.  Same amount of money, just
> different convention for where the ","'s and "."'s go.  e.g. moving
> the decimal place 3 places would mean if you had 1.00000 before, now
> it shows it as 1,000.00.
>
> https://bitcointalk.org/index.php?topic=44.msg267#msg267
>
>
> Would now be a good time to start thinking about changing the default
> display in the software.  Perhaps initially it could be a dropdown
> display option, then at some point mbtc becomes the default?
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Type: text/html, Size: 5661 bytes --]

 permalink raw reply	[|nested]
2013-11-14 20:01 ` Alan Reiner

  2013-11-14 21:55     ` Allen Piscitello
  2013-11-14 22:03     ` Jeff Garzik
  2013-11-15 10:45   ` Wladimir
  
From: Mark Friedenbach @ 2013-11-14 21:15 UTC (permalink / raw)
  To: bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For this reason I'm in favor of skipping mBTC and moving straight to
uBTC. Having eight, or even five decimal places is not intuitive to
the average user. Two decimal places is becoming standard for new
national currencies, and we wouldn't be too far from human scale
everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
many people on this list would consider bitcoin overvalued in the long
term perspective.

Better to go through a confusing renumbering only once.

Mark

On 11/14/13 12:01 PM, Alan Reiner wrote:
> ... I'm also of the opinion that it's freakin' hard to change the
> base unit in such an established system.  There is no easy way to
> do this that doesn't cause more heartache than it's worth...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShT2JAAoJEAdzVfsmodw4DXAQAIJTNbpwBGTXuFyaxXQULf20
hMs7OlQZSOZOdsmSiPv2augxzbpa2DhhZjiosrScSBCjxMeYd4S6WgTt/b8moAYR
HD8pm88JyCKDOd7bOmzTkgDOTBBFfH+islmOY9VTdeKGHeOHH6yyLMKwnUpa+S89
4YtdzlIXAtfT37dpR5E4cHPmAYCbrRsNOB6j5ohVl2VqRou2vkwoJr/YvaW54M8i
ucIZyai2qjNWyJLcZC9QWi9Yw/W/n9QYE2mHyL0qWNaIrZVn6WGty8KpYq+i7aeU
4N4UdtLT7FAhWYec9nmEec868WsUsd+H3/WSWViMinUKO4YA3cyxWDL7MTmTRsci
g0R4WGYCzMM3cEWz5ycf5KEBPH/nDlbqFmEartTffqKXgrK5Ohhw+28Iqw5KcDX8
SVx34lw2yHWmTeIMY8d3qYKqBdcsvixDUD3xvq+ZqEIa+bZw12s4LIzqmir84TB8
fB4bdq5GddXX0PK4pboXL+Nib0OVK72YgYnVs/ejlBmeiG8Ixoz4/ygR5MHm8jcw
tSiwH0xohOJWg3lJj0vZorubXoECcOqwPzsZkwnT9irbrvOuk2jCPvrkEC8U9fgA
XHgirStS49/lI/iUWrRchoTt5iuwG18G4+E81V/DMsrSkYlipuf2DlEXiapn3hWz
ccP053+6o5Rgpc7J1aa0
=QW1i
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
2013-11-14 21:15   ` Mark Friedenbach

  2013-11-14 22:00       ` Alan Reiner
  2014-05-02 19:17       ` Jeff Garzik
  2013-11-14 22:03     ` Jeff Garzik
  
From: Allen Piscitello @ 2013-11-14 21:55 UTC (permalink / raw)
  To: Mark Friedenbach;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]

I also would prefer to go straight to uBTC as the "standard wallet unit".
 It works out perfectly with Satoshi's being the decimal units.  Something
that costs $10USD would be 25000uBTC.  This isn't a problem for a place
like South Korea, where 10USD is about 10,000 Won, so we aren't even off on
a scale of usable currencies in major economies.

The downsides are obviously confusion (causing mistakes resulting in lost
coins), and possibly from a psychological perspective on price (uBTC are
worthless!).  On the other hand, it also might help people feel like they
are getting in on the ground floor still (I own 100,000 uBTC!), and reduce
the perception the Bitcoins are not divisible (I have heard several people
worry that 21 million is not enough units).

Alan's ideas for compatibility with multiple fields will also be helpful to
solving the confusion issue.



On Thu, Nov 14, 2013 at 3:15 PM, Mark Friedenbach <mark@monetize•io> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For this reason I'm in favor of skipping mBTC and moving straight to
> uBTC. Having eight, or even five decimal places is not intuitive to
> the average user. Two decimal places is becoming standard for new
> national currencies, and we wouldn't be too far from human scale
> everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
> many people on this list would consider bitcoin overvalued in the long
> term perspective.
>
> Better to go through a confusing renumbering only once.
>
> Mark
>
> On 11/14/13 12:01 PM, Alan Reiner wrote:
> > ... I'm also of the opinion that it's freakin' hard to change the
> > base unit in such an established system.  There is no easy way to
> > do this that doesn't cause more heartache than it's worth...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJShT2JAAoJEAdzVfsmodw4DXAQAIJTNbpwBGTXuFyaxXQULf20
> hMs7OlQZSOZOdsmSiPv2augxzbpa2DhhZjiosrScSBCjxMeYd4S6WgTt/b8moAYR
> HD8pm88JyCKDOd7bOmzTkgDOTBBFfH+islmOY9VTdeKGHeOHH6yyLMKwnUpa+S89
> 4YtdzlIXAtfT37dpR5E4cHPmAYCbrRsNOB6j5ohVl2VqRou2vkwoJr/YvaW54M8i
> ucIZyai2qjNWyJLcZC9QWi9Yw/W/n9QYE2mHyL0qWNaIrZVn6WGty8KpYq+i7aeU
> 4N4UdtLT7FAhWYec9nmEec868WsUsd+H3/WSWViMinUKO4YA3cyxWDL7MTmTRsci
> g0R4WGYCzMM3cEWz5ycf5KEBPH/nDlbqFmEartTffqKXgrK5Ohhw+28Iqw5KcDX8
> SVx34lw2yHWmTeIMY8d3qYKqBdcsvixDUD3xvq+ZqEIa+bZw12s4LIzqmir84TB8
> fB4bdq5GddXX0PK4pboXL+Nib0OVK72YgYnVs/ejlBmeiG8Ixoz4/ygR5MHm8jcw
> tSiwH0xohOJWg3lJj0vZorubXoECcOqwPzsZkwnT9irbrvOuk2jCPvrkEC8U9fgA
> XHgirStS49/lI/iUWrRchoTt5iuwG18G4+E81V/DMsrSkYlipuf2DlEXiapn3hWz
> ccP053+6o5Rgpc7J1aa0
> =QW1i
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 4425 bytes --]

 permalink raw reply	[|nested]
2013-11-14 21:55     ` Allen Piscitello

  2013-11-14 22:07         ` Allen Piscitello
                           ` (2 more replies)
  2014-05-02 19:17       ` Jeff Garzik
  
From: Alan Reiner @ 2013-11-14 22:00 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]

Just keep in mind it will be a little awkward that 54.3 uBTC is the
smallest unit that can be transferred [easily] and the standard fees are
500 uBTC.    It's not a deal breaker, it's just something that needs to
be taken into consideration when it comes to user perception (which is
one of the reasons we would make such a change in the first place). 

"Holy crap these fees are huge!  I thought Bitcoin didn't have fees!"


On 11/14/2013 04:55 PM, Allen Piscitello wrote:
> I also would prefer to go straight to uBTC as the "standard wallet unit".    It works out
perfectly with Satoshi's being the decimal units.  Something that costs
$10USD would be 25000uBTC.  This isn't a problem for a place like South
Korea, where 10USD is about 10,000 Won, so we aren't even off on a scale
of usable currencies in major economies.
>
> The downsides are obviously confusion (causing mistakes resulting in
lost coins), and possibly from a psychological perspective on price
(uBTC are worthless!).  On the other hand, it also might help people
feel like they are getting in on the ground floor still (I own 100,000
uBTC!), and reduce the perception the Bitcoins are not divisible (I have
heard several people worry that 21 million is not enough units).
>
> Alan's ideas for compatibility with multiple fields will also be
helpful to solving the confusion issue.
>
>
>
> On Thu, Nov 14, 2013 at 3:15 PM, Mark Friedenbach <mark@monetize•io
<mailto:mark@monetize•io>> wrote:
>
> For this reason I'm in favor of skipping mBTC and moving straight to
> uBTC. Having eight, or even five decimal places is not intuitive to
> the average user. Two decimal places is becoming standard for new
> national currencies, and we wouldn't be too far from human scale
> everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
> many people on this list would consider bitcoin overvalued in the long
> term perspective.
>
> Better to go through a confusing renumbering only once.
>
> Mark
>
> On 11/14/13 12:01 PM, Alan Reiner wrote:
> > ... I'm also of the opinion that it's freakin' hard to change the
> > base unit in such an established system.  There is no easy way to
> > do this that doesn't cause more heartache than it's worth...
>
>    
------------------------------------------------------------------------------
>     DreamFactory - Open Source REST & JSON Services for HTML5 & Native
Apps
>     OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>     Free app hosting. Or install the open source package on any LAMP
server.
>     Sign up and see examples for AngularJS, jQuery, Sencha Touch and
Native!
>    
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists•sourceforge.net
<mailto:Bitcoin-development@lists•sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



[-- Attachment #2: Type: text/html, Size: 5999 bytes --]

 permalink raw reply	[|nested]
2013-11-14 21:15   ` Mark Friedenbach
  2013-11-14 21:55     ` Allen Piscitello

  2013-11-14 22:31       ` Mark Friedenbach
                         ` (2 more replies)
  
From: Jeff Garzik @ 2013-11-14 22:03 UTC (permalink / raw)
  To: Mark Friedenbach;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2743 bytes --]

Go straight to uBTC. Humans and existing computer systems handle numbers to
the left of the decimals just fine (HK Dollars, Yen). The opposite is
untrue (QuickBooks really does not like 3+ decimal places).

     - Jeff
On Nov 14, 2013 4:40 PM, "Mark Friedenbach" <mark@monetize•io> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For this reason I'm in favor of skipping mBTC and moving straight to
> uBTC. Having eight, or even five decimal places is not intuitive to
> the average user. Two decimal places is becoming standard for new
> national currencies, and we wouldn't be too far from human scale
> everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
> many people on this list would consider bitcoin overvalued in the long
> term perspective.
>
> Better to go through a confusing renumbering only once.
>
> Mark
>
> On 11/14/13 12:01 PM, Alan Reiner wrote:
> > ... I'm also of the opinion that it's freakin' hard to change the
> > base unit in such an established system.  There is no easy way to
> > do this that doesn't cause more heartache than it's worth...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJShT2JAAoJEAdzVfsmodw4DXAQAIJTNbpwBGTXuFyaxXQULf20
> hMs7OlQZSOZOdsmSiPv2augxzbpa2DhhZjiosrScSBCjxMeYd4S6WgTt/b8moAYR
> HD8pm88JyCKDOd7bOmzTkgDOTBBFfH+islmOY9VTdeKGHeOHH6yyLMKwnUpa+S89
> 4YtdzlIXAtfT37dpR5E4cHPmAYCbrRsNOB6j5ohVl2VqRou2vkwoJr/YvaW54M8i
> ucIZyai2qjNWyJLcZC9QWi9Yw/W/n9QYE2mHyL0qWNaIrZVn6WGty8KpYq+i7aeU
> 4N4UdtLT7FAhWYec9nmEec868WsUsd+H3/WSWViMinUKO4YA3cyxWDL7MTmTRsci
> g0R4WGYCzMM3cEWz5ycf5KEBPH/nDlbqFmEartTffqKXgrK5Ohhw+28Iqw5KcDX8
> SVx34lw2yHWmTeIMY8d3qYKqBdcsvixDUD3xvq+ZqEIa+bZw12s4LIzqmir84TB8
> fB4bdq5GddXX0PK4pboXL+Nib0OVK72YgYnVs/ejlBmeiG8Ixoz4/ygR5MHm8jcw
> tSiwH0xohOJWg3lJj0vZorubXoECcOqwPzsZkwnT9irbrvOuk2jCPvrkEC8U9fgA
> XHgirStS49/lI/iUWrRchoTt5iuwG18G4+E81V/DMsrSkYlipuf2DlEXiapn3hWz
> ccP053+6o5Rgpc7J1aa0
> =QW1i
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3558 bytes --]

 permalink raw reply	[|nested]
2013-11-14 22:00       ` Alan Reiner

  2013-11-14 23:01           ` Luke-Jr
  2013-11-15  8:55           ` Eugen Leitl
  2013-11-14 22:21         ` Mark Friedenbach
  2013-11-14 22:32         ` Drak
  
From: Allen Piscitello @ 2013-11-14 22:07 UTC (permalink / raw)
  To: Alan Reiner;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 4869 bytes --]

Obviously the answer is to just display all fees and trading rates as BTC
or MBTC (.0000005 MBTC fee? how cheap!).  On a more serious note, the
transition should definitely be thought out well as it could be very
damaging to have this confusion, but I would prefer to do it only once
rather than twice.


On Thu, Nov 14, 2013 at 4:00 PM, Alan Reiner <etotheipi@gmail•com> wrote:

>  Just keep in mind it will be a little awkward that 54.3 uBTC is the
> smallest unit that can be transferred [easily] and the standard fees are
> 500 uBTC.    It's not a deal breaker, it's just something that needs to be
> taken into consideration when it comes to user perception (which is one of
> the reasons we would make such a change in the first place).
>
> "Holy crap these fees are huge!  I thought Bitcoin didn't have fees!"
>
>
>
> On 11/14/2013 04:55 PM, Allen Piscitello wrote:
> > I also would prefer to go straight to uBTC as the "standard wallet
> unit".    It works out perfectly with Satoshi's being the decimal units.
> Something that costs $10USD would be 25000uBTC.  This isn't a problem for a
> place like South Korea, where 10USD is about 10,000 Won, so we aren't even
> off on a scale of usable currencies in major economies.
> >
> > The downsides are obviously confusion (causing mistakes resulting in
> lost coins), and possibly from a psychological perspective on price (uBTC
> are worthless!).  On the other hand, it also might help people feel like
> they are getting in on the ground floor still (I own 100,000 uBTC!), and
> reduce the perception the Bitcoins are not divisible (I have heard several
> people worry that 21 million is not enough units).
> >
> > Alan's ideas for compatibility with multiple fields will also be helpful
> to solving the confusion issue.
> >
> >
> >
> > On Thu, Nov 14, 2013 at 3:15 PM, Mark Friedenbach <mark@monetize•io
> <mailto:mark@monetize•io> <mark@monetize•io>> wrote:
> >
>
> For this reason I'm in favor of skipping mBTC and moving straight to
> uBTC. Having eight, or even five decimal places is not intuitive to
> the average user. Two decimal places is becoming standard for new
> national currencies, and we wouldn't be too far from human scale
> everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
> many people on this list would consider bitcoin overvalued in the long
> term perspective.
>
> Better to go through a confusing renumbering only once.
>
> Mark
>
> On 11/14/13 12:01 PM, Alan Reiner wrote:
> > ... I'm also of the opinion that it's freakin' hard to change the
> > base unit in such an established system.  There is no easy way to
> > do this that doesn't cause more heartache than it's worth...
>
> >
>
> >
> ------------------------------------------------------------------------------
> >     DreamFactory - Open Source REST & JSON Services for HTML5 & Native
> Apps
> >     OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> >     Free app hosting. Or install the open source package on any LAMP
> server.
> >     Sign up and see examples for AngularJS, jQuery, Sencha Touch and
> Native!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> >     _______________________________________________
> >     Bitcoin-development mailing list
> >     Bitcoin-development@lists•sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net><Bitcoin-development@lists•sourceforge.net>
> >     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> > Free app hosting. Or install the open source package on any LAMP server.
> > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 7475 bytes --]

 permalink raw reply	[|nested]
2013-11-14 22:00       ` Alan Reiner
  2013-11-14 22:07         ` Allen Piscitello

  2013-11-14 22:32         ` Drak
  
From: Mark Friedenbach @ 2013-11-14 22:21 UTC (permalink / raw)
  To: bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/13 2:00 PM, Alan Reiner wrote:
> Just keep in mind it will be a little awkward that 54.3 uBTC is
> the smallest unit that can be transferred [easily] and the standard
> fees are 500 uBTC.    It's not a deal breaker, it's just something
> that needs to be taken into consideration when it comes to user
> perception (which is one of the reasons we would make such a change
> in the first place).
> 
> "Holy crap these fees are huge!  I thought Bitcoin didn't have
> fees!"

Well.. they are huge. 20 cents suggested fee for a irrevocable
transaction?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShU0EAAoJEAdzVfsmodw4TlAP/33KPX3ypMZ0PyHQVg3OCX21
hUXhTQBBO3JjO7x4HoNqdV0fApfCldq4cl/pNENG74inVuYNH+dUwUBIF6q6Qzfs
RU45++yytPob28ZojgrQgZq7/lAvi9qvsg5tLMyLt72uf3Kz1whmiRAHI5qaJ/xW
5w9LfOxXHFVkTQsUPzIjbD2kYAqUNILMzndKSv4YwRruYNm60gxCh2mQvgNr3s1Z
oGdLsPhx6AA1+Y6tgvnZVm71dwYUyg7OAafzGtpGEz953/cQwbgTqsZ3CrOiPk67
OJ9XxRPREOyKTDYo1WcM1GlQAq9LOHkMcU5OWS7TX2DzZAbLc7TqmqSMuAHdn6d5
eh+AgRWN1ppgVzHaCfgGSfP4NdXHRuMbDvSSoeiP+JLZ1ateT1aesklOaPRFfieW
NUJ61XAFWYCuVEK/ctUhSKMd19Rao23yuly+PtrMHvCw6Zn/LrpA4z2nD4vTFTXi
WeFyYwjIDjKBeuQMfWg5I2uMpo+9vC/DA3cwPticV7+LD7wsATHVNWVzuHlmjgTX
CPO4tVkqBPk7NsqDreOaVhvgnbAUHknyeDqguYS2LppDGu4P4XiOIHpS3reRyHuc
/NbXAvDkR23JGQFeHgdR/E983TdsqUiH3US43Cy3ikEcWm79eNG0cPGuHHVZBjPh
AACKjmPS+JR7rBAKFSGl
=f9P7
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
* 
  2013-11-14 11:45 Melvin Carvalho
                   ` 
  2013-11-14 22:27 ` 

  3 siblings, 0 replies; 112+ messages in thread
From: Melvin Carvalho @ 2014-05-02 14:29 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

On 14 November 2013 12:45, Melvin Carvalho <melvincarvalho@gmail•com> wrote:

> Rationale
> =======
>
> Given the recent rise in value there seems to be anecdotal evidence that 1
> bitcoin being so high is putting off a lot of normal buyers, because they
> feel that putting down $400+ and only getting "1 coin", or having to buy in
> multiples of 1 whole coin, is too much.. only after it being explained that
> they can buy fractional amounts to they regain interest, apparently
> happening increasingly.
>
>
> Straw Poll
> ========
>
> 6 months ago there was a straw poll on this
>
> https://bitcointalk.org/index.php?topic=220322.0
>
> Roughly 2/3 of respondents favoured switching
>
> A further 20% said to switch after it hits 1000
>
> Satoshi's comments:
> ================
>
> Eventually at most only 21 million coins for 6.8 billion people in the
> world if it really gets huge.
>
> But don't worry, there are another 6 decimal places that aren't shown, for
> a total of 8 decimal places internally.  It shows 1.00 but internally it's
> 1.00000000.  If there's massive deflation in the future, the software could
> show more decimal places.
>
> If it gets tiresome working with small numbers, we could change where the
> display shows the decimal point.  Same amount of money, just different
> convention for where the ","'s and "."'s go.  e.g. moving the decimal place
> 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.
>
> https://bitcointalk.org/index.php?topic=44.msg267#msg267
>
>
> Would now be a good time to start thinking about changing the default
> display in the software.  Perhaps initially it could be a dropdown display
> option, then at some point mbtc becomes the default?
>
>
Just a FYI on this topic.  In Gavin's recent interview he described the
block reward as 25,000 millibits (about 25 minutes in).

https://www.youtube.com/watch?v=4pBd-OD9Rns

Decide for yourself whether or not that's meaningful :)

PS very enjoyable and accessible panel ...

[-- Attachment #2: Type: text/html, Size: 2891 bytes --]

^ permalink raw reply	[|nested] 112+ messages in thread
2013-11-14 22:03     ` Jeff Garzik

  2013-11-14 22:53         ` Alan Reiner
  2013-11-15  7:18       ` Wladimir
  2013-11-18  2:28       ` Wendell
  
From: Mark Friedenbach @ 2013-11-14 22:31 UTC (permalink / raw)
  To: Jeff Garzik;  bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Whoops, this was meant for the list:

Drawing on analogues from national currencies, it's also possible to
alleviate the confusion by switching currency symbols, e.g. to XBT or
NBC (New Bitcoin).

1 XBC == 1 uBTC

On 11/14/13 2:03 PM, Jeff Garzik wrote:
> Go straight to uBTC. Humans and existing computer systems handle
> numbers to the left of the decimals just fine (HK Dollars, Yen).
> The opposite is untrue (QuickBooks really does not like 3+ decimal
> places).
> 
> - Jeff
> 
> On Nov 14, 2013 4:40 PM, "Mark Friedenbach" <mark@monetize•io 
> <mailto:mark@monetize•io>> wrote:
> 
> For this reason I'm in favor of skipping mBTC and moving straight
> to uBTC. Having eight, or even five decimal places is not intuitive
> to the average user. Two decimal places is becoming standard for
> new national currencies, and we wouldn't be too far from human
> scale everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't
> think very many people on this list would consider bitcoin
> overvalued in the long term perspective.
> 
> Better to go through a confusing renumbering only once.
> 
> Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShU9YAAoJEAdzVfsmodw4svUP/1THaWdSoy+/J1Z4QcuoEC5T
Lxyu5uN6d1TRb/fxZ1VQI+FJgRjJTT2zIBrk9lJHBuvYy6Gq6JUjHQZHbC7lhr9Q
nDwM76LFOWPR0PDC9JLIeiDbkIimrARUjrKIMUJYCpQWHfLOZssWjDmLhAucAYcF
gmObw+9M2fR7Xh7X2qOQt+xXWyAeeqCur2EClV+xNnhcyQXyXl2R9qdCF5ugy7k1
nmHhMYap7q8TP2yrH/SloEGor56DICamVNnB91HOiN/QY9fZD0To6+RTJDsu/CR3
01hRS+5JNVEQIBQ7cCxAO7kRxcxf9aDabEdS24r/alpuMg7/32wz/EqCSCqQtSnq
MlvKifF5Bh+Y0hSNbNKdFMSes6fOhoLkl87ugKCkH8FQjI8rev3ke79tGKK92m01
kmSBuzazwjVDNS/wwhPunkaiBaEAtzo1VCilibjjqLQEWdUBdsawsdlLDYb13mQD
xPxDTKB2TR33Iri+mvdAai8qrLGHJUDDLVs5N0uK+tHbxqgznCkQ3NSINtuwFRLk
L1Usvr3XNSc0Jh7lHfPP+voE1TAYsDD3DXmT0eAmIXXzo1E4J2UKzhI+M7kJM8M9
qSzbC3TExmijd9LrOYdVX3Ab+LP6XDSPym4rBb0mAH8DOxKmFOYrNIwURnmGwJFA
jZi0WrHXHpg3ThXP8Jdj
=J7x7
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
2013-11-14 22:00       ` Alan Reiner
  2013-11-14 22:07         ` Allen Piscitello
  2013-11-14 22:21         ` Mark Friedenbach

  2013-11-14 22:37           ` Drak
  
From: Drak @ 2013-11-14 22:32 UTC (permalink / raw)
  To: Alan Reiner;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

On 14 November 2013 22:00, Alan Reiner <etotheipi@gmail•com> wrote:

>  Just keep in mind it will be a little awkward that 54.3 uBTC is the
> smallest unit that can be transferred [easily] and the standard fees are
> 500 uBTC.    It's not a deal breaker,
>

The fed was reduced to 0.0001/kb a while back...

Drak

[-- Attachment #2: Type: text/html, Size: 729 bytes --]

 permalink raw reply	[|nested]
2013-11-14 22:32         ` Drak

  
From: Drak @ 2013-11-14 22:37 UTC (permalink / raw)
  To: Alan Reiner;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On 14 November 2013 22:32, Drak <drak@zikula•org> wrote:

> On 14 November 2013 22:00, Alan Reiner <etotheipi@gmail•com> wrote:
>
>>  Just keep in mind it will be a little awkward that 54.3 uBTC is the
>> smallest unit that can be transferred [easily] and the standard fees are
>> 500 uBTC.    It's not a deal breaker,
>>
>
> The fed was reduced to 0.0001/kb a while back...
>

Hrm. Freudian slip... you know what I mean *fee, not fed.... :-)

.... so in response to those saying the fees are $0.20, actually it's more
like $0.042 at current prices.

Drak

[-- Attachment #2: Type: text/html, Size: 1351 bytes --]

 permalink raw reply	[|nested]
2013-11-14 22:31       ` Mark Friedenbach

  2013-11-14 23:01           ` Jeff Garzik
                             ` (2 more replies)
  
From: Alan Reiner @ 2013-11-14 22:53 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]

I really like the XBT idea.  It makes a lot of sense to match the ISO
currency symbol (though the ISO guys will have to adjust the way they've
defined the "XBT").  And I do agree that going right to uBTC and
skipping mBTC makes sense, too.

I'd prefer them not be called "micro bitcoins."  I really want to call
them "microbes" ... but I'm not sure that has the right flavor for money
transfer :)  "Please give me 872 microbes".  Perhaps we just call them
"bits."  Or even "micros" or "microbits".  As I write this, I realize
there's probably 872 threads on the forums about this already...

But we would want to promote a consistent term, to avoid further
confusion when people use different names for the new unit.  It's not
guaranteed to be successful, but if we pick a good name, and build it
into the interface on the first release pushing the new unit, we have a
chance to make the transition even easier.





On 11/14/2013 05:31 PM, Mark Friedenbach wrote:
> Whoops, this was meant for the list:
>
> Drawing on analogues from national currencies, it's also possible to
> alleviate the confusion by switching currency symbols, e.g. to XBT or
> NBC (New Bitcoin).
>
> 1 XBC == 1 uBTC
>
> On 11/14/13 2:03 PM, Jeff Garzik wrote:
> > Go straight to uBTC. Humans and existing computer systems handle
> > numbers to the left of the decimals just fine (HK Dollars, Yen).
> > The opposite is untrue (QuickBooks really does not like 3+ decimal
> > places).
>
> > - Jeff
>
> > On Nov 14, 2013 4:40 PM, "Mark Friedenbach" <mark@monetize•io
> > <mailto:mark@monetize•io>> wrote:
>
> > For this reason I'm in favor of skipping mBTC and moving straight
> > to uBTC. Having eight, or even five decimal places is not intuitive
> > to the average user. Two decimal places is becoming standard for
> > new national currencies, and we wouldn't be too far from human
> > scale everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't
> > think very many people on this list would consider bitcoin
> > overvalued in the long term perspective.
>
> > Better to go through a confusing renumbering only once.
>
> > Mark
>
>
------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



[-- Attachment #2: Type: text/html, Size: 4227 bytes --]

 permalink raw reply	[|nested]
2013-11-14 22:07         ` Allen Piscitello

  2013-11-14 23:11             ` Mark Friedenbach
  2013-11-16  0:41             ` Drak
  2013-11-15  8:55           ` Eugen Leitl
  
From: Luke-Jr @ 2013-11-14 23:01 UTC (permalink / raw)
  To: bitcoin-development

On Thursday, November 14, 2013 10:07:58 PM Allen Piscitello wrote:
> Obviously the answer is to just display all fees and trading rates as BTC
> or MBTC (.0000005 MBTC fee? how cheap!).  On a more serious note, the
> transition should definitely be thought out well as it could be very
> damaging to have this confusion, but I would prefer to do it only once
> rather than twice.

I wonder if it might make sense to bundle some other terminology fixups at the 
same time.

Right now, Bitcoin-Qt has been using the term "confirmations" (plural) to 
refer to how many blocks deep a transaction is buried. We also use the term 
"confirmation" to refer to the point where a transaction is accepted as paid. 
IMO, the latter use makes sense, but the former leads to confusion especially 
in light of scamcoins which abuse this confusion to claim they have "faster 
confirmations", implying that the actual confirmation occurs faster when it 
really doesn't. "5 blocks deep" may not be more clear to laymen, but at least 
it makes it harder for people to confuse with actual confirmation.

I think we all know the problems with the term "address". People naturally 
compare it to postal addresses, email addresses, etc, which operate 
fundamentally different. I suggest that we switch to using "invoice id" to 
refer to what is now known as addresses, as that seems to get the more natural 
understanding to people. On the other hand, with the advent of the payment 
protocol, perhaps address/invoice id use will die out soon?

Thoughts?

Luke



 permalink raw reply	[|nested]
2013-11-14 22:53         ` Alan Reiner

  2013-11-14 23:10           ` Luke-Jr
  2013-11-15  9:23           ` Eugen Leitl
  
From: Jeff Garzik @ 2013-11-14 23:01 UTC (permalink / raw)
  To: Alan Reiner;  Bitcoin Dev

On Thu, Nov 14, 2013 at 5:53 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> I really like the XBT idea.  It makes a lot of sense to match the ISO

Indeed.  The decimal place move would be an excellent time to switch.

     Jeff



 permalink raw reply	[|nested]
2013-11-14 22:53         ` Alan Reiner
  2013-11-14 23:01           ` Jeff Garzik

  2013-11-15  9:23           ` Eugen Leitl
  
From: Luke-Jr @ 2013-11-14 23:10 UTC (permalink / raw)
  To: bitcoin-development

On Thursday, November 14, 2013 10:53:16 PM Alan Reiner wrote:
> I really like the XBT idea.  It makes a lot of sense to match the ISO
> currency symbol (though the ISO guys will have to adjust the way they've
> defined the "XBT").  And I do agree that going right to uBTC and
> skipping mBTC makes sense, too.
> 
> I'd prefer them not be called "micro bitcoins."  I really want to call
> them "microbes" ... but I'm not sure that has the right flavor for money
> transfer :)  "Please give me 872 microbes".  Perhaps we just call them
> "bits."  Or even "micros" or "microbits".  As I write this, I realize
> there's probably 872 threads on the forums about this already...
> 
> But we would want to promote a consistent term, to avoid further
> confusion when people use different names for the new unit.  It's not
> guaranteed to be successful, but if we pick a good name, and build it
> into the interface on the first release pushing the new unit, we have a
> chance to make the transition even easier.

As long as we're using SI units, IMO we should stick to SI. That means "micro-
bitcoins". *Informally/spoken*, an abbreviation like "mibicoins" might make 
sense.

Luke



 permalink raw reply	[|nested]
2013-11-14 23:01           ` Luke-Jr

  2013-11-14 23:13               ` Luke-Jr
                                 ` (2 more replies)
  2013-11-16  0:41             ` Drak
  
From: Mark Friedenbach @ 2013-11-14 23:11 UTC (permalink / raw)
  To: bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/13 3:01 PM, Luke-Jr wrote:
> I think we all know the problems with the term "address". People
> naturally compare it to postal addresses, email addresses, etc,
> which operate fundamentally different. I suggest that we switch to
> using "invoice id" to refer to what is now known as addresses, as
> that seems to get the more natural understanding to people. On the
> other hand, with the advent of the payment protocol, perhaps
> address/invoice id use will die out soon?
> 
> Thoughts?

"key id" (thanks sipa).

I know it's a more technical term, but that is rather the point. It
was a fundamental error to call hashed-pubkeys "addresses" as people
either associate this with "account" or physical addresses, which also
rarely change.

Security and privacy guarantees of the system are defeated when key
pairs are reused. We should ideally adopt terminology that lead people
to associations of ephemeral, temporary use. "key id" is at least
neutral in this regard. Can anyone think of something better?

Mark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShVieAAoJEAdzVfsmodw4TlkP/i2cZm9NolReIsv6WBNQUGZ6
0VJveOcsOmEXj3ixSyzPRitFl52EOfU+LZaM3liwFPczuIOXZUXOLAJqakxGGsFa
cWwvZjrBk13aTR+4dXZ6OWcCNmTfm6+st2+v1MpQcXlHD8J1WtrdrzKr3fNSntir
yHbNmF6hPfgLr64m52BhUVrxBg9eiIFDI6VCzmUgk+paNmIxs9dgx7POnz1/hQb3
2FGfNt2J81t4F78mpzjtKx+vHRyHpIKJ2+3mjzcQ7IBkhBgPYnp69TwBSGXbg7l9
6yV0P7DGjWepO5+s96GCjbScYpmZO0gx0ZTn/eamfxh20XuX2fZBEVNd1KnhX4Xq
D4UwylGNa5FteRgURtVN5Xdb82jB2qhhr/IkGSgKds24zhHzgvBgvLJBgwtQHwil
M/y2DMC70WVEXf0Fz96L1kNYUA6062/ZNlwITRWxkUUJprF+xyN3R+BVWMggBMnR
Vjht74MZMkJyYlPQr8BRbYdhgMwv6dh0v5T4M6ck6MjKYj/GLsnEfHyY2d/BNg8c
2nkcBC8Dtv9KoFOk6STS1n7R4ooqepmdsRNPBZUzKvv/NN1B1A8jeluLiN9hSzl1
ubDF/34LJTji8bP9jfDBEND94xdaKjTl+2ISweRttBOOVqCtQlzCQ4udiT7vAntb
AYYMBYmYO/A926T+K6Lp
=kFj9
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
2013-11-14 23:11             ` Mark Friedenbach

  2013-11-14 23:22               ` Jeff Garzik
  2013-11-15  0:15               ` Luke-Jr
  
From: Luke-Jr @ 2013-11-14 23:13 UTC (permalink / raw)
  To: bitcoin-development

On Thursday, November 14, 2013 11:11:26 PM Mark Friedenbach wrote:
> "key id" (thanks sipa).
> 
> I know it's a more technical term, but that is rather the point. It
> was a fundamental error to call hashed-pubkeys "addresses" as people
> either associate this with "account" or physical addresses, which also
> rarely change.
> 
> Security and privacy guarantees of the system are defeated when key
> pairs are reused. We should ideally adopt terminology that lead people
> to associations of ephemeral, temporary use. "key id" is at least
> neutral in this regard. Can anyone think of something better?

Keys are often reused, so not sure that conveys the single-use much better.
Reason I suggested invoice id is because nobody wants to pay the same invoice 
twice.

Luke



 permalink raw reply	[|nested]
2013-11-14 23:11             ` Mark Friedenbach
  2013-11-14 23:13               ` Luke-Jr

  2013-11-15  0:15               ` Luke-Jr
  
From: Jeff Garzik @ 2013-11-14 23:22 UTC (permalink / raw)
  To: Mark Friedenbach;  Bitcoin Dev

On Thu, Nov 14, 2013 at 6:11 PM, Mark Friedenbach <mark@monetize•io> wrote:
> "key id" (thanks sipa).

+1, short and accurate

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2013-11-14 22:27 ` Drak

  2013-11-15  0:37     ` Daniel F
  
From: Jeff Garzik @ 2013-11-15  0:05 UTC (permalink / raw)
  To: Drak;  Bitcoin Dev

On Thu, Nov 14, 2013 at 5:27 PM, Drak <drak@zikula•org> wrote:
> Unless something is recommended/done by the bitcoin core developers I doubt
> much will change at bitcoin user/consumer level.

While the sentiment is appreciated, it seems important to gently push
back a bit, and remind:

This is a decentralized currency, and we should avoid centralizing
decisions.  This is something that impacts the community at large, and
deserves input and discussion at every level.

I would suggest posting on all possible forums "proposal: switch to
uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion
is generated.  If the support is broad, it will be plain from the
responses if there is a consensus.  Perhaps everyone will agree it is
the best course, and we can make an easy change.

But we need less "core dev fiat" not more :)

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2013-11-14 23:11             ` Mark Friedenbach
  2013-11-14 23:13               ` Luke-Jr
  2013-11-14 23:22               ` Jeff Garzik

  2013-11-15  0:18                 ` Mark Friedenbach
  
From: Luke-Jr @ 2013-11-15  0:15 UTC (permalink / raw)
  To: bitcoin-development

On Thursday, November 14, 2013 11:11:26 PM Mark Friedenbach wrote:
> On 11/14/13 3:01 PM, Luke-Jr wrote:
> > I think we all know the problems with the term "address". People
> > naturally compare it to postal addresses, email addresses, etc,
> > which operate fundamentally different. I suggest that we switch to
> > using "invoice id" to refer to what is now known as addresses, as
> > that seems to get the more natural understanding to people. On the
> > other hand, with the advent of the payment protocol, perhaps
> > address/invoice id use will die out soon?
> > 
> > Thoughts?
> 
> "key id" (thanks sipa).

To be clear, I wasn't suggesting renaming scriptPubKey, which sipa was talking 
about with "key id"; just the destination-for-transaction presented to
end-users.



 permalink raw reply	[|nested]
2013-11-15  0:15               ` Luke-Jr

  
From: Mark Friedenbach @ 2013-11-15  0:18 UTC (permalink / raw)
  To: Luke-Jr, bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/13 4:15 PM, Luke-Jr wrote:
> On Thursday, November 14, 2013 11:11:26 PM Mark Friedenbach wrote:
>> "key id" (thanks sipa).
> 
> To be clear, I wasn't suggesting renaming scriptPubKey, which sipa
> was talking about with "key id"; just the
> destination-for-transaction presented to end-users.

I was referencing a IRC conversation where sipa suggested "key id" as
a replacement for "address".

My only issue with "invoice" is possible confusion over the payment
protocol.

Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShWhlAAoJEAdzVfsmodw4SgUP/j52LdhCh/MZXrZNlKQhO57/
RO2Z9Ul2lL/uAB/7/lydxDmds6Ad12QT285fwYycvnKY31F2flBI3j+Er8EDZPCs
7O2eTWw9LD1DF45iBoU2PM1oXL+G1xsiNoyTKriLIH9n16sXr1/XvaeRa539gRhT
naM/r3AeW0mr6TZ/kh4/KRcFkkMsnyzrdFDwEpbpHlWPfz+QFQaJ6fI1rtgvD8xv
v7zlRBi7WhSdPQhE+SmK97hxRRTK0qW+qSOYd5zbh9gZXRcbI5ys0erikORUVBjR
/rMnKzK46uF8RYddXiMew/AdrFBb999MJsdI2Ci+HOezAzg5tyxf4IqKqk6FJcVK
TC1KebM/TpH3MpAqYLpRo24/SAelLLCIPD9S+afz5ME+pD5cuMZNAnyqY9vVPpCb
w9sEh5JksIVXXPugKM5ZW4VBjj/h6zOKD1fsjirgV0JzKKZm59JHSG9NL7XQhoSS
zFb1SxH8jueH+xAIE6mCUDWK1uDPUphJ6ZMs2fk3opBeDEevLspR2g+U2XSdtB4p
ymV+sbsph+rT02Gf6d588WXlQHbD5KTaLbyq6XqFHI3UIhjhVs0mAda/Ey6S+PMS
o/5Q10gX9NKPinqQU/WYHD2pgEwRFhCCqSuAbfWzz4v2fyvUT3v9o/aDxXlU/ogF
MVptUVrWXCJDUymG0mbq
=EclJ
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
2013-11-15  0:05   ` Jeff Garzik

  2013-11-15  0:46       ` Melvin Carvalho
  2013-11-15  0:57       ` Alan Reiner
  
From: Daniel F @ 2013-11-15  0:37 UTC (permalink / raw)
  To: Jeff Garzik, Bitcoin Dev

> This is a decentralized currency, and we should avoid centralizing
> decisions.  This is something that impacts the community at large, and
> deserves input and discussion at every level.
> 
> I would suggest posting on all possible forums "proposal: switch to
> uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion
> is generated.  If the support is broad, it will be plain from the
> responses if there is a consensus.  Perhaps everyone will agree it is
> the best course, and we can make an easy change.
> 
> But we need less "core dev fiat" not more :)
> 
this seems like such a paint-the-bikeshed problem that it's sure to
generate vast volumes of discussion, waste a lot of people's time, and
all for only a dubious (imo) gain. (case in point - here i am
contributing to it :) ).

i agree that we should avoid centralizing this. i'll go a step further
and note that the client already has a dropdown allowing individuals to
choose units. merchants are free to choose to price in different units.
exchanges are free to denominate trade in different units.

i suggest we just let the market do its thing and not get into trying to
'make a decision' of any sort.



 permalink raw reply	[|nested]
2013-11-15  0:37     ` Daniel F

  2013-11-15  0:57       ` Alan Reiner
  
From: Melvin Carvalho @ 2013-11-15  0:46 UTC (permalink / raw)
  To: Daniel F;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]

On 15 November 2013 01:37, Daniel F <nanotube@gmail•com> wrote:

> > This is a decentralized currency, and we should avoid centralizing
> > decisions.  This is something that impacts the community at large, and
> > deserves input and discussion at every level.
> >
> > I would suggest posting on all possible forums "proposal: switch to
> > uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion
> > is generated.  If the support is broad, it will be plain from the
> > responses if there is a consensus.  Perhaps everyone will agree it is
> > the best course, and we can make an easy change.
> >
> > But we need less "core dev fiat" not more :)
> >
> this seems like such a paint-the-bikeshed problem that it's sure to
> generate vast volumes of discussion, waste a lot of people's time, and
> all for only a dubious (imo) gain. (case in point - here i am
> contributing to it :) ).
>
> i agree that we should avoid centralizing this. i'll go a step further
> and note that the client already has a dropdown allowing individuals to
> choose units. merchants are free to choose to price in different units.
> exchanges are free to denominate trade in different units.
>
> i suggest we just let the market do its thing and not get into trying to
> 'make a decision' of any sort.
>

I do agree with you here

e.g. I think the question of the ISO code (XBT vs BTC) is probably out of
scope for this thread, and there was no clear consensus, when it came up on
the forums.

As a data point, the price of bitcoin has gone up roughly 1000x since
satoshi made his suggestion that the decimal point could move 3 places.

I dont think it's a question of centralization, I was just seeking opinion
on what people felt about the reference implementation.  How about just
changing the default value in the dropdown from BTC -> to mBTC

The the other clients and exchange choose whether they want to follow suit
or not

>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3670 bytes --]

 permalink raw reply	[|nested]
2013-11-15  0:37     ` Daniel F
  2013-11-15  0:46       ` Melvin Carvalho

  
From: Alan Reiner @ 2013-11-15  0:57 UTC (permalink / raw)
  To: bitcoin-development

I disagree.  There's a real perception and usability issue with the
current interface combined with the current price.  People are
intimidated by the current system, even though the price really reflects
Bitcoin starting to spread its wings (maybe prematurely, bubble-style,
but the price will have to get to this point eventually if Bitcoin will
thrive at the target scale). 

Bitcoin's learning curve is hard enough already.   As silly as it
sounds, feeling "insecure" because you only 0.00032 BTC, and then using
too many zeroes when paying for your smoothie are problems that can
really turn people off.  You say "Let the market sort it out". 
Sometimes the market needs direction and consistency.  Without us doing
anything, we just end up with fragmentation and confusion. 

I'd much prefer we reach a consensus on a path forward and push that
path hard.  Because there's always resistance to change, and confusion
along the way.  The easier and more consistent we can make it, the
smoother it will be.  We want to avoid:

"Hey, I'll sell it to you for 382 microbes." 
"What is a microbe?  Is that the same as a XBT?"
"I don't know, my wallet uses NBC."
"Well how much BTC is it? Okay, just send me 0.00038200 BTC"
"Four zeros after the decimal?"
"Yeah... oh wait you just sent me 10x"
...

Again it sounds silly, but this is a real usability issue.

On 11/14/2013 07:37 PM, Daniel F wrote:
>> This is a decentralized currency, and we should avoid centralizing
>> decisions.  This is something that impacts the community at large, and
>> deserves input and discussion at every level.
>>
>> I would suggest posting on all possible forums "proposal: switch to
>> uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion
>> is generated.  If the support is broad, it will be plain from the
>> responses if there is a consensus.  Perhaps everyone will agree it is
>> the best course, and we can make an easy change.
>>
>> But we need less "core dev fiat" not more :)
>>
> this seems like such a paint-the-bikeshed problem that it's sure to
> generate vast volumes of discussion, waste a lot of people's time, and
> all for only a dubious (imo) gain. (case in point - here i am
> contributing to it :) ).
>
> i agree that we should avoid centralizing this. i'll go a step further
> and note that the client already has a dropdown allowing individuals to
> choose units. merchants are free to choose to price in different units.
> exchanges are free to denominate trade in different units.
>
> i suggest we just let the market do its thing and not get into trying to
> 'make a decision' of any sort.
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 permalink raw reply	[|nested]
From: Tamas Blummer @ 2013-11-15  5:21 UTC ( / )
  To: bitcoin-development



Hi Jeff,

such a vote is up there since March:

https://bitcointalk.org/index.php?topic=149150.0

Votes are in favor of it.

Advantages are obvious:

1. having satoshi as 1/100 of the main unit is familiar to people like USD and cent
2. All existing financial software can deal/store big numbers but typically only 2 decimals.
3. Split could be linked with the introduction of the ISO code in one step.

Lets get it finally done.

On Thu, 14 Nov 2013 19:05:06 -0500 Jeff Garzik <jgarzik@bitpay•com> wrote:
> would suggest posting on all possible forums "proposal: switch to
>uBTC, labelled as ISO prefers (XBT?)" and see what sort of discussion
>is generated.  If the support is broad, it will be plain from the
>responses if there is a consensus.  Perhaps everyone will agree it is
>the best course, and we can make an easy change.
>
>But we need less "core dev fiat" not more :)
>
>-- 
>Jeff Garzik
>Senior Software Engineer and open source evangelist
>BitPay, Inc.      https://bitpay.com/

Regards,

Tamás Blummer
Founder, CEO
http://bitsofproof.com
2013-11-14 22:03     ` Jeff Garzik
  2013-11-14 22:31       ` Mark Friedenbach

  2013-11-18  2:28       ` Wendell
  
From: Wladimir @ 2013-11-15  7:18 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 4570 bytes --]

On Thu, Nov 14, 2013 at 11:03 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:

> Go straight to uBTC. Humans and existing computer systems handle numbers
> to the left of the decimals just fine (HK Dollars, Yen). The opposite is
> untrue (QuickBooks really does not like 3+ decimal places).
>
I have used mBTC for a long time and never had cope with more than two
numbers to the right of the decimal (which is the norm in euro countries).
Sure, if we have another 100x+ price increase then μBTC is a better pick,
but right now that would give us *intimidating large numbers*.

Though I have always liked the idea of moving to mBTC or μBTC, I want the
community to take initiative before switching over the default in the
reference client. The alternative units should first be sufficiently known
to the user base.

It has been possible for a long time to set the reference client to those
units (and all mentions of monetary value are accompanied with a unit).
Maybe we should stealthily collect people's settings and switch over once a
majority switched *ducks*.

Or, more seriously, maybe add a popup when upgrading the first time to 0.9
with an explanation where people can reconsider their unit setting?

Wladimir



>      - Jeff
> On Nov 14, 2013 4:40 PM, "Mark Friedenbach" <mark@monetize•io> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> For this reason I'm in favor of skipping mBTC and moving straight to
>> uBTC. Having eight, or even five decimal places is not intuitive to
>> the average user. Two decimal places is becoming standard for new
>> national currencies, and we wouldn't be too far from human scale
>> everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
>> many people on this list would consider bitcoin overvalued in the long
>> term perspective.
>>
>> Better to go through a confusing renumbering only once.
>>
>> Mark
>>
>> On 11/14/13 12:01 PM, Alan Reiner wrote:
>> > ... I'm also of the opinion that it's freakin' hard to change the
>> > base unit in such an established system.  There is no easy way to
>> > do this that doesn't cause more heartache than it's worth...
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBAgAGBQJShT2JAAoJEAdzVfsmodw4DXAQAIJTNbpwBGTXuFyaxXQULf20
>> hMs7OlQZSOZOdsmSiPv2augxzbpa2DhhZjiosrScSBCjxMeYd4S6WgTt/b8moAYR
>> HD8pm88JyCKDOd7bOmzTkgDOTBBFfH+islmOY9VTdeKGHeOHH6yyLMKwnUpa+S89
>> 4YtdzlIXAtfT37dpR5E4cHPmAYCbrRsNOB6j5ohVl2VqRou2vkwoJr/YvaW54M8i
>> ucIZyai2qjNWyJLcZC9QWi9Yw/W/n9QYE2mHyL0qWNaIrZVn6WGty8KpYq+i7aeU
>> 4N4UdtLT7FAhWYec9nmEec868WsUsd+H3/WSWViMinUKO4YA3cyxWDL7MTmTRsci
>> g0R4WGYCzMM3cEWz5ycf5KEBPH/nDlbqFmEartTffqKXgrK5Ohhw+28Iqw5KcDX8
>> SVx34lw2yHWmTeIMY8d3qYKqBdcsvixDUD3xvq+ZqEIa+bZw12s4LIzqmir84TB8
>> fB4bdq5GddXX0PK4pboXL+Nib0OVK72YgYnVs/ejlBmeiG8Ixoz4/ygR5MHm8jcw
>> tSiwH0xohOJWg3lJj0vZorubXoECcOqwPzsZkwnT9irbrvOuk2jCPvrkEC8U9fgA
>> XHgirStS49/lI/iUWrRchoTt5iuwG18G4+E81V/DMsrSkYlipuf2DlEXiapn3hWz
>> ccP053+6o5Rgpc7J1aa0
>> =QW1i
>> -----END PGP SIGNATURE-----
>>
>>
>> ------------------------------------------------------------------------------
>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>> Free app hosting. Or install the open source package on any LAMP server.
>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 6325 bytes --]

 permalink raw reply	[|nested]
2013-11-14 22:07         ` Allen Piscitello
  2013-11-14 23:01           ` Luke-Jr

  
From: Eugen Leitl @ 2013-11-15  8:55 UTC (permalink / raw)
  To: bitcoin-development

On Thu, Nov 14, 2013 at 04:07:58PM -0600, Allen Piscitello wrote:
> Obviously the answer is to just display all fees and trading rates as BTC
> or MBTC (.0000005 MBTC fee? how cheap!).  On a more serious note, the
> transition should definitely be thought out well as it could be very
> damaging to have this confusion, but I would prefer to do it only once
> rather than twice.

Why not just using SI prefixes, as God intended.

MBTC mega 10^6 
kBTC kilo 10^3
-    -    10^0
mBTC milli 10^-3 
uBTC micro 10^-6
nBTC nano  10^-9 (at all possible?)



 permalink raw reply	[|nested]
2013-11-14 22:53         ` Alan Reiner
  2013-11-14 23:01           ` Jeff Garzik
  2013-11-14 23:10           ` Luke-Jr

  2013-11-15  9:37             ` Alex Kravets
  
From: Eugen Leitl @ 2013-11-15  9:23 UTC (permalink / raw)
  To: bitcoin-development

On Thu, Nov 14, 2013 at 05:53:16PM -0500, Alan Reiner wrote:
> I really like the XBT idea.  It makes a lot of sense to match the ISO

I really don't. Just use the SI prefixes.

> currency symbol (though the ISO guys will have to adjust the way they've
> defined the "XBT").  And I do agree that going right to uBTC and
> skipping mBTC makes sense, too.

The display units should be choosable by the user. 
 
> I'd prefer them not be called "micro bitcoins."  I really want to call
> them "microbes" ... but I'm not sure that has the right flavor for money

Why on earth?

> transfer :)  "Please give me 872 microbes".  Perhaps we just call them
> "bits."  Or even "micros" or "microbits".  As I write this, I realize
> there's probably 872 threads on the forums about this already...
> 
> But we would want to promote a consistent term, to avoid further
> confusion when people use different names for the new unit.  It's not
> guaranteed to be successful, but if we pick a good name, and build it
> into the interface on the first release pushing the new unit, we have a
> chance to make the transition even easier.

The reason SI prefixes were invented is exactly to preven that case.



 permalink raw reply	[|nested]
2013-11-15  9:23           ` Eugen Leitl

  2013-11-15  9:59               ` Adam Back
  2013-11-15 10:39               ` Eugen Leitl
  
From: Alex Kravets @ 2013-11-15  9:37 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]

Hi guys,

I've seen many many non-geeks be utterly intimidated and confused by
0.000XXXXX quantities and/or mBTC & uBTC notation


Yes, $10 being rougnly 10,000 Won in South Korean is a great example where
large amounts of units work very well in a major economy.


FWIW,  I would prefer the entire switch-over be done *once* *and *at the
same time switching both BTC to XBT and using the following


Currency Code *: *XBT
Unit Definition  *: *1 Bit = 100 Satoshis

Addition benefit is splitting the term Bitcoin/bitcoin (as in Network and
currency unit) into Bitcoin (network) and Bit (the unit).


Perhaps this project/process should have a name and be listed on a road map
somewhere

*BRCS: *Bitcoin Re-denomination and [Currency] Code Standardization project


Cheers ...





On Fri, Nov 15, 2013 at 1:23 AM, Eugen Leitl <eugen@leitl•org> wrote:

> On Thu, Nov 14, 2013 at 05:53:16PM -0500, Alan Reiner wrote:
> > I really like the XBT idea.  It makes a lot of sense to match the ISO
>
> I really don't. Just use the SI prefixes.
>
> > currency symbol (though the ISO guys will have to adjust the way they've
> > defined the "XBT").  And I do agree that going right to uBTC and
> > skipping mBTC makes sense, too.
>
> The display units should be choosable by the user.
>
> > I'd prefer them not be called "micro bitcoins."  I really want to call
> > them "microbes" ... but I'm not sure that has the right flavor for money
>
> Why on earth?
>
> > transfer :)  "Please give me 872 microbes".  Perhaps we just call them
> > "bits."  Or even "micros" or "microbits".  As I write this, I realize
> > there's probably 872 threads on the forums about this already...
> >
> > But we would want to promote a consistent term, to avoid further
> > confusion when people use different names for the new unit.  It's not
> > guaranteed to be successful, but if we pick a good name, and build it
> > into the interface on the first release pushing the new unit, we have a
> > chance to make the transition even easier.
>
> The reason SI prefixes were invented is exactly to preven that case.
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Alex Kravets <http://www.linkedin.com/in/akravets>       def redPill = '
Scala <http://www.scala-lang.org/>
[[ brutal honesty <http://goo.gl/vwydt> is the best policy ]]

[-- Attachment #2: Type: text/html, Size: 4454 bytes --]

 permalink raw reply	[|nested]
2013-11-15  9:37             ` Alex Kravets

  2013-11-15 10:39               ` Eugen Leitl
  
From: Adam Back @ 2013-11-15  9:59 UTC (permalink / raw)
  To: Alex Kravets;  bitcoin-development

While we're discussing the emotive (though actually of real relevance for
bitcoin user comprehension and sentiment) I couldnt resisnt to add some
trivia reference it is amusing that a currency rarely in history had to
deflate (remove 0s) rather than inflate (add 0s).  Viz this hyperinflated
fifty trillion zimbabwe dollar note I carry in my wallet for bitcoin
contrast/amusement purposes:

http://www.ebay.com/itm/50-TRILLION-ZIMBABWE-DOLLARS-CURRENCY-MONEY-US-SELLER-/110671104681

I like Alan's suggestion to show both to avoid denomination confusion.  That
is the one danger, and high risk given irrevocability.

Adam



 permalink raw reply	[|nested]
2013-11-15  9:37             ` Alex Kravets
  2013-11-15  9:59               ` Adam Back

  
From: Eugen Leitl @ 2013-11-15 10:39 UTC (permalink / raw)
  To: bitcoin-development

On Fri, Nov 15, 2013 at 01:37:56AM -0800, Alex Kravets wrote:
> Hi guys,

Alex, you're top-posting and not trimming your replies.
 
> I've seen many many non-geeks be utterly intimidated and confused by
> 0.000XXXXX quantities and/or mBTC & uBTC notation

Yes, people really can't tell any difference between
mm, cm, m, dm and km. Not.
 
> 
> Yes, $10 being rougnly 10,000 Won in South Korean is a great example where
> large amounts of units work very well in a major economy.

You're trying to invent a new symbol for the same unit, instead
of using an established, generic system of prefixes.
That's pretty insane.
 
> 
> FWIW,  I would prefer the entire switch-over be done *once* *and *at the
> same time switching both BTC to XBT and using the following

I would prefer that nobody does any such silly thing. 
 
> 
> Currency Code *: *XBT
> Unit Definition  *: *1 Bit = 100 Satoshis
> 
> Addition benefit is splitting the term Bitcoin/bitcoin (as in Network and
> currency unit) into Bitcoin (network) and Bit (the unit).

Bitcoin is not measured in bits. Bits are units of information, and
are measured in bits, kbits, Mbits, Gbits, Tbits, Pbits etc.
http://en.wikipedia.org/wiki/Bit_rate
 
> 
> Perhaps this project/process should have a name and be listed on a road map
> somewhere

What would a sane person think if he saw that on the roadmap, you think?
 
> *BRCS: *Bitcoin Re-denomination and [Currency] Code Standardization project

Ever heard of SI unit prefixes?

http://en.wikipedia.org/wiki/Metric_prefix
 
> 
> Cheers ...
> 
> 
> 
> 
> 
> On Fri, Nov 15, 2013 at 1:23 AM, Eugen Leitl <eugen@leitl•org> wrote:
> 
> > On Thu, Nov 14, 2013 at 05:53:16PM -0500, Alan Reiner wrote:
> > > I really like the XBT idea.  It makes a lot of sense to match the ISO
> >
> > I really don't. Just use the SI prefixes.
> >
> > > currency symbol (though the ISO guys will have to adjust the way they've
> > > defined the "XBT").  And I do agree that going right to uBTC and
> > > skipping mBTC makes sense, too.
> >
> > The display units should be choosable by the user.
> >
> > > I'd prefer them not be called "micro bitcoins."  I really want to call
> > > them "microbes" ... but I'm not sure that has the right flavor for money
> >
> > Why on earth?
> >
> > > transfer :)  "Please give me 872 microbes".  Perhaps we just call them
> > > "bits."  Or even "micros" or "microbits".  As I write this, I realize
> > > there's probably 872 threads on the forums about this already...
> > >
> > > But we would want to promote a consistent term, to avoid further
> > > confusion when people use different names for the new unit.  It's not
> > > guaranteed to be successful, but if we pick a good name, and build it
> > > into the interface on the first release pushing the new unit, we have a
> > > chance to make the transition even easier.
> >
> > The reason SI prefixes were invented is exactly to preven that case.
> >
> >
> > ------------------------------------------------------------------------------
> > DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> > OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> > Free app hosting. Or install the open source package on any LAMP server.
> > Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> > http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> 
> 
> 
> -- 
> Alex Kravets <http://www.linkedin.com/in/akravets>       def redPill = '
> Scala <http://www.scala-lang.org/>
> [[ brutal honesty <http://goo.gl/vwydt> is the best policy ]]

> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk

> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 permalink raw reply	[|nested]
2013-11-14 20:01 ` Alan Reiner
  2013-11-14 21:15   ` Mark Friedenbach

  2013-11-15 10:57     ` Eugen Leitl
  
From: Wladimir @ 2013-11-15 10:45 UTC (permalink / raw)
  To: Alan Reiner;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

Alan,

 I highly recommend that if we make any move towards this, that the
> software show verification in both/all units.
>
> For instance, there should be 3 input fields, one for "BTC", one for
> "mBTC" one for "uBTC".  As the user enters a value in one of the fields, it
> would automatically update the other fields with the converted value as
> they type.  This makes it really difficult to get it wrong... if you're
> typing "10" into the BTC field, thinking it's mBTC, you'll see 10,000 mBTC
> showing up in the other box as you type.  Similarly, it should display all
> units on all verification windows.  Users may also use it for sanity
> checking conversion between units.
>

Good point - For me its too much clutter to show multiple boxes everywhere
(we already support unit conversion by changing the dropdown box in the
amount widget), but I'm going to make the verification dialog show the
totals in all three units. This will make people learn about other units
without having to choose them consciously.

Wladimir

[-- Attachment #2: Type: text/html, Size: 1482 bytes --]

 permalink raw reply	[|nested]
2013-11-15 10:45   ` Wladimir

  
From: Eugen Leitl @ 2013-11-15 10:57 UTC (permalink / raw)
  To: bitcoin-development

On Fri, Nov 15, 2013 at 11:45:41AM +0100, Wladimir wrote:

> Good point - For me its too much clutter to show multiple boxes everywhere
> (we already support unit conversion by changing the dropdown box in the
> amount widget), but I'm going to make the verification dialog show the
> totals in all three units. This will make people learn about other units
> without having to choose them consciously.

That sounds like a good idea.



 permalink raw reply	[|nested]
2013-11-14 23:01           ` Luke-Jr
  2013-11-14 23:11             ` Mark Friedenbach

  2013-11-16  0:48               ` Mark Friedenbach
  2013-11-16  1:10               ` Luke-Jr
  
From: Drak @ 2013-11-16  0:41 UTC (permalink / raw)
  To: Luke-Jr;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

On 14 November 2013 23:01, Luke-Jr <luke@dashjr•org> wrote:

> I wonder if it might make sense to bundle some other terminology fixups at
> the
> same time.
>

A very good idea.


> Right now, Bitcoin-Qt has been using the term "confirmations" (plural) to
> refer to how many blocks deep a transaction is buried. We also use the term
> "confirmation" to refer to the point where a transaction is accepted as
> paid.
> IMO, the latter use makes sense, but the former leads to confusion
> especially
> in light of scamcoins which abuse this confusion to claim they have "faster
> confirmations", implying that the actual confirmation occurs faster when it
> really doesn't. "5 blocks deep" may not be more clear to laymen, but at
> least
> it makes it harder for people to confuse with actual confirmation.
>

I think people are more familiar with check clearance - "the payment/check
has cleared".

If "confirmation" and "n confirmations" together are problematic, I'd talk
about "cleared payments" and "n confirmations"

So "a payment clears after one confirmation, but you might want to wait
until the payment has been confirmed n times".
Then at least you are not using the same word for two different meanings
and you're using stuff more familiar in popular lexicon.
I dont think it's helpful for users if we use the word "blocks".

Without the technical details, I just explain to normal bitcoin users that
the Bitcoin network checks and confirms the payment is valid (multiple
times).

I think we all know the problems with the term "address". People naturally
> compare it to postal addresses, email addresses, etc, which operate
> fundamentally different. I suggest that we switch to using "invoice id" to
> refer to what is now known as addresses, as that seems to get the more
> natural
> understanding to people. On the other hand, with the advent of the payment
> protocol, perhaps address/invoice id use will die out soon?
>

I think "key id" is a bit alien at user level - it's not something they are
used to.
For years, people had a problem with  "email address", instead using "email
number" but they got there eventually. Most people nowadays use "email
address"
So "payment address" or "bitcoin address" make better sense here when
qualified as a "<foo> address" and not just an "address"

You could also call it "payment id", but I dont think "invoice id" since
no-one pays to an invoice id that's just a reference for a payment, not the
destination.

People are very familiar with Paypal these days, and are familiar with
"paypal address" or their "paypal id" so again I think valid contenders are
"bitcoin address" or "bitcoin id".

Regards,

Drak

[-- Attachment #2: Type: text/html, Size: 4118 bytes --]

 permalink raw reply	[|nested]
2013-11-16  0:41             ` Drak

  2013-11-16  1:10               ` Luke-Jr
  
From: Mark Friedenbach @ 2013-11-16  0:48 UTC (permalink / raw)
  To: bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/15/13 4:41 PM, Drak wrote:
> For years, people had a problem with  "email address", instead
> using "email number" but they got there eventually. Most people
> nowadays use "email address" So "payment address" or "bitcoin
> address" make better sense here when qualified as a "<foo> address"
> and not just an "address"
> 
> You could also call it "payment id", but I dont think "invoice id"
> since no-one pays to an invoice id that's just a reference for a
> payment, not the destination.
> 
> People are very familiar with Paypal these days, and are familiar
> with "paypal address" or their "paypal id" so again I think valid
> contenders are "bitcoin address" or "bitcoin id".

No, no no. That's precisely the problem! Bitcoin pubkey-hashes are not
like email address, physical address, or paypal address. These latter
things are fixed pieces of information that stay constant over time.
Bitcoin keys, on the other hand, must be one-use-only. We want to
break this association, not strengthen it.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShsDqAAoJEAdzVfsmodw4e+UQAJBk3N7y/1ph8k6K/tPn2RB4
t0TiI46j0WuUghnCiDSOhQiL0EnUWUX8tCa6jH/3ASafBLKVey2LA7LeYoFZXpqJ
QEk5S7+eroA6uzzhViDTcoJJ7yH+ivd6dioVApirfnHVYiq6TZuTULhN/5zM6g1J
WehI9Rg2C7wj+I71yPJDeGAdtyOeX0iKQy3hN+q7+RIgeZC1viwsq81u6dzVjIZM
aPIk6S2VYHSUKhd7wSg+AprCV7jwftKhxDrW6R6KmOGYIG+JdqVnaErc5Wm7ujXk
Jnoh6UsQrcx9ck8I4sRTcbb5jGme1taN8RDcKifYqzTVQAr/ziVRqYY57fNAJMm2
lJZ0ctVD1+UB96DzQB4wCuWRoFF5+I9kD2hoEAXA4O9tqcou48lTQ25DAnkcusd+
dD0SfcRsgda8XqnWffGPYaW0E0dQuvu6elO+rzSh4DSCMkroKIvUwdak8Ah5M2lC
DyE/efwO9csImbTc1QukedkPskbOqPOo36sH5GdmObKKFCpORIzIO0aDQE1NM2Ib
rJurpU0iJ8eA+QT9lpyWG+jjahYpqyVhPcpfVsIewKhI0izBa352IYPbpCv/pdfM
oMO/tBfIwUW3jjav3zyFE47hAwistqfV4xds93K9rqpOmLtDIhSuzfmbuXwmciCM
d7/3rYQ6FxtyNkEUa27L
=5MWw
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
2013-11-16  0:41             ` Drak
  2013-11-16  0:48               ` Mark Friedenbach

  2013-11-16  1:19                 ` Jean-Paul Kogelman
  2013-11-16  1:19                 ` Drak
  
From: Luke-Jr @ 2013-11-16  1:10 UTC (permalink / raw)
  To: Drak;  Bitcoin Dev

On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
> So "a payment clears after one confirmation, but you might want to wait
> until the payment has been confirmed n times".
> Then at least you are not using the same word for two different meanings
> and you're using stuff more familiar in popular lexicon.
> I dont think it's helpful for users if we use the word "blocks".

"Confirmations" in a numeric context isn't correct, though. We're using to it 
because we've been using Bitcoin so long, but to the average person they would 
expect it to mean something more than it is. If not referring to blocks, then 
perhaps "witnessed N times"?

> For years, people had a problem with  "email address", instead using "email
> number" but they got there eventually. Most people nowadays use "email
> address"
> So "payment address" or "bitcoin address" make better sense here when
> qualified as a "<foo> address" and not just an "address"
> 
> You could also call it "payment id", but I dont think "invoice id" since
> no-one pays to an invoice id that's just a reference for a payment, not the
> destination.
> 
> People are very familiar with Paypal these days, and are familiar with
> "paypal address" or their "paypal id" so again I think valid contenders are
> "bitcoin address" or "bitcoin id".

I think you might be demonstrating my point with regard to user confusion 
here. Bitcoin addresses are *not* like email addresses, paypal ids, etc. 
Bitcoin addresses aren't the destination - they're point to a destination (an 
account in a wallet), but they also represent information such as who is 
paying and what for - in other words, a specific invoice.

Luke



 permalink raw reply	[|nested]
2013-11-16  1:10               ` Luke-Jr

  2013-11-16  1:19                 ` Drak
  
From: Jean-Paul Kogelman @ 2013-11-16  1:19 UTC (permalink / raw)
  To: Luke-Jr;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]



On Nov 15, 2013, at 05:10 PM, Luke-Jr <luke@dashjr•org> wrote:

On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
So "a payment clears after one confirmation, but you might want to wait
until the payment has been confirmed n times".
Then at least you are not using the same word for two different meanings
and you're using stuff more familiar in popular lexicon.
I dont think it's helpful for users if we use the word "blocks".

"Confirmations" in a numeric context isn't correct, though. We're using to it 
because we've been using Bitcoin so long, but to the average person they would 
expect it to mean something more than it is. If not referring to blocks, then 
perhaps "witnessed N times"?

Why not call it "Clearing" for transactions with < 6 confirmations and "Cleared" for >= 6?
 
The round ticker should be enough of an indication of the progress.



[-- Attachment #2.1: Type: text/html, Size: 1471 bytes --]

 permalink raw reply	[|nested]
2013-11-16  1:10               ` Luke-Jr
  2013-11-16  1:19                 ` Jean-Paul Kogelman

  2013-11-16  1:31                   ` Mark Friedenbach
  
From: Drak @ 2013-11-16  1:19 UTC (permalink / raw)
  To: Luke-Jr;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]

On 16 November 2013 01:10, Luke-Jr <luke@dashjr•org> wrote:

> On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
> > So "a payment clears after one confirmation, but you might want to wait
> > until the payment has been confirmed n times".
> > Then at least you are not using the same word for two different meanings
> > and you're using stuff more familiar in popular lexicon.
> > I dont think it's helpful for users if we use the word "blocks".
>
> "Confirmations" in a numeric context isn't correct, though. We're using to
> it
> because we've been using Bitcoin so long, but to the average person they
> would
> expect it to mean something more than it is. If not referring to blocks,
> then
> perhaps "witnessed N times"?


If you are talking about user interface, I don't think you have to be
technically correct. It must make sense to the user.
A user cares about his balance, and did a payment "go through", and "did my
payment arrive/clear".

The UI is for their benefit.


> > For years, people had a problem with  "email address", instead using
> "email
> > number" but they got there eventually. Most people nowadays use "email
> > address"
> > So "payment address" or "bitcoin address" make better sense here when
> > qualified as a "<foo> address" and not just an "address"
> >
> > You could also call it "payment id", but I dont think "invoice id" since
> > no-one pays to an invoice id that's just a reference for a payment, not
> the
> > destination.
> >
> > People are very familiar with Paypal these days, and are familiar with
> > "paypal address" or their "paypal id" so again I think valid contenders
> are
> > "bitcoin address" or "bitcoin id".
>
> I think you might be demonstrating my point with regard to user confusion
> here. Bitcoin addresses are *not* like email addresses, paypal ids, etc.
> Bitcoin addresses aren't the destination - they're point to a destination
> (an
> account in a wallet), but they also represent information such as who is
> paying and what for - in other words, a specific invoice.


Maybe, but again from the user's perspective they pay someone, and they
receive money - just like you do with paypal using an email address.
The technical bits in the middle dont matter to the user and trying to crap
stuff in to be technically correct is just confusing to them.

The UI needs to be about the user and fit with his experience of the world.

Drak

[-- Attachment #2: Type: text/html, Size: 3374 bytes --]

 permalink raw reply	[|nested]
2013-11-16  1:19                 ` Drak

  
From: Mark Friedenbach @ 2013-11-16  1:31 UTC (permalink / raw)
  To: bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/15/13 5:19 PM, Drak wrote:
> Maybe, but again from the user's perspective they pay someone, and
> they receive money - just like you do with paypal using an email
> address. The technical bits in the middle dont matter to the user
> and trying to crap stuff in to be technically correct is just
> confusing to them.
> 
> The UI needs to be about the user and fit with his experience of
> the world.

It's not about being technically correct. It is about protecting the
user from grave breaches of privacy. It is for their own benefit that
they should not be reusing addresses, and if they understood why they
wouldn't.

Unfortunately calling it a "bitcoin address" and including an "address
book" in the reference client has had the effect of making people
think that these objects are like paypal address, or email addresses,
but they are not and they should not be treated the same.

Mark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShsr4AAoJEAdzVfsmodw46nIP/AlDcJh2ET9qYT2ZvddciTk3
dtQDArCkwCW3kYbVjIFT8YtNFftEfkq/qBNnILipLJNN49QduAIlt3aetEE6eJBZ
oqYOV2R7GW2yhLDv/GrT6GnB1C9nQ4OuKC6RNpXX4bMpZSrbP9yfyyLqecF1tMBV
i8De4XLz1uUvZOo/jwHNeYy/BAZktwdk5hWlgG2yKebRbqVX1Xv70Qb1cPpBgCWm
uRDL3bqdZuh6i8NNDQpBqMJ/MP4ZWpIgdHkfO6a3QCq3H0JXyug4t5lkNngCrAI3
KGlSOuYK4Fsfw97xQUBFIaSYFOU+yPDRQK4UGcTqWPLt5YHzUxBFNkOXSnVReudq
Em/wlbDkPqm7R6by54fVkG85snJrwmTbD7uxGz2fe1LyzB3HhdOTZyZ1KiyDHqGA
zDUFxmH0XNhvVcJvcSFlc38A54oOHTJmfJ3rxJU/q0/5N3ZIBdF8fQ4xIvXXDeeA
dO+tul5q78tbO6xyTrbsHO8JRYt4Un8Hjc5mkdqp9gzA8beJFm5+jMZlGBfdl5jR
lS9sW7QBxr6m+n2PJ97i+1CgoxTfzOh3jyj93G6Hqx3reTfCu5fSWUhwRnFzJXav
qqPBP4Cl+6ocK7+4V1lyfAzMqpYx+GCJ1JZhD0hhwrGglgVPfE0bz7BUGea8U3+T
0pCTlkhWzEbzDp7NtFdY
=ShxL
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]
2013-11-14 18:18 ` Luke-Jr

  
From: Jacob Lyles @ 2013-11-17  3:22 UTC (permalink / raw)
  To: Luke-Jr;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

One of the strongest results from psychology is the power of defaults over
people's behavio<http://danariely.com/2008/05/05/3-main-lessons-of-psychology/>r.
Opt-in vs. opt-out national organ donation policies mean the difference
between organ donation rates under ~10% to over ~90%. Most people stick
with the default option.


On Thu, Nov 14, 2013 at 10:18 AM, Luke-Jr <luke@dashjr•org> wrote:

> On Thursday, November 14, 2013 11:45:51 AM Melvin Carvalho wrote:
> > Would now be a good time to start thinking about changing the default
> > display in the software.  Perhaps initially it could be a dropdown
> display
> > option, then at some point mbtc becomes the default?
>
> There's already a dropdown display option...
>
>
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2162 bytes --]

 permalink raw reply	[|nested]
2013-11-14 22:03     ` Jeff Garzik
  2013-11-14 22:31       ` Mark Friedenbach
  2013-11-15  7:18       ` Wladimir

  2014-03-13 12:56         ` Jeff Garzik
  
From: Wendell @ 2013-11-18  2:28 UTC (permalink / raw)
  To: Jeff Garzik;  bitcoin-development

We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved.

-wendell

grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411

On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:

> Go straight to uBTC. Humans and existing computer systems handle numbers to
> the left of the decimals just fine (HK Dollars, Yen). The opposite is
> untrue (QuickBooks really does not like 3+ decimal places).




 permalink raw reply	[|nested]
2013-11-18  2:28       ` Wendell

  2014-03-13 13:29           ` Gary Rowe
                             ` (2 more replies)
  
From: Jeff Garzik @ 2014-03-13 12:56 UTC (permalink / raw)
  To: Wendell;  Bitcoin Dev

Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
ago, which was disappointing -- it sounded like the consensus was
uBTC, and moving to uBTC later --which will happen-- may result in
additional user confusion, thanks to yet another decimal place
transition.



On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com> wrote:
> We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved.
>
> -wendell
>
> grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411
>
> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>
>> Go straight to uBTC. Humans and existing computer systems handle numbers to
>> the left of the decimals just fine (HK Dollars, Yen). The opposite is
>> untrue (QuickBooks really does not like 3+ decimal places).
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2014-03-13 12:56         ` Jeff Garzik

  2014-03-13 13:31             ` Mike Hearn
  2014-03-13 13:34           ` Wladimir
  2014-03-14 21:56           ` Odinn Cyberguerrilla
  
From: Gary Rowe @ 2014-03-13 13:29 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

The MultiBit HD view is that this is a locale-sensitive presentation issue.
As a result we offer a simple configuration panel giving pretty much every
possible combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
mXBT,  μXBT, sat along
with settings for leading/trailing symbol, commas, spaces and points. This
allows anyone to customise to meet their own needs beyond the offered
default.

We apply the NIST guidelines for representation of SI unit symbols (i.e no
conversion to native language, no RTL giving icon+m etc).

Right now MultiBit HD is configured to use m+icon taken from the Font
Awesome icon set. However reading earlier posts it seems that μ+icon is
more sensible.

Let us know what you'd like.

Links:
m+icon screenshot: http://imgur.com/a/WCDoG
Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/
NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html


On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com> wrote:

> Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
> ago, which was disappointing -- it sounded like the consensus was
> uBTC, and moving to uBTC later --which will happen-- may result in
> additional user confusion, thanks to yet another decimal place
> transition.
>
>
>
> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com> wrote:
> > We're with uBTC too. Been waiting for the signal to do this, let's do it
> right after the fee system is improved.
> >
> > -wendell
> >
> > grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411
> >
> > On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >
> >> Go straight to uBTC. Humans and existing computer systems handle
> numbers to
> >> the left of the decimals just fine (HK Dollars, Yen). The opposite is
> >> untrue (QuickBooks really does not like 3+ decimal places).
> >
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 4808 bytes --]

 permalink raw reply	[|nested]
2014-03-13 13:29           ` Gary Rowe

  2014-03-13 13:40               ` Andreas Schildbach
  2014-03-13 19:38               ` Jeff Garzik
  
From: Mike Hearn @ 2014-03-13 13:31 UTC (permalink / raw)
  To: Gary Rowe;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 3483 bytes --]

The standard has become mBTC and that's what was adopted. It's too late to
try and sway this on a mailing list thread now.


On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe <g.rowe@froot•co.uk> wrote:

> The MultiBit HD view is that this is a locale-sensitive presentation
> issue. As a result we offer a simple configuration panel giving pretty much
> every possible combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
> mXBT,  μXBT, sat along with settings for leading/trailing symbol, commas,
> spaces and points. This allows anyone to customise to meet their own needs
> beyond the offered default.
>
> We apply the NIST guidelines for representation of SI unit symbols (i.e no
> conversion to native language, no RTL giving icon+m etc).
>
> Right now MultiBit HD is configured to use m+icon taken from the Font
> Awesome icon set. However reading earlier posts it seems that μ+icon is
> more sensible.
>
> Let us know what you'd like.
>
> Links:
> m+icon screenshot: http://imgur.com/a/WCDoG
> Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/
> NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>
>
> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com> wrote:
>
>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
>> ago, which was disappointing -- it sounded like the consensus was
>> uBTC, and moving to uBTC later --which will happen-- may result in
>> additional user confusion, thanks to yet another decimal place
>> transition.
>>
>>
>>
>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com> wrote:
>> > We're with uBTC too. Been waiting for the signal to do this, let's do
>> it right after the fee system is improved.
>> >
>> > -wendell
>> >
>> > grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411
>> >
>> > On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>> >
>> >> Go straight to uBTC. Humans and existing computer systems handle
>> numbers to
>> >> the left of the decimals just fine (HK Dollars, Yen). The opposite is
>> >> untrue (QuickBooks really does not like 3+ decimal places).
>> >
>>
>>
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> 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@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 6269 bytes --]

 permalink raw reply	[|nested]
2014-03-13 12:56         ` Jeff Garzik
  2014-03-13 13:29           ` Gary Rowe

  2014-03-13 13:45             ` Jeff Garzik
  2014-03-14 21:56           ` Odinn Cyberguerrilla
  
From: Wladimir @ 2014-03-13 13:34 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev, Wendell

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:

> Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
> ago, which was disappointing -- it sounded like the consensus was
> uBTC, and moving to uBTC later --which will happen-- may result in
> additional user confusion, thanks to yet another decimal place
> transition.
>

I've kind of given up getting any consensus about this, or even getting
people to care.

Everyone agrees that a decimal shift would be good, but it's the same
boring shed painting discussion every time on how many decimals. In the end
nothing happens.

I can't really blame Andreas for finally taking action and making the
change to mBTC. People in the community are familiar with mBTC because some
exchanges and price sites used mBTC (at least for a while when >$1000),
also mBTC seems to be catching on on reddit etc.

Moving to muBTC (which in itself would be better because it is the final
unit change ever needed without hardfork) would require more coordinated
education effort.

Wladimir

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

 permalink raw reply	[|nested]
2014-03-13 13:31             ` Mike Hearn

  2014-03-14 14:05                 ` Andreas Schildbach
  2014-03-13 19:38               ` Jeff Garzik
  
From: Andreas Schildbach @ 2014-03-13 13:40 UTC (permalink / raw)
  To: bitcoin-development

Indeed. And users were crying for mBTC. Nobody was asking for µBTC.

I must admit I was not aware if this thread. I just watched other
wallets and at some point decided its time to switch to mBTC.


On 03/13/2014 02:31 PM, Mike Hearn wrote:
> The standard has become mBTC and that's what was adopted. It's too late
> to try and sway this on a mailing list thread now.
> 
> 
> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe <g.rowe@froot•co.uk
> <mailto:g.rowe@froot•co.uk>> wrote:
> 
>     The MultiBit HD view is that this is a locale-sensitive presentation
>     issue. As a result we offer a simple configuration panel giving
>     pretty much every possible combination: icon, m+icon,  μ+icon, BTC,
>     mBTC,  μBTC, XBT, mXBT,  μXBT, sat along with settings for
>     leading/trailing symbol, commas, spaces and points. This allows
>     anyone to customise to meet their own needs beyond the offered default. 
> 
>     We apply the NIST guidelines for representation of SI unit symbols
>     (i.e no conversion to native language, no RTL giving icon+m etc).
> 
>     Right now MultiBit HD is configured to use m+icon taken from the
>     Font Awesome icon set. However reading earlier posts it seems
>     that μ+icon is more sensible. 
> 
>     Let us know what you'd like.
> 
>     Links:
>     m+icon screenshot: http://imgur.com/a/WCDoG
>     Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/
>     NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> 
> 
>     On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
>     <mailto:jgarzik@bitpay•com>> wrote:
> 
>         Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
>         ago, which was disappointing -- it sounded like the consensus was
>         uBTC, and moving to uBTC later --which will happen-- may result in
>         additional user confusion, thanks to yet another decimal place
>         transition.
> 
> 
> 
>         On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com
>         <mailto:w@grabhive•com>> wrote:
>         > We're with uBTC too. Been waiting for the signal to do this,
>         let's do it right after the fee system is improved.
>         >
>         > -wendell
>         >
>         > grabhive.com <http://grabhive.com> | twitter.com/hivewallet
>         <http://twitter.com/hivewallet> | gpg: 6C0C9411
>         >
>         > On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>         >
>         >> Go straight to uBTC. Humans and existing computer systems
>         handle numbers to
>         >> the left of the decimals just fine (HK Dollars, Yen). The
>         opposite is
>         >> untrue (QuickBooks really does not like 3+ decimal places).
>         >
> 
> 
> 
>         --
>         Jeff Garzik
>         Bitcoin core developer and open source evangelist
>         BitPay, Inc.      https://bitpay.com/
> 
>         ------------------------------------------------------------------------------
>         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@lists•sourceforge.net
>         <mailto:Bitcoin-development@lists•sourceforge.net>
>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
>     ------------------------------------------------------------------------------
>     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@lists•sourceforge.net
>     <mailto:Bitcoin-development@lists•sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 





 permalink raw reply	[|nested]
2014-03-13 13:34           ` Wladimir

  2014-03-13 13:53               ` Mike Hearn
  2014-03-13 16:08               ` Troy Benjegerdes
  
From: Jeff Garzik @ 2014-03-13 13:45 UTC (permalink / raw)
  To: Wladimir;  Bitcoin Dev, Wendell

<vendor hat: on>

Based on this seeming consensus, BitPay was headed towards uBTC
internally, and hoped to coordinate messaging and rollout with others
in the community.  Ah well, proceed apace, and Bitcoin Wallet will
catch up, I suppose.

Multiple unit changes negatively impact users, but we are already there :/


On Thu, Mar 13, 2014 at 9:34 AM, Wladimir <laanwj@gmail•com> wrote:
>
> On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
>>
>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
>> ago, which was disappointing -- it sounded like the consensus was
>> uBTC, and moving to uBTC later --which will happen-- may result in
>> additional user confusion, thanks to yet another decimal place
>> transition.
>
>
> I've kind of given up getting any consensus about this, or even getting
> people to care.
>
> Everyone agrees that a decimal shift would be good, but it's the same boring
> shed painting discussion every time on how many decimals. In the end nothing
> happens.
>
> I can't really blame Andreas for finally taking action and making the change
> to mBTC. People in the community are familiar with mBTC because some
> exchanges and price sites used mBTC (at least for a while when >$1000), also
> mBTC seems to be catching on on reddit etc.
>
> Moving to muBTC (which in itself would be better because it is the final
> unit change ever needed without hardfork) would require more coordinated
> education effort.
>
> Wladimir



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2014-03-13 13:45             ` Jeff Garzik

  2014-03-13 14:32                 ` Jeff Garzik
  2014-03-13 16:08               ` Troy Benjegerdes
  
From: Mike Hearn @ 2014-03-13 13:53 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev, Wendell

[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]

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 about it. Getting from $1 to $1000 was amazing, but it was possible
through huge media coverage. Getting from $1000 to $1,000,000 would take
massive adoption of the kind Bitcoin isn't ready for yet.



On Thu, Mar 13, 2014 at 2:45 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:

> <vendor hat: on>
>
> Based on this seeming consensus, BitPay was headed towards uBTC
> internally, and hoped to coordinate messaging and rollout with others
> in the community.  Ah well, proceed apace, and Bitcoin Wallet will
> catch up, I suppose.
>
> Multiple unit changes negatively impact users, but we are already there :/
>
>
> On Thu, Mar 13, 2014 at 9:34 AM, Wladimir <laanwj@gmail•com> wrote:
> >
> > On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
> >>
> >> Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
> >> ago, which was disappointing -- it sounded like the consensus was
> >> uBTC, and moving to uBTC later --which will happen-- may result in
> >> additional user confusion, thanks to yet another decimal place
> >> transition.
> >
> >
> > I've kind of given up getting any consensus about this, or even getting
> > people to care.
> >
> > Everyone agrees that a decimal shift would be good, but it's the same
> boring
> > shed painting discussion every time on how many decimals. In the end
> nothing
> > happens.
> >
> > I can't really blame Andreas for finally taking action and making the
> change
> > to mBTC. People in the community are familiar with mBTC because some
> > exchanges and price sites used mBTC (at least for a while when >$1000),
> also
> > mBTC seems to be catching on on reddit etc.
> >
> > Moving to muBTC (which in itself would be better because it is the final
> > unit change ever needed without hardfork) would require more coordinated
> > education effort.
> >
> > Wladimir
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3944 bytes --]

 permalink raw reply	[|nested]
2014-03-13 13:53               ` Mike Hearn

  2014-03-13 15:50                   ` Mike Hearn
  2014-03-13 16:14                   ` Alan Reiner
  
From: Jeff Garzik @ 2014-03-13 14:32 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev, Wendell

On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn <mike@plan99•net> 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.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]


  2014-03-13 15:37   ` Chris Pacia
  
From: Tamas Blummer @ 2014-03-13 15:17 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

Jeff's arguments are understood and supported by those who worked in finance.

Existing financial applications have often problems dealing with more than 2 decimals.
People who work in finance are used to two decimals.

Neither systems nor people in finance have a problem with large numbers though.

For above practical reasons I am also for moving to a unit that equals 100 satoshi.
I heard the name bit for it which I like.

Regards,

Tamás Blummer
Founder, CEO
Bits of Proof
http://bitsofproof.com


[-- Attachment #2: Type: text/html, Size: 5047 bytes --]

 permalink raw reply	[|nested]
2014-03-13 15:17 ` Tamas Blummer

  
From: Chris Pacia @ 2014-03-13 15:37 UTC (permalink / raw)
  To: Tamas Blummer;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

I second the name 'bit' for μBTC.
On Mar 13, 2014 11:19 AM, "Tamas Blummer" <tamas@bitsofproof•com> wrote:

> Jeff's arguments are understood and supported by those who worked in
> finance.
>
> Existing financial applications have often problems dealing with more than
> 2 decimals.
> People who work in finance are used to two decimals.
>
> Neither systems nor people in finance have a problem with large numbers
> though.
>
> For above practical reasons I am also for moving to a unit that equals 100
> satoshi.
> I heard the name bit for it which I like.
>
> Regards,
>
> Tamás Blummer
> Founder, CEO
> Bits of Proof
> http://bitsofproof.com
>
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4589 bytes --]

 permalink raw reply	[|nested]
2014-03-13 14:32                 ` Jeff Garzik

  2014-03-13 16:17                     ` Troy Benjegerdes
  2014-03-13 16:39                     ` Melvin Carvalho
  2014-03-13 16:14                   ` Alan Reiner
  
From: Mike Hearn @ 2014-03-13 15:50 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev, Wendell

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2418 bytes --]

 permalink raw reply	[|nested]
2014-03-13 13:45             ` Jeff Garzik
  2014-03-13 13:53               ` Mike Hearn

  2014-03-13 16:30                 ` Tamas Blummer
                                   ` (2 more replies)
  
From: Troy Benjegerdes @ 2014-03-13 16:08 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev, Wendell

<cynic hat: on>

Every volatility bump messes up expectations of what a bitcoin is worth,
so why are we bikeshedding uBTC vs mBTC? Just be done with it and do mBTC
now, and plan uBTC for just after the next price spike to $10KUSD or whatever, 
and then plan on rolling back to mBTC when the price crashes from altcoin
money supply inflation competition.


On Thu, Mar 13, 2014 at 09:45:54AM -0400, Jeff Garzik wrote:
> <vendor hat: on>
> 
> Based on this seeming consensus, BitPay was headed towards uBTC
> internally, and hoped to coordinate messaging and rollout with others
> in the community.  Ah well, proceed apace, and Bitcoin Wallet will
> catch up, I suppose.
> 
> Multiple unit changes negatively impact users, but we are already there :/
> 
> 
> On Thu, Mar 13, 2014 at 9:34 AM, Wladimir <laanwj@gmail•com> wrote:
> >
> > On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
> >>
> >> Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
> >> ago, which was disappointing -- it sounded like the consensus was
> >> uBTC, and moving to uBTC later --which will happen-- may result in
> >> additional user confusion, thanks to yet another decimal place
> >> transition.
> >
> >
> > I've kind of given up getting any consensus about this, or even getting
> > people to care.
> >
> > Everyone agrees that a decimal shift would be good, but it's the same boring
> > shed painting discussion every time on how many decimals. In the end nothing
> > happens.
> >
> > I can't really blame Andreas for finally taking action and making the change
> > to mBTC. People in the community are familiar with mBTC because some
> > exchanges and price sites used mBTC (at least for a while when >$1000), also
> > mBTC seems to be catching on on reddit etc.
> >
> > Moving to muBTC (which in itself would be better because it is the final
> > unit change ever needed without hardfork) would require more coordinated
> > education effort.
> >
> > Wladimir
> 
> 
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed•org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash




 permalink raw reply	[|nested]
2014-03-13 14:32                 ` Jeff Garzik
  2014-03-13 15:50                   ` Mike Hearn

  2014-03-13 16:23                     ` Tamas Blummer
  2014-03-13 16:29                     ` Jeff Garzik
  
From: Alan Reiner @ 2014-03-13 16:14 UTC (permalink / raw)
  To: bitcoin-development

On 03/13/2014 10:32 AM, Jeff Garzik wrote:
> On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn <mike@plan99•net> 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.



 permalink raw reply	[|nested]
2014-03-13 15:50                   ` Mike Hearn

  2014-03-13 16:39                     ` Melvin Carvalho
  
From: Troy Benjegerdes @ 2014-03-13 16:17 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev, Wendell

On Thu, Mar 13, 2014 at 04:50:14PM +0100, Mike Hearn wrote:
> 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.

I think the ship of hand-wavy, data-free logic sailed with 
'money supply == 21 million', so why not enjoy the ride? If we care about
real people and real use cases, then let's talk about indexing the money 
supply to some blockchain-observable value and add demurrage instead of 
of bikeshedding the color of the latest coat of paint.

> 
> 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 :)

I'm surprised every time I pull up to a gas pump and the price is 3.249999
per gallon. But I don't really care what the price is, as long as there's 
an e85 pump. If I could pay at the pump with bitcoin, I wouldn't even look
at the price, I'd only care if my tank got filled up or if I have to drive
slower to get better mileage.

Hell, I'd have an app that would tell me what gas station to go to that got
me the best miles per bitcoin based on where I actually wanted to go.



 permalink raw reply	[|nested]
2014-03-13 16:14                   ` Alan Reiner

  2014-03-13 16:29                     ` Jeff Garzik
  
From: Tamas Blummer @ 2014-03-13 16:23 UTC (permalink / raw)
  To: Alan Reiner;  bitcoin-development


[-- Attachment #1.1: Type: text/plain, Size: 880 bytes --]


On 13.03.2014, at 17:14, Alan Reiner <etotheipi@gmail•com> wrote:

> 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.
> 

Not suprised that people dealing with real world finance problems 
and people who are not engineers come to the same conclusion. 
Welcome Alan!

Why not add 'bit' as an option or even default to Armory?

Regards,

Tamas Blummer
Founder, CEO
Bits of Proof
http://bitsofproof.com


[-- Attachment #1.2: Type: text/html, Size: 5557 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

 permalink raw reply	[|nested]
2014-03-13 16:14                   ` Alan Reiner
  2014-03-13 16:23                     ` Tamas Blummer

  2014-03-13 17:18                       ` Mark Friedenbach
  2014-03-13 19:26                       ` Drak
  
From: Jeff Garzik @ 2014-03-13 16:29 UTC (permalink / raw)
  To: Alan Reiner;  Bitcoin Dev

On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> 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.

mBTC now just means the issue -will- be revisited in the future.  Just
a question of when, not if.

People and software in various nations handle big numbers for small
values (e.g. Yen) just fine.
People and software do -not- handle extra decimal places well, field
experience shows.

<vendor hat: on>  To roll out QuickBooks support --without converting
any numbers, a key financial attribute-- mBTC is simply insufficient
today, not in the future.

I also argue that it is a security risk, as follows:  To support
accounting packages limited to 2 decimal places, decimal point
conversion must be performed.  This produces a situation where your
accounting system shows numbers that do not visually match the numbers
in the bitcoin software.  That, in turn, making auditing more
difficult, particularly for outsiders.

Shipping with mBTC defaults was decidedly unwise, considering that --
like BTC -- it fails to solve existing, known problems that uBTC can
solve, and considering the inevitable mBTC->uBTC switch.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2014-03-13 16:08               ` Troy Benjegerdes

  2014-03-13 16:37                   ` slush
  2014-03-13 18:23                 ` Jorge Timón
  2014-03-14  1:26                 ` Un Ix
  
From: Tamas Blummer @ 2014-03-13 16:30 UTC (permalink / raw)
  To: Troy Benjegerdes;  Bitcoin Dev, Wendell

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

BTW, its not like this would be the first time this was raised, instead the "ship left" while ignoring arguments.

The idea of is up there for votes since March 2013 https://bitcointalk.org/index.php?topic=149150.0
and received the most votes. 

I remembered this last time on this list here:

http://sourceforge.net/p/bitcoin/mailman/message/31640769/

Regards,

Tamas Blummer
Founder, CEO
Bits of Proof
http://bitsofproof.com


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

 permalink raw reply	[|nested]
2014-03-13 16:30                 ` Tamas Blummer

  2014-03-13 17:48                     ` Luke-Jr
  
From: slush @ 2014-03-13 16:37 UTC (permalink / raw)
  To: Tamas Blummer;  Wendell, Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

Internal accounting in satoshis.
Display based on locale.

Problem solved.


On Thu, Mar 13, 2014 at 5:30 PM, Tamas Blummer <tamas@bitsofproof•com>wrote:

> BTW, its not like this would be the first time this was raised, instead
> the "ship left" while ignoring arguments.
>
> The idea of is up there for votes since March 2013
> https://bitcointalk.org/index.php?topic=149150.0
> and received the most votes.
>
> I remembered this last time on this list here:
>
> http://sourceforge.net/p/bitcoin/mailman/message/31640769/
>
> Regards,
>
> Tamas Blummer
> Founder, CEO
> Bits of Proof
> http://bitsofproof.com
>
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 2135 bytes --]

 permalink raw reply	[|nested]
2014-03-13 15:50                   ` Mike Hearn
  2014-03-13 16:17                     ` Troy Benjegerdes

  2014-03-13 16:55                       ` Allen Piscitello
  
From: Melvin Carvalho @ 2014-03-13 16:39 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev, Wendell

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

On 13 March 2014 16:50, Mike Hearn <mike@plan99•net> wrote:

> 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.
>

+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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4608 bytes --]

 permalink raw reply	[|nested]
2014-03-13 16:39                     ` Melvin Carvalho

  2014-03-13 17:13                         ` Mike Hearn
  
From: Allen Piscitello @ 2014-03-13 16:55 UTC (permalink / raw)
  To: Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 5199 bytes --]

Mike is making an assumption that is not necessary, which is the price of
the most commonly used unit should be between is $.50 and $1000.  The issue
to revisit or not shouldn't require $1,000,000 Bitcoin price.  Typing a ton
of decimals is incredibly annoying.  Doing the mental math in my head is
annoying.  Even if a cup of coffee costs 3.12345 mBTC, that's a lot more
annoying than 3123.45 uBTC.

The points that people liked mBTC better than BTC doesn't mean anything
when comparing uBTC to mBTC.  Many people just stopped thinking at the mBTC
level, do not understand the implications involved in switching to uBTC, or
even considered uBTC.  The idea that we can just poll what people want to
give them the ideal experience is also flawed, in that users often don't
know what they want until they have it in front of them.

There is basically no downside to uBTC, except a few places already
switched to mBTC.  For exchanges, which are dealing with decimals since
they will do BTC/USD rather than the opposite, it might make sense for them
to continue to use mBTC or BTC.  For wallets and prices for users,
especially when there are large decimals since the price is still based on
more stable currencies, then converted to Bitcoin, let's switch to what is
easiest.

I haven't seen a single good argument for keeping it in mBTC (other than
some people already did it).  On the other hand, I've seen numerous great
reasons for switching to uBTC.

My two cents.


On Thu, Mar 13, 2014 at 11:39 AM, Melvin Carvalho
<melvincarvalho@gmail•com>wrote:

>
>
>
> On 13 March 2014 16:50, Mike Hearn <mike@plan99•net> wrote:
>
>> 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.
>>
>
> +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@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 7535 bytes --]

 permalink raw reply	[|nested]
2014-03-13 16:55                       ` Allen Piscitello

  2014-03-13 17:23                           ` Allen Piscitello
  
From: Mike Hearn @ 2014-03-13 17:13 UTC (permalink / raw)
  To: Allen Piscitello;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

>
> Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying
> than 3123.45 uBTC.
>

This is subjective though. To me the first price looks like the price of a
cup of coffee (or I just mentally double it). The second looks like the
price of an expensive holiday.

If users really find this so terrible, merchants have a simple solution: do
the rounding before presenting the price. Then the price looks like "3.12
mBTC" which is sort of what I'd expect it to look like. But some wallets
already make digits >2dp smaller so visually you can get precision whilst
still looking similar to what you might expect (this is what Bitcoin Wallet
does).


> I haven't seen a single good argument for keeping it in mBTC (other than
> some people already did it).
>

That's the good argument!

[-- Attachment #2: Type: text/html, Size: 1267 bytes --]

 permalink raw reply	[|nested]
2014-03-13 16:29                     ` Jeff Garzik

  2014-03-13 17:21                         ` Jeff Garzik
  2014-03-13 17:24                         ` Mike Hearn
  2014-03-13 19:26                       ` Drak
  
From: Mark Friedenbach @ 2014-03-13 17:18 UTC (permalink / raw)
  To: bitcoin-development

This ship may have already sailed, but...

Using milli- and micro- notation for currency units is also not very
well supported. Last time this thread was active, I believe there was a
suggestion to use 1 XBT == 1 uBTC. This would bring us completely within
the realm of supported behavior in accounting applications.

On 03/13/2014 09:29 AM, Jeff Garzik wrote:
> On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner <etotheipi@gmail•com> wrote:
>> 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.
> 
> mBTC now just means the issue -will- be revisited in the future.  Just
> a question of when, not if.
> 
> People and software in various nations handle big numbers for small
> values (e.g. Yen) just fine.
> People and software do -not- handle extra decimal places well, field
> experience shows.
> 
> <vendor hat: on>  To roll out QuickBooks support --without converting
> any numbers, a key financial attribute-- mBTC is simply insufficient
> today, not in the future.
> 
> I also argue that it is a security risk, as follows:  To support
> accounting packages limited to 2 decimal places, decimal point
> conversion must be performed.  This produces a situation where your
> accounting system shows numbers that do not visually match the numbers
> in the bitcoin software.  That, in turn, making auditing more
> difficult, particularly for outsiders.
> 
> Shipping with mBTC defaults was decidedly unwise, considering that --
> like BTC -- it fails to solve existing, known problems that uBTC can
> solve, and considering the inevitable mBTC->uBTC switch.
> 



 permalink raw reply	[|nested]
2014-03-13 17:18                       ` Mark Friedenbach

  2014-03-13 17:24                         ` Mike Hearn
  
From: Jeff Garzik @ 2014-03-13 17:21 UTC (permalink / raw)
  To: Mark Friedenbach;  Bitcoin Dev

On Thu, Mar 13, 2014 at 1:18 PM, Mark Friedenbach <mark@monetize•io> wrote:
> Using milli- and micro- notation for currency units is also not very
> well supported. Last time this thread was active, I believe there was a
> suggestion to use 1 XBT == 1 uBTC. This would bring us completely within
> the realm of supported behavior in accounting applications.

Yes.  That was in Tamas's recursive link, and also brought up on
github by jcorgan.  +1

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2014-03-13 17:13                         ` Mike Hearn

  
From: Allen Piscitello @ 2014-03-13 17:23 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

It certainly is not subjective, in that people are far more used to dealing
with whole numbers than decimals.  Try reading the first one, then reading
the second one.  Tell those numbers to someone else, have them write it
down, and see how many people screw up the first vs. the second.  This has
nothing to do with whether it "looks expensive".  There are reasons for
wanting the numbers to be higher as well, as evidenced by the number of
Dogecoin enthusiasts who like "having more", even if it doesn't matter.
 That part gets more subjective, but still favors micros in most cases.
 Sure, 3000 may sound like a lot, but if you have a lot more, it's all a
different scale.

If the argument is for keeping things based on what is already done, why
even switch to millis?  After all, everyone is used to full Bitcoins, why
even change to millis?  Whatever your arguments are there, for switching
base bitcoins to millis, try to see why they fail at micros (other than the
subjective argument that I'm used to decimal units of currency being worth
a cup of coffee, even though numerous people all over the world don't have
that conditioning).


On Thu, Mar 13, 2014 at 12:13 PM, Mike Hearn <mike@plan99•net> wrote:

> Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying
>> than 3123.45 uBTC.
>>
>
> This is subjective though. To me the first price looks like the price of a
> cup of coffee (or I just mentally double it). The second looks like the
> price of an expensive holiday.
>
> If users really find this so terrible, merchants have a simple solution:
> do the rounding before presenting the price. Then the price looks like
> "3.12 mBTC" which is sort of what I'd expect it to look like. But some
> wallets already make digits >2dp smaller so visually you can get precision
> whilst still looking similar to what you might expect (this is what Bitcoin
> Wallet does).
>
>
>> I haven't seen a single good argument for keeping it in mBTC (other than
>> some people already did it).
>>
>
> That's the good argument!
>

[-- Attachment #2: Type: text/html, Size: 2889 bytes --]

 permalink raw reply	[|nested]
2014-03-13 17:18                       ` Mark Friedenbach
  2014-03-13 17:21                         ` Jeff Garzik

  2014-03-13 17:36                           ` Alan Reiner
  
From: Mike Hearn @ 2014-03-13 17:24 UTC (permalink / raw)
  To: Mark Friedenbach;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

>
> Using milli- and micro- notation for currency units is also not very
> well supported. Last time this thread was active, I believe there was a
> suggestion to use 1 XBT == 1 uBTC.


Unfortunately I think some people already started using XBT to mean the
same as BTC (another ship that sailed: somehow Bhutan will have to live
with it). So if some software started to redefine it to mean something
else, that seems like a recipe for accidentally sending far too much or too
little money by mistake.

The whole area of symbols, denominations etc is a confusing mess right now,
it opens up the potential for mistakes and makes Bitcoin look
unprofessional. Part of the reason I don't want us to revisit this at the
moment is we need to grab onto any consistency we can get. People want to
think in terms of a single unit. BTC vs mBTC is already bad enough, it'd be
easy to miss the denomination and do some sums wrong. Introducing a third
unit, especially one that skips the intervening nanoBTC, seems like a way
to make mistakes even more common!

[-- Attachment #2: Type: text/html, Size: 1325 bytes --]

 permalink raw reply	[|nested]
2014-03-13 17:24                         ` Mike Hearn

  2014-03-13 17:43                             ` Wladimir
  2014-03-13 17:51                             ` Mike Hearn
  
From: Alan Reiner @ 2014-03-13 17:36 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]


On 03/13/2014 01:24 PM, Mike Hearn wrote:
>
>     Using milli- and micro- notation for currency units is also not very
>     well supported. Last time this thread was active, I believe there
>     was a
>     suggestion to use 1 XBT == 1 uBTC.
>
>
> Unfortunately I think some people already started using XBT to mean
> the same as BTC (another ship that sailed: somehow Bhutan will have to
> live with it). So if some software started to redefine it to mean
> something else, that seems like a recipe for accidentally sending far
> too much or too little money by mistake.
>

There is also the benefit that if someone screws up BTC and uBTC, it's
likely to fail.  Most people don't have 1e6 times as much money in their
wallet as they attempted to send in a single transaction.  Similarly,
sending one-millionth of what you meant to is likely invalid or below
the dust limit. 

Well it looks like the consensus is to do it, instead of talking about
it.  I'm going to make sure we get uBTC into the next Armory release. 

[-- Attachment #2: Type: text/html, Size: 1932 bytes --]

 permalink raw reply	[|nested]
2014-03-13 17:36                           ` Alan Reiner

  2014-03-13 17:51                             ` Mike Hearn
  
From: Wladimir @ 2014-03-13 17:43 UTC (permalink / raw)
  To: Alan Reiner;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

On Thu, Mar 13, 2014 at 6:36 PM, Alan Reiner <etotheipi@gmail•com> wrote:

>
> On 03/13/2014 01:24 PM, Mike Hearn wrote:
> Well it looks like the consensus is to do it, instead of talking about
> it.  I'm going to make sure we get uBTC into the next Armory release.
>

As default?

If so, only for new installs? Or will all current users automatically be
switched over?

Wladimir

[-- Attachment #2: Type: text/html, Size: 909 bytes --]

 permalink raw reply	[|nested]
2014-03-13 16:37                   ` slush

  
From: Luke-Jr @ 2014-03-13 17:48 UTC (permalink / raw)
  To: bitcoin-development;  Wendell

On Thursday, March 13, 2014 4:37:02 PM slush wrote:
> Display based on locale.

Please don't bring locale into this. Bitcoin has always been intentionally 
locale-independent (hence BTC using xxx,xxx,xxx.xx format even in locales 
which swap the commas and periods). Localising display makes different locales 
more or less incompatible at a human level, even if they use the same 
blockchain.

Luke



 permalink raw reply	[|nested]
2014-03-13 17:36                           ` Alan Reiner
  2014-03-13 17:43                             ` Wladimir

  2014-03-13 17:58                               ` Alan Reiner
  
From: Mike Hearn @ 2014-03-13 17:51 UTC (permalink / raw)
  To: Alan Reiner;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

>
> Well it looks like the consensus is to do it, instead of talking about
> it.  I'm going to make sure we get uBTC into the next Armory release.
>

Hmm - be careful with the word "consensus" here. A bunch of people on a
mailing list does not make consensus ;)

If you survey other wallets, you'll find most already switched to mBTC,
that it took some effort to do so (look at the size of the patches for
instance) and that probably, nobody is super-keen to change again so soon.
So uBTC would make you different to most of the other wallets and services
in wide usage.

If Armory wants to do that, that's no problem, maybe it will be a
competitive advantage - just saying, don't quote this thread as indicating
some kind of community consensus.

Wallets and services that are using mBTC (that I know of)

blockchain.info
MultiBit
Bitcoin Wallet (Android)
Hive
Bitcoinity
KnC Wallet (defaults to BTC but can be switched to mBTC in settings, uBTC
not an option)
Mullvad
btcstore.eu

Doing a google search for [bitcoin "mBTC"] and [bitcoin "uBTC"], the former
has a bunch of sites and services with prices in mBTC. The latter only has
faucets, as far as I can tell, which sort of makes sense.

[-- Attachment #2: Type: text/html, Size: 1778 bytes --]

 permalink raw reply	[|nested]
2014-03-13 17:51                             ` Mike Hearn

  
From: Alan Reiner @ 2014-03-13 17:58 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]



On 03/13/2014 01:51 PM, Mike Hearn wrote:
>
>     Well it looks like the consensus is to do it, instead of talking
>     about it.  I'm going to make sure we get uBTC into the next Armory
>     release.
>
>
> Hmm - be careful with the word "consensus" here. A bunch of people on
> a mailing list does not make consensus ;)
>
> If you survey other wallets, you'll find most already switched to
> mBTC, that it took some effort to do so (look at the size of the
> patches for instance) and that probably, nobody is super-keen to
> change again so soon. So uBTC would make you different to most of the
> other wallets and services in wide usage. 
>
> If Armory wants to do that, that's no problem, maybe it will be a
> competitive advantage - just saying, don't quote this thread as
> indicating some kind of community consensus.
>
> Wallets and services that are using mBTC (that I know of)
>
> blockchain.info <http://blockchain.info>
> MultiBit
> Bitcoin Wallet (Android)
> Hive
> Bitcoinity
> KnC Wallet (defaults to BTC but can be switched to mBTC in settings,
> uBTC not an option)
> Mullvad
> btcstore.eu <http://btcstore.eu>
>
> Doing a google search for [bitcoin "mBTC"] and [bitcoin "uBTC"], the
> former has a bunch of sites and services with prices in mBTC. The
> latter only has faucets, as far as I can tell, which sort of makes sense.

I actually was not aware that so many had already switched to mBTC.   I
guess it shows how much I use other wallets. 

You misunderstood my "consensus" comment.   I was simply stating the
"consensus" of debating on the mailing list endlessly is not as
effective as doing it.  Thus I was just going to do it and see who
follows.  But that also assumed there was not a critical mass who'd
already switched -- I must admit I'm not so confident anymore...

I am/so strongly opposed //to mBTC /compared to uBTC, I was ready to
take a small leap of faith (with associated risks), to help push the
"consensus".  Of course it would still remain configurable, but the
default will make a big difference.

-Alan

[-- Attachment #2: Type: text/html, Size: 3671 bytes --]

 permalink raw reply	[|nested]
2014-03-13 16:08               ` Troy Benjegerdes
  2014-03-13 16:30                 ` Tamas Blummer

  2014-03-13 18:29                   ` Mike Hearn
  2014-03-14  1:26                 ` Un Ix
  
From: Jorge Timón @ 2014-03-13 18:23 UTC (permalink / raw)
  To: Troy Benjegerdes;  Bitcoin Dev, Wendell

On 3/13/14, Troy Benjegerdes <hozer@hozed•org> wrote:
> <cynic hat: on>
>
> Every volatility bump messes up expectations of what a bitcoin is worth,
> so why are we bikeshedding uBTC vs mBTC? Just be done with it and do mBTC
> now, and plan uBTC for just after the next price spike to $10KUSD or
> whatever,
> and then plan on rolling back to mBTC when the price crashes from altcoin
> money supply inflation competition.

No, even if bitcoin crashes to 1 usd you don't need to change back to
BTC, you can keep the existing-accounting-tools friendly micro. That's
the whole point, having "one true only unit change". You would only
need to change it if there was a sub-satoshi hardfork, which doesn't
seem necessary anytime soon.

On 3/13/14, Mike Hearn <mike@plan99•net> wrote:
> 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 about it. Getting from $1 to $1000 was amazing, but it was possible
> through huge media coverage. Getting from $1000 to $1,000,000 would take
> massive adoption of the kind Bitcoin isn't ready for yet.

We shouldn't make any assumptions about the future price of bitcoin to
make the decision.

On 3/13/14, Mike Hearn <mike@plan99•net> wrote:
>>
>> Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying
>> than 3123.45 uBTC.
>>
>
> This is subjective though. To me the first price looks like the price of a
> cup of coffee (or I just mentally double it). The second looks like the
> price of an expensive holiday.

This sounds very US-centric to me. Aren't you thinking in usd?

It won't look like an expensive holiday to, say, someone used to Viet
Nam Dong (VND), Uzbekistani Som (UZS) or Mongolian Tugrik (MNT).

http://coinmill.com/BTC_calculator.html#BTC= 0.00312345


"People seem to like mBTC" is just an ad populum fallacy: millions of
flies can actually be wrong. Also you haven't showed them micros,
maybe they like it too.

So the only valid argument I've heard in favor of mBTC so far is "some
wallets/services are doing it wrong already".



 permalink raw reply	[|nested]
2014-03-13 18:23                 ` Jorge Timón

  2014-03-13 18:51                     ` Ben Davenport
  2014-03-14  0:34                     ` Jorge Timón
  
From: Mike Hearn @ 2014-03-13 18:29 UTC (permalink / raw)
  To: Jorge Timón;  Wendell, Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

>
> You would only need to change it if there was a sub-satoshi hardfork,
> which doesn't seem necessary anytime soon.
>

+

We shouldn't make any assumptions about the future price of bitcoin to make
> the decision.
>

Hmmm ;) Didn't you just make an assumption about the future price?


> This sounds very US-centric to me. Aren't you thinking in usd?
>

The currencies I'm familiar with are CHF, USD, EUR and GBP, which all have
roughly similar values. I guess such currencies make up the bulk of the
Bitcoin userbase at the moment.


> "People seem to like mBTC" is just an ad populum fallacy: millions of
> flies can actually be wrong. Also you haven't showed them micros,
> maybe they like it too.


Saying "it's already popular and would take work to change" is not really a
fallacy now, is it?

But anyway, this is getting silly. You don't have to convince me. Go visit
all the services I listed above, plus all the ones I didn't find in my five
minutes of searching, and convince them they're wrong like the flies and
switching is the best use of their time :o

[-- Attachment #2: Type: text/html, Size: 1892 bytes --]

 permalink raw reply	[|nested]
2014-03-13 18:29                   ` Mike Hearn

  2014-03-14  0:34                     ` Jorge Timón
  
From: Ben Davenport @ 2014-03-13 18:51 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev, Wendell

[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]

Another vote in support of uBTC. I made my position clear in May of last
year. Since then, Dogecoin has essentially PROVEN the psychological value
of a low-valued large-balance currency.

(From: https://bitcointalk.org/index.php?topic=220322.msg2334059#msg2334059)

"The whole unit change seems so disruptive and difficult to coordinate now
-- do we really want to have to deal with another one later when there are
way more people to try to coordinate? I really think we should look to the
endgame and figure out where we want to be.

"I'd propose moving to uB (micro-bitcoin = 1e-6) as the standard unit now
and forever. For now, it can be referred to as uB or uBTC, but over time,
once it's ubiquitous, it should just be called a bitcoin. Because the
smallest unit is the satoshi (1e-8), this means uB-denominated prices would
get 2 decimal places maximum, which is the most that any consumer wants to
deal with anyway.

"At the same time, I'd propose inverting the exchange rate, so instead of
quoting uB/USD = .00013, it would be quoted as USD/uB = 7692. This is
exactly the same way Yen are quoted relative to USD (USDJPY = 100.66), and
is also the same way other private virtual currencies such as WoW gold are
quoted."





On Thu, Mar 13, 2014 at 11:29 AM, Mike Hearn <mike@plan99•net> wrote:

> You would only need to change it if there was a sub-satoshi hardfork,
>> which doesn't seem necessary anytime soon.
>>
>
> +
>
> We shouldn't make any assumptions about the future price of bitcoin to
>> make the decision.
>>
>
> Hmmm ;) Didn't you just make an assumption about the future price?
>
>
>> This sounds very US-centric to me. Aren't you thinking in usd?
>>
>
> The currencies I'm familiar with are CHF, USD, EUR and GBP, which all have
> roughly similar values. I guess such currencies make up the bulk of the
> Bitcoin userbase at the moment.
>
>
>> "People seem to like mBTC" is just an ad populum fallacy: millions of
>> flies can actually be wrong. Also you haven't showed them micros,
>> maybe they like it too.
>
>
> Saying "it's already popular and would take work to change" is not really
> a fallacy now, is it?
>
> But anyway, this is getting silly. You don't have to convince me. Go visit
> all the services I listed above, plus all the ones I didn't find in my five
> minutes of searching, and convince them they're wrong like the flies and
> switching is the best use of their time :o
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 4660 bytes --]

 permalink raw reply	[|nested]
2014-03-13 16:29                     ` Jeff Garzik
  2014-03-13 17:18                       ` Mark Friedenbach

  
From: Drak @ 2014-03-13 19:26 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]

I agree with you Jeff. The unit switch needs to happen once and once only,
but that is exactly why I said the defaults really need to change in
Bitcoin-Qt since that is still the main reference implementation and it
will influence others.

Bitpay could also take the lead here and make the switch to their defaults.
That would greatly assist the uBTC movement.

Regardless of what anyone says, Bitcoin-Qt is still the main reference
implementation and the best way to encourage a change in the community at
large is for the default units to be changed here. Core devs can surely
garner enough consensus among themselves to accept and merge a PR to that
effect. That will send a message, more than anything else that can be done.

My two satoshi.

Drak


On 13 March 2014 16:29, Jeff Garzik <jgarzik@bitpay•com> wrote:

> On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> > 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.
>
> mBTC now just means the issue -will- be revisited in the future.  Just
> a question of when, not if.
>
> People and software in various nations handle big numbers for small
> values (e.g. Yen) just fine.
> People and software do -not- handle extra decimal places well, field
> experience shows.
>
> <vendor hat: on>  To roll out QuickBooks support --without converting
> any numbers, a key financial attribute-- mBTC is simply insufficient
> today, not in the future.
>
> I also argue that it is a security risk, as follows:  To support
> accounting packages limited to 2 decimal places, decimal point
> conversion must be performed.  This produces a situation where your
> accounting system shows numbers that do not visually match the numbers
> in the bitcoin software.  That, in turn, making auditing more
> difficult, particularly for outsiders.
>
> Shipping with mBTC defaults was decidedly unwise, considering that --
> like BTC -- it fails to solve existing, known problems that uBTC can
> solve, and considering the inevitable mBTC->uBTC switch.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3867 bytes --]

 permalink raw reply	[|nested]
2014-03-13 13:31             ` Mike Hearn
  2014-03-13 13:40               ` Andreas Schildbach

  
From: Jeff Garzik @ 2014-03-13 19:38 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev, Gary Rowe

On Thu, Mar 13, 2014 at 9:31 AM, Mike Hearn <mike@plan99•net> wrote:
> The standard has become mBTC and that's what was adopted. It's too late to
> try and sway this on a mailing list thread now.

Just saying that doesn't make it so, nor does it make it a good idea.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2014-03-13 18:29                   ` Mike Hearn
  2014-03-13 18:51                     ` Ben Davenport

  2014-03-14 17:14                       ` vv01f
  
From: Jorge Timón @ 2014-03-14  0:34 UTC (permalink / raw)
  To: Mike Hearn;  Wendell, Bitcoin Dev

On 3/13/14, Mike Hearn <mike@plan99•net> wrote:
>>
>> You would only need to change it if there was a sub-satoshi hardfork,
>> which doesn't seem necessary anytime soon.
>>
>
> +
>
> We shouldn't make any assumptions about the future price of bitcoin to make
>> the decision.
>>
>
> Hmmm ;) Didn't you just make an assumption about the future price?

You can just remove my assertion about the likeliness of the need of
sub-satoshis and the main claim still stands.

> The currencies I'm familiar with are CHF, USD, EUR and GBP, which all have
> roughly similar values. I guess such currencies make up the bulk of the
> Bitcoin userbase at the moment.

Fair enough, not US-centric but western-centric then.
In any case the "3000 micros will look like expensive" claim is still
very relative.

>> "People seem to like mBTC" is just an ad populum fallacy: millions of
>> flies can actually be wrong. Also you haven't showed them micros,
>> maybe they like it too.
>
>
> Saying "it's already popular and would take work to change" is not really a
> fallacy now, is it?

No, it's not. That's what I said the current adoption by some wallets
and services was the only valid argument immediately after dismantling
the actual fallacy.
Did you missed that last sentence or are you intentionally using a
straw man argument?

In summary, yes, that's point is valid, I'm not saying it isn't. I
just wanted to keep us away from the rest argument but pointing out
they are not logic.
I repeat, that's the ONLY valid argument I've heard so far.



 permalink raw reply	[|nested]
2014-03-13 16:08               ` Troy Benjegerdes
  2014-03-13 16:30                 ` Tamas Blummer
  2014-03-13 18:23                 ` Jorge Timón

  
From: Un Ix @ 2014-03-14  1:26 UTC (permalink / raw)
  To: Troy Benjegerdes;  Bitcoin Dev, Wendell

Second this comment.

A change like this so soon after mt gox debacle would be one more sign of bitcoins 'instability' for skeptics and average folk who read only headlines.

In general, it seems some people are looking to try and change the publics mental price of BTC which is more of a non-technical challenge. 

Gavin

> On 14/03/2014, at 12:21 am, "Troy Benjegerdes" <hozer@hozed•org> wrote:
> 
> <cynic hat: on>
> 
> Every volatility bump messes up expectations of what a bitcoin is worth,
> so why are we bikeshedding uBTC vs mBTC? Just be done with it and do mBTC
> now, and plan uBTC for just after the next price spike to $10KUSD or whatever, 
> and then plan on rolling back to mBTC when the price crashes from altcoin
> money supply inflation competition.
> 
> 
>> On Thu, Mar 13, 2014 at 09:45:54AM -0400, Jeff Garzik wrote:
>> <vendor hat: on>
>> 
>> Based on this seeming consensus, BitPay was headed towards uBTC
>> internally, and hoped to coordinate messaging and rollout with others
>> in the community.  Ah well, proceed apace, and Bitcoin Wallet will
>> catch up, I suppose.
>> 
>> Multiple unit changes negatively impact users, but we are already there :/
>> 
>> 
>>> On Thu, Mar 13, 2014 at 9:34 AM, Wladimir <laanwj@gmail•com> wrote:
>>> 
>>>> On Thu, Mar 13, 2014 at 1:56 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
>>>> 
>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
>>>> ago, which was disappointing -- it sounded like the consensus was
>>>> uBTC, and moving to uBTC later --which will happen-- may result in
>>>> additional user confusion, thanks to yet another decimal place
>>>> transition.
>>> 
>>> 
>>> I've kind of given up getting any consensus about this, or even getting
>>> people to care.
>>> 
>>> Everyone agrees that a decimal shift would be good, but it's the same boring
>>> shed painting discussion every time on how many decimals. In the end nothing
>>> happens.
>>> 
>>> I can't really blame Andreas for finally taking action and making the change
>>> to mBTC. People in the community are familiar with mBTC because some
>>> exchanges and price sites used mBTC (at least for a while when >$1000), also
>>> mBTC seems to be catching on on reddit etc.
>>> 
>>> Moving to muBTC (which in itself would be better because it is the final
>>> unit change ever needed without hardfork) would require more coordinated
>>> education effort.
>>> 
>>> Wladimir
>> 
>> 
>> 
>> -- 
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/
>> 
>> ------------------------------------------------------------------------------
>> 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@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> -- 
> ----------------------------------------------------------------------------
> Troy Benjegerdes                 'da hozer'                  hozer@hozed•org
> 7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop
> 
>      Never pick a fight with someone who buys ink by the barrel,
>         nor try buy a hacker who makes money by the megahash
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 permalink raw reply	[|nested]
2014-03-13 13:40               ` Andreas Schildbach

  2014-03-14 14:14                   ` Tamas Blummer
  2014-03-14 14:18                   ` Roy Badami
  
From: Andreas Schildbach @ 2014-03-14 14:05 UTC (permalink / raw)
  To: bitcoin-development

btw. None of Bitcoin Wallet's users complained about confusion because
of the mBTC switch. In contrast, I get many mails and questions if
exchange rates happen to differ by >10%.

I suspect nobody looks at the Bitcoin price. It's the amount in local
currency that matters to the users.


On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> Indeed. And users were crying for mBTC. Nobody was asking for µBTC.
> 
> I must admit I was not aware if this thread. I just watched other
> wallets and at some point decided its time to switch to mBTC.
> 
> 
> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>> The standard has become mBTC and that's what was adopted. It's too late
>> to try and sway this on a mailing list thread now.
>>
>>
>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe <g.rowe@froot•co.uk
>> <mailto:g.rowe@froot•co.uk>> wrote:
>>
>>     The MultiBit HD view is that this is a locale-sensitive presentation
>>     issue. As a result we offer a simple configuration panel giving
>>     pretty much every possible combination: icon, m+icon,  μ+icon, BTC,
>>     mBTC,  μBTC, XBT, mXBT,  μXBT, sat along with settings for
>>     leading/trailing symbol, commas, spaces and points. This allows
>>     anyone to customise to meet their own needs beyond the offered default. 
>>
>>     We apply the NIST guidelines for representation of SI unit symbols
>>     (i.e no conversion to native language, no RTL giving icon+m etc).
>>
>>     Right now MultiBit HD is configured to use m+icon taken from the
>>     Font Awesome icon set. However reading earlier posts it seems
>>     that μ+icon is more sensible. 
>>
>>     Let us know what you'd like.
>>
>>     Links:
>>     m+icon screenshot: http://imgur.com/a/WCDoG
>>     Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/
>>     NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>
>>
>>     On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
>>     <mailto:jgarzik@bitpay•com>> wrote:
>>
>>         Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
>>         ago, which was disappointing -- it sounded like the consensus was
>>         uBTC, and moving to uBTC later --which will happen-- may result in
>>         additional user confusion, thanks to yet another decimal place
>>         transition.
>>
>>
>>
>>         On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com
>>         <mailto:w@grabhive•com>> wrote:
>>         > We're with uBTC too. Been waiting for the signal to do this,
>>         let's do it right after the fee system is improved.
>>         >
>>         > -wendell
>>         >
>>         > grabhive.com <http://grabhive.com> | twitter.com/hivewallet
>>         <http://twitter.com/hivewallet> | gpg: 6C0C9411
>>         >
>>         > On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>>         >
>>         >> Go straight to uBTC. Humans and existing computer systems
>>         handle numbers to
>>         >> the left of the decimals just fine (HK Dollars, Yen). The
>>         opposite is
>>         >> untrue (QuickBooks really does not like 3+ decimal places).
>>         >
>>
>>
>>
>>         --
>>         Jeff Garzik
>>         Bitcoin core developer and open source evangelist
>>         BitPay, Inc.      https://bitpay.com/
>>
>>         ------------------------------------------------------------------------------
>>         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@lists•sourceforge.net
>>         <mailto:Bitcoin-development@lists•sourceforge.net>
>>         https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     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@lists•sourceforge.net
>>     <mailto:Bitcoin-development@lists•sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 





 permalink raw reply	[|nested]
2014-03-14 14:05                 ` Andreas Schildbach

  2014-03-14 14:49                     ` Andreas Schildbach
  2014-03-14 15:10                     ` Tyler
  2014-03-14 14:18                   ` Roy Badami
  
From: Tamas Blummer @ 2014-03-14 14:14 UTC (permalink / raw)
  To: Andreas Schildbach;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 7178 bytes --]

You give them a hard to interpret thing like mBTC and then wonder why
they rather look at local currency. Because the choices you gave them are bad.

I think Bitcoin would have a better chance to be percieved as a currency
of its own if it had prices and fractions like currencies do. 

3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be.


Tamas Blummer
Bits of Proof

On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de> wrote:

> btw. None of Bitcoin Wallet's users complained about confusion because
> of the mBTC switch. In contrast, I get many mails and questions if
> exchange rates happen to differ by >10%.
> 
> I suspect nobody looks at the Bitcoin price. It's the amount in local
> currency that matters to the users.
> 
> 
> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>> Indeed. And users were crying for mBTC. Nobody was asking for µBTC.
>> 
>> I must admit I was not aware if this thread. I just watched other
>> wallets and at some point decided its time to switch to mBTC.
>> 
>> 
>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>> The standard has become mBTC and that's what was adopted. It's too late
>>> to try and sway this on a mailing list thread now.
>>> 
>>> 
>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe <g.rowe@froot•co.uk
>>> <mailto:g.rowe@froot•co.uk>> wrote:
>>> 
>>>    The MultiBit HD view is that this is a locale-sensitive presentation
>>>    issue. As a result we offer a simple configuration panel giving
>>>    pretty much every possible combination: icon, m+icon,  μ+icon, BTC,
>>>    mBTC,  μBTC, XBT, mXBT,  μXBT, sat along with settings for
>>>    leading/trailing symbol, commas, spaces and points. This allows
>>>    anyone to customise to meet their own needs beyond the offered default. 
>>> 
>>>    We apply the NIST guidelines for representation of SI unit symbols
>>>    (i.e no conversion to native language, no RTL giving icon+m etc).
>>> 
>>>    Right now MultiBit HD is configured to use m+icon taken from the
>>>    Font Awesome icon set. However reading earlier posts it seems
>>>    that μ+icon is more sensible. 
>>> 
>>>    Let us know what you'd like.
>>> 
>>>    Links:
>>>    m+icon screenshot: http://imgur.com/a/WCDoG
>>>    Font Awesome icon: http://fortawesome.github.io/Font-Awesome/icon/btc/
>>>    NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>> 
>>> 
>>>    On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
>>>    <mailto:jgarzik@bitpay•com>> wrote:
>>> 
>>>        Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
>>>        ago, which was disappointing -- it sounded like the consensus was
>>>        uBTC, and moving to uBTC later --which will happen-- may result in
>>>        additional user confusion, thanks to yet another decimal place
>>>        transition.
>>> 
>>> 
>>> 
>>>        On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com
>>>        <mailto:w@grabhive•com>> wrote:
>>>> We're with uBTC too. Been waiting for the signal to do this,
>>>        let's do it right after the fee system is improved.
>>>> 
>>>> -wendell
>>>> 
>>>> grabhive.com <http://grabhive.com> | twitter.com/hivewallet
>>>        <http://twitter.com/hivewallet> | gpg: 6C0C9411
>>>> 
>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>>>> 
>>>>> Go straight to uBTC. Humans and existing computer systems
>>>        handle numbers to
>>>>> the left of the decimals just fine (HK Dollars, Yen). The
>>>        opposite is
>>>>> untrue (QuickBooks really does not like 3+ decimal places).
>>>> 
>>> 
>>> 
>>> 
>>>        --
>>>        Jeff Garzik
>>>        Bitcoin core developer and open source evangelist
>>>        BitPay, Inc.      https://bitpay.com/
>>> 
>>>        ------------------------------------------------------------------------------
>>>        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@lists•sourceforge.net
>>>        <mailto:Bitcoin-development@lists•sourceforge.net>
>>>        https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> 
>>> 
>>> 
>>>    ------------------------------------------------------------------------------
>>>    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@lists•sourceforge.net
>>>    <mailto:Bitcoin-development@lists•sourceforge.net>
>>>    https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 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@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

 permalink raw reply	[|nested]
2014-03-14 14:05                 ` Andreas Schildbach
  2014-03-14 14:14                   ` Tamas Blummer

  
From: Roy Badami @ 2014-03-14 14:18 UTC (permalink / raw)
  To: Andreas Schildbach;  bitcoin-development

On Fri, Mar 14, 2014 at 03:05:25PM +0100, Andreas Schildbach wrote:
> btw. None of Bitcoin Wallet's users complained about confusion because
> of the mBTC switch. In contrast, I get many mails and questions if
> exchange rates happen to differ by >10%.

At the moment, I imagine the vast majority of Bitcoin users are
familliar with SI units and know what milli- and micro- mean.

I doubt that is true of the general population, though.

roy



 permalink raw reply	[|nested]
2014-03-14 14:14                   ` Tamas Blummer

  2014-03-14 14:57                       ` Tamas Blummer
  2014-03-14 16:01                       ` Mark Friedenbach
  2014-03-14 15:10                     ` Tyler
  
From: Andreas Schildbach @ 2014-03-14 14:49 UTC (permalink / raw)
  To: bitcoin-development

How much do you pay for an Espresso in your local currency?

At least for the Euro and the Dollar, mBTC 3.56 is very close to what
people would expect. Certainly more familiar than µBTC 3558 or BTC
0.003578.

Anyway, I was just sharing real-world experience: nobody is confused.


On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> You give them a hard to interpret thing like mBTC and then wonder
> why they rather look at local currency. Because the choices you
> gave them are bad.
> 
> I think Bitcoin would have a better chance to be percieved as a
> currency of its own if it had prices and fractions like currencies
> do.
> 
> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> would be.
> 
> 
> Tamas Blummer Bits of Proof
> 
> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de>
> wrote:
> 
>> btw. None of Bitcoin Wallet's users complained about confusion
>> because of the mBTC switch. In contrast, I get many mails and
>> questions if exchange rates happen to differ by >10%.
>> 
>> I suspect nobody looks at the Bitcoin price. It's the amount in
>> local currency that matters to the users.
>> 
>> 
>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>> µBTC.
>>> 
>>> I must admit I was not aware if this thread. I just watched
>>> other wallets and at some point decided its time to switch to
>>> mBTC.
>>> 
>>> 
>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>> The standard has become mBTC and that's what was adopted.
>>>> It's too late to try and sway this on a mailing list thread
>>>> now.
>>>> 
>>>> 
>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>> wrote:
>>>> 
>>>> The MultiBit HD view is that this is a locale-sensitive
>>>> presentation issue. As a result we offer a simple
>>>> configuration panel giving pretty much every possible
>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
>>>> mXBT,  μXBT, sat along with settings for leading/trailing
>>>> symbol, commas, spaces and points. This allows anyone to
>>>> customise to meet their own needs beyond the offered default.
>>>> 
>>>> 
>>>> We apply the NIST guidelines for representation of SI unit
>>>> symbols (i.e no conversion to native language, no RTL giving
>>>> icon+m etc).
>>>> 
>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>> the Font Awesome icon set. However reading earlier posts it
>>>> seems that μ+icon is more sensible.
>>>> 
>>>> Let us know what you'd like.
>>>> 
>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>> Awesome icon:
>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>> 
>>>> 
>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com 
>>>> <mailto:jgarzik@bitpay•com>> wrote:
>>>> 
>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
>>>> several weeks ago, which was disappointing -- it sounded like
>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>> happen-- may result in additional user confusion, thanks to
>>>> yet another decimal place transition.
>>>> 
>>>> 
>>>> 
>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com 
>>>> <mailto:w@grabhive•com>> wrote:
>>>>> We're with uBTC too. Been waiting for the signal to do
>>>>> this,
>>>> let's do it right after the fee system is improved.
>>>>> 
>>>>> -wendell
>>>>> 
>>>>> grabhive.com <http://grabhive.com> |
>>>>> twitter.com/hivewallet
>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
>>>>> 
>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>>>>> 
>>>>>> Go straight to uBTC. Humans and existing computer
>>>>>> systems
>>>> handle numbers to
>>>>>> the left of the decimals just fine (HK Dollars, Yen).
>>>>>> The
>>>> opposite is
>>>>>> untrue (QuickBooks really does not like 3+ decimal
>>>>>> places).
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- Jeff Garzik Bitcoin core developer and open source
>>>> evangelist BitPay, Inc.      https://bitpay.com/
>>>> 
>>>> ------------------------------------------------------------------------------
>>>>
>>>> 
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@lists•sourceforge.net 
>>>> <mailto:Bitcoin-development@lists•sourceforge.net> 
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>>
>>>>
>>>> 
------------------------------------------------------------------------------
>>>> 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@lists•sourceforge.net 
>>>> <mailto:Bitcoin-development@lists•sourceforge.net> 
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 
------------------------------------------------------------------------------
>>>> 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@lists•sourceforge.net 
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>>
>>>
>>>> 
------------------------------------------------------------------------------
>>> 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@lists•sourceforge.net 
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>>
>>> 
------------------------------------------------------------------------------
>> 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@lists•sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
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@lists•sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 





 permalink raw reply	[|nested]
2014-03-14 14:49                     ` Andreas Schildbach

  2014-03-14 15:02                         ` Andreas Schildbach
  2014-03-14 16:01                       ` Mark Friedenbach
  
From: Tamas Blummer @ 2014-03-14 14:57 UTC (permalink / raw)
  To: Andreas Schildbach;  bitcoin-development


[-- Attachment #1.1: Type: text/plain, Size: 9441 bytes --]

you miss the point Andreas. It is not about the magnitude but about
the form of a price.

A number with no decimals or with two decimals is percieved as a
price in some currency. 

A number with more than two decimals is just not percieved as a price
but as a geeky something that you rather convert to local currency.

Tamas Blummer
Bits of Proof

On 14.03.2014, at 15:49, Andreas Schildbach <andreas@schildbach•de> wrote:

> How much do you pay for an Espresso in your local currency?
> 
> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> people would expect. Certainly more familiar than µBTC 3558 or BTC
> 0.003578.
> 
> Anyway, I was just sharing real-world experience: nobody is confused.
> 
> 
> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>> You give them a hard to interpret thing like mBTC and then wonder
>> why they rather look at local currency. Because the choices you
>> gave them are bad.
>> 
>> I think Bitcoin would have a better chance to be percieved as a
>> currency of its own if it had prices and fractions like currencies
>> do.
>> 
>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>> would be.
>> 
>> 
>> Tamas Blummer Bits of Proof
>> 
>> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de>
>> wrote:
>> 
>>> btw. None of Bitcoin Wallet's users complained about confusion
>>> because of the mBTC switch. In contrast, I get many mails and
>>> questions if exchange rates happen to differ by >10%.
>>> 
>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>>> local currency that matters to the users.
>>> 
>>> 
>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>>> µBTC.
>>>> 
>>>> I must admit I was not aware if this thread. I just watched
>>>> other wallets and at some point decided its time to switch to
>>>> mBTC.
>>>> 
>>>> 
>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>>> The standard has become mBTC and that's what was adopted.
>>>>> It's too late to try and sway this on a mailing list thread
>>>>> now.
>>>>> 
>>>>> 
>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>> wrote:
>>>>> 
>>>>> The MultiBit HD view is that this is a locale-sensitive
>>>>> presentation issue. As a result we offer a simple
>>>>> configuration panel giving pretty much every possible
>>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
>>>>> mXBT,  μXBT, sat along with settings for leading/trailing
>>>>> symbol, commas, spaces and points. This allows anyone to
>>>>> customise to meet their own needs beyond the offered default.
>>>>> 
>>>>> 
>>>>> We apply the NIST guidelines for representation of SI unit
>>>>> symbols (i.e no conversion to native language, no RTL giving
>>>>> icon+m etc).
>>>>> 
>>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>>> the Font Awesome icon set. However reading earlier posts it
>>>>> seems that μ+icon is more sensible.
>>>>> 
>>>>> Let us know what you'd like.
>>>>> 
>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>>> Awesome icon:
>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>>> 
>>>>> 
>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com 
>>>>> <mailto:jgarzik@bitpay•com>> wrote:
>>>>> 
>>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
>>>>> several weeks ago, which was disappointing -- it sounded like
>>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>>> happen-- may result in additional user confusion, thanks to
>>>>> yet another decimal place transition.
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com 
>>>>> <mailto:w@grabhive•com>> wrote:
>>>>>> We're with uBTC too. Been waiting for the signal to do
>>>>>> this,
>>>>> let's do it right after the fee system is improved.
>>>>>> 
>>>>>> -wendell
>>>>>> 
>>>>>> grabhive.com <http://grabhive.com> |
>>>>>> twitter.com/hivewallet
>>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
>>>>>> 
>>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>>>>>> 
>>>>>>> Go straight to uBTC. Humans and existing computer
>>>>>>> systems
>>>>> handle numbers to
>>>>>>> the left of the decimals just fine (HK Dollars, Yen).
>>>>>>> The
>>>>> opposite is
>>>>>>> untrue (QuickBooks really does not like 3+ decimal
>>>>>>> places).
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> -- Jeff Garzik Bitcoin core developer and open source
>>>>> evangelist BitPay, Inc.      https://bitpay.com/
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> 
>>>>> 
> 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@lists•sourceforge.net 
>>>>> <mailto:Bitcoin-development@lists•sourceforge.net> 
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
> ------------------------------------------------------------------------------
>>>>> 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@lists•sourceforge.net 
>>>>> <mailto:Bitcoin-development@lists•sourceforge.net> 
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
> ------------------------------------------------------------------------------
>>>>> 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@lists•sourceforge.net 
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> 
> ------------------------------------------------------------------------------
>>>> 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@lists•sourceforge.net 
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
> ------------------------------------------------------------------------------
>>> 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@lists•sourceforge.net 
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> 
> 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@lists•sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #1.2: Type: text/html, Size: 14621 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

 permalink raw reply	[|nested]
2014-03-14 14:57                       ` Tamas Blummer

  2014-03-14 15:12                           ` Tamas Blummer
  2014-03-14 15:32                           ` Mike Hearn
  
From: Andreas Schildbach @ 2014-03-14 15:02 UTC (permalink / raw)
  To: bitcoin-development

By that definition 3.56 is a price. Maybe I misunderstood you and you're
lobbying for mBTC?


On 03/14/2014 03:57 PM, Tamas Blummer wrote:
> you miss the point Andreas. It is not about the magnitude but about
> the form of a price.
> 
> A number with no decimals or with two decimals is percieved as a
> price in some currency. 
> 
> A number with more than two decimals is just not percieved as a price
> but as a geeky something that you rather convert to local currency.
> 
> Tamas Blummer
> Bits of Proof
> 
> On 14.03.2014, at 15:49, Andreas Schildbach <andreas@schildbach•de
> <mailto:andreas@schildbach•de>> wrote:
> 
>> How much do you pay for an Espresso in your local currency?
>>
>> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>> people would expect. Certainly more familiar than µBTC 3558 or BTC
>> 0.003578.
>>
>> Anyway, I was just sharing real-world experience: nobody is confused.
>>
>>
>> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>>> You give them a hard to interpret thing like mBTC and then wonder
>>> why they rather look at local currency. Because the choices you
>>> gave them are bad.
>>>
>>> I think Bitcoin would have a better chance to be percieved as a
>>> currency of its own if it had prices and fractions like currencies
>>> do.
>>>
>>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>>> would be.
>>>
>>>
>>> Tamas Blummer Bits of Proof
>>>
>>> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de
>>> <mailto:andreas@schildbach•de>>
>>> wrote:
>>>
>>>> btw. None of Bitcoin Wallet's users complained about confusion
>>>> because of the mBTC switch. In contrast, I get many mails and
>>>> questions if exchange rates happen to differ by >10%.
>>>>
>>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>>>> local currency that matters to the users.
>>>>
>>>>
>>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>>>> µBTC.
>>>>>
>>>>> I must admit I was not aware if this thread. I just watched
>>>>> other wallets and at some point decided its time to switch to
>>>>> mBTC.
>>>>>
>>>>>
>>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>>>> The standard has become mBTC and that's what was adopted.
>>>>>> It's too late to try and sway this on a mailing list thread
>>>>>> now.
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>
>>>>>> <mailto:g.rowe@froot•co.uk>> wrote:
>>>>>>
>>>>>> The MultiBit HD view is that this is a locale-sensitive
>>>>>> presentation issue. As a result we offer a simple
>>>>>> configuration panel giving pretty much every possible
>>>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
>>>>>> mXBT,  μXBT, sat along with settings for leading/trailing
>>>>>> symbol, commas, spaces and points. This allows anyone to
>>>>>> customise to meet their own needs beyond the offered default.
>>>>>>
>>>>>>
>>>>>> We apply the NIST guidelines for representation of SI unit
>>>>>> symbols (i.e no conversion to native language, no RTL giving
>>>>>> icon+m etc).
>>>>>>
>>>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>>>> the Font Awesome icon set. However reading earlier posts it
>>>>>> seems that μ+icon is more sensible.
>>>>>>
>>>>>> Let us know what you'd like.
>>>>>>
>>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>>>> Awesome icon:
>>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>>>>
>>>>>>
>>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
>>>>>> <mailto:jgarzik@bitpay•com>
>>>>>> <mailto:jgarzik@bitpay•com>> wrote:
>>>>>>
>>>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
>>>>>> several weeks ago, which was disappointing -- it sounded like
>>>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>>>> happen-- may result in additional user confusion, thanks to
>>>>>> yet another decimal place transition.





 permalink raw reply	[|nested]
2014-03-14 14:14                   ` Tamas Blummer
  2014-03-14 14:49                     ` Andreas Schildbach

  
From: Tyler @ 2014-03-14 15:10 UTC (permalink / raw)
  To: Tamas Blummer, bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 10104 bytes --]

>You give them a hard to interpret thing like mBTC and then wonder why
>they rather look at local currency. Because the choices you gave them are
bad.

I don't think this is particularly true. The options people are given are
all good in this case and all have their merits. The reason people are
converting to fiat using the exchange rates is because right now the
exchanges define its value. People have no intuitive idea that a loaf of
bread cost X BTC. This isn't going to change anytime soon.

In my opinion it doesn't really matter what denomination you use.  If we
switched to micro we would have 3 extra digits we would be working with on
a daily basis which have very little significance. But thats just a western
point of view and people could adapt.

The real problems are that millibitcoin and microbitcoin are hard to say
loud and the both start with 'm' not too many people have a mu key on their
keyboard. Even Bitcoin is not nice to say. it has two very hard sounds
together in the middle of the word.

It would be far easier if we had a system like one ham is 1000 bits, one
bacon is 1000 hams.

Clearly a ridiculous example but try saying and you'll realize how much
easier it is to describe things not that they are clearly differentiable
words that are easy to say.

I like bits as the lowest one. But its not something you can decide. The
common names will have to develop naturally and in all likelihood will
differ between regions (I know I know we must keep it standardized but what
might be easy to say in North America probably isn't as easy elsewhere.)

So give people the options (Let them transact on their own terms). I would
say restrict it to BTC milli and micro in the settings that will help nudge
people towards even different regions simply having different names for the
same quantity as opposed to some place having 10 hams as a pixie.


On 14 March 2014 10:14, Tamas Blummer <tamas@bitsofproof•com> wrote:

> You give them a hard to interpret thing like mBTC and then wonder why
> they rather look at local currency. Because the choices you gave them are
> bad.
>
> I think Bitcoin would have a better chance to be percieved as a currency
> of its own if it had prices and fractions like currencies do.
>
> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits would be.
>
>
> Tamas Blummer
> Bits of Proof
>
> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de> wrote:
>
> > btw. None of Bitcoin Wallet's users complained about confusion because
> > of the mBTC switch. In contrast, I get many mails and questions if
> > exchange rates happen to differ by >10%.
> >
> > I suspect nobody looks at the Bitcoin price. It's the amount in local
> > currency that matters to the users.
> >
> >
> > On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> >> Indeed. And users were crying for mBTC. Nobody was asking for µBTC.
> >>
> >> I must admit I was not aware if this thread. I just watched other
> >> wallets and at some point decided its time to switch to mBTC.
> >>
> >>
> >> On 03/13/2014 02:31 PM, Mike Hearn wrote:
> >>> The standard has become mBTC and that's what was adopted. It's too late
> >>> to try and sway this on a mailing list thread now.
> >>>
> >>>
> >>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe <g.rowe@froot•co.uk
> >>> <mailto:g.rowe@froot•co.uk>> wrote:
> >>>
> >>>    The MultiBit HD view is that this is a locale-sensitive presentation
> >>>    issue. As a result we offer a simple configuration panel giving
> >>>    pretty much every possible combination: icon, m+icon,  μ+icon, BTC,
> >>>    mBTC,  μBTC, XBT, mXBT,  μXBT, sat along with settings for
> >>>    leading/trailing symbol, commas, spaces and points. This allows
> >>>    anyone to customise to meet their own needs beyond the offered
> default.
> >>>
> >>>    We apply the NIST guidelines for representation of SI unit symbols
> >>>    (i.e no conversion to native language, no RTL giving icon+m etc).
> >>>
> >>>    Right now MultiBit HD is configured to use m+icon taken from the
> >>>    Font Awesome icon set. However reading earlier posts it seems
> >>>    that μ+icon is more sensible.
> >>>
> >>>    Let us know what you'd like.
> >>>
> >>>    Links:
> >>>    m+icon screenshot: http://imgur.com/a/WCDoG
> >>>    Font Awesome icon:
> http://fortawesome.github.io/Font-Awesome/icon/btc/
> >>>    NIST SI guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> >>>
> >>>
> >>>    On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
> >>>    <mailto:jgarzik@bitpay•com>> wrote:
> >>>
> >>>        Resurrecting this topic.  Bitcoin Wallet moved to mBTC several
> weeks
> >>>        ago, which was disappointing -- it sounded like the consensus
> was
> >>>        uBTC, and moving to uBTC later --which will happen-- may result
> in
> >>>        additional user confusion, thanks to yet another decimal place
> >>>        transition.
> >>>
> >>>
> >>>
> >>>        On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com
> >>>        <mailto:w@grabhive•com>> wrote:
> >>>> We're with uBTC too. Been waiting for the signal to do this,
> >>>        let's do it right after the fee system is improved.
> >>>>
> >>>> -wendell
> >>>>
> >>>> grabhive.com <http://grabhive.com> | twitter.com/hivewallet
> >>>        <http://twitter.com/hivewallet> | gpg: 6C0C9411
> >>>>
> >>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >>>>
> >>>>> Go straight to uBTC. Humans and existing computer systems
> >>>        handle numbers to
> >>>>> the left of the decimals just fine (HK Dollars, Yen). The
> >>>        opposite is
> >>>>> untrue (QuickBooks really does not like 3+ decimal places).
> >>>>
> >>>
> >>>
> >>>
> >>>        --
> >>>        Jeff Garzik
> >>>        Bitcoin core developer and open source evangelist
> >>>        BitPay, Inc.      https://bitpay.com/
> >>>
> >>>
>  ------------------------------------------------------------------------------
> >>>        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@lists•sourceforge.net
> >>>        <mailto:Bitcoin-development@lists•sourceforge.net>
> >>>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>>
> >>>
> >>>
>  ------------------------------------------------------------------------------
> >>>    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@lists•sourceforge.net
> >>>    <mailto:Bitcoin-development@lists•sourceforge.net>
> >>>    https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>>
> >>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> 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@lists•sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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@lists•sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
Tyler Jackson

[-- Attachment #2: Type: text/html, Size: 15413 bytes --]

 permalink raw reply	[|nested]
2014-03-14 15:02                         ` Andreas Schildbach

  2014-03-14 15:30                             ` Andreas Schildbach
  2014-03-14 15:32                           ` Mike Hearn
  
From: Tamas Blummer @ 2014-03-14 15:12 UTC (permalink / raw)
  To: Andreas Schildbach;  bitcoin-development


[-- Attachment #1.1: Type: text/plain, Size: 5463 bytes --]

I think you want to misunderstand me Andreas.

It is astonishing arrogance to define the units because we in Bitcoin are used to
some wierd notation and ignore that the vast majority of population and 
 financial software in existence does not have a notion of prices
with more than two decimals.

With 1 bit = 100 satoshi, we would solve this problem for good. 
Instead mBTC is a confusing step in-between.

Tamas Blummer
http://bitsofproof.com

On 14.03.2014, at 16:02, Andreas Schildbach <andreas@schildbach•de> wrote:

> By that definition 3.56 is a price. Maybe I misunderstood you and you're
> lobbying for mBTC?
> 
> 
> On 03/14/2014 03:57 PM, Tamas Blummer wrote:
>> you miss the point Andreas. It is not about the magnitude but about
>> the form of a price.
>> 
>> A number with no decimals or with two decimals is percieved as a
>> price in some currency. 
>> 
>> A number with more than two decimals is just not percieved as a price
>> but as a geeky something that you rather convert to local currency.
>> 
>> Tamas Blummer
>> Bits of Proof
>> 
>> On 14.03.2014, at 15:49, Andreas Schildbach <andreas@schildbach•de
>> <mailto:andreas@schildbach•de>> wrote:
>> 
>>> How much do you pay for an Espresso in your local currency?
>>> 
>>> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>>> people would expect. Certainly more familiar than µBTC 3558 or BTC
>>> 0.003578.
>>> 
>>> Anyway, I was just sharing real-world experience: nobody is confused.
>>> 
>>> 
>>> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>>>> You give them a hard to interpret thing like mBTC and then wonder
>>>> why they rather look at local currency. Because the choices you
>>>> gave them are bad.
>>>> 
>>>> I think Bitcoin would have a better chance to be percieved as a
>>>> currency of its own if it had prices and fractions like currencies
>>>> do.
>>>> 
>>>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>>>> would be.
>>>> 
>>>> 
>>>> Tamas Blummer Bits of Proof
>>>> 
>>>> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de
>>>> <mailto:andreas@schildbach•de>>
>>>> wrote:
>>>> 
>>>>> btw. None of Bitcoin Wallet's users complained about confusion
>>>>> because of the mBTC switch. In contrast, I get many mails and
>>>>> questions if exchange rates happen to differ by >10%.
>>>>> 
>>>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>>>>> local currency that matters to the users.
>>>>> 
>>>>> 
>>>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>>>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>>>>> µBTC.
>>>>>> 
>>>>>> I must admit I was not aware if this thread. I just watched
>>>>>> other wallets and at some point decided its time to switch to
>>>>>> mBTC.
>>>>>> 
>>>>>> 
>>>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>>>>> The standard has become mBTC and that's what was adopted.
>>>>>>> It's too late to try and sway this on a mailing list thread
>>>>>>> now.
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>
>>>>>>> <mailto:g.rowe@froot•co.uk>> wrote:
>>>>>>> 
>>>>>>> The MultiBit HD view is that this is a locale-sensitive
>>>>>>> presentation issue. As a result we offer a simple
>>>>>>> configuration panel giving pretty much every possible
>>>>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
>>>>>>> mXBT,  μXBT, sat along with settings for leading/trailing
>>>>>>> symbol, commas, spaces and points. This allows anyone to
>>>>>>> customise to meet their own needs beyond the offered default.
>>>>>>> 
>>>>>>> 
>>>>>>> We apply the NIST guidelines for representation of SI unit
>>>>>>> symbols (i.e no conversion to native language, no RTL giving
>>>>>>> icon+m etc).
>>>>>>> 
>>>>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>>>>> the Font Awesome icon set. However reading earlier posts it
>>>>>>> seems that μ+icon is more sensible.
>>>>>>> 
>>>>>>> Let us know what you'd like.
>>>>>>> 
>>>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>>>>> Awesome icon:
>>>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>>>>> 
>>>>>>> 
>>>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
>>>>>>> <mailto:jgarzik@bitpay•com>
>>>>>>> <mailto:jgarzik@bitpay•com>> wrote:
>>>>>>> 
>>>>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
>>>>>>> several weeks ago, which was disappointing -- it sounded like
>>>>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>>>>> happen-- may result in additional user confusion, thanks to
>>>>>>> yet another decimal place transition.
> 
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #1.2: Type: text/html, Size: 8370 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

 permalink raw reply	[|nested]
2014-03-14 15:12                           ` Tamas Blummer

  
From: Andreas Schildbach @ 2014-03-14 15:30 UTC (permalink / raw)
  To: bitcoin-development

I don't know about financial software.

I really don't get what you mean by weird notation? Bitcoin Wallet is
made for ordinary users. They are used to real-world prices like EUR
1.63 / USD 2.26 (that would be the Espresso example). How can mBTC 3.56
be weird to these people?

Granted, there are exceptions, like in Japan. Maybe those would be
better served with µBTC as default. Maybe. Up to now, outside of this
mailing list nobody requested µBTC. Then again, Japanese userbase is
tiny compared to US.


On 03/14/2014 04:12 PM, Tamas Blummer wrote:
> I think you want to misunderstand me Andreas.
> 
> It is astonishing arrogance to define the units because we in Bitcoin
> are used to
> some wierd notation and ignore that the vast majority of population and 
>  financial software in existence does not have a notion of prices
> with more than two decimals.
> 
> With 1 bit = 100 satoshi, we would solve this problem for good. 
> Instead mBTC is a confusing step in-between.
> 
> Tamas Blummer
> http://bitsofproof.com
> 
> On 14.03.2014, at 16:02, Andreas Schildbach <andreas@schildbach•de
> <mailto:andreas@schildbach•de>> wrote:
> 
>> By that definition 3.56 is a price. Maybe I misunderstood you and you're
>> lobbying for mBTC?
>>
>>
>> On 03/14/2014 03:57 PM, Tamas Blummer wrote:
>>> you miss the point Andreas. It is not about the magnitude but about
>>> the form of a price.
>>>
>>> A number with no decimals or with two decimals is percieved as a
>>> price in some currency.
>>>
>>> A number with more than two decimals is just not percieved as a price
>>> but as a geeky something that you rather convert to local currency.
>>>
>>> Tamas Blummer
>>> Bits of Proof
>>>
>>> On 14.03.2014, at 15:49, Andreas Schildbach <andreas@schildbach•de
>>> <mailto:andreas@schildbach•de>
>>> <mailto:andreas@schildbach•de>> wrote:
>>>
>>>> How much do you pay for an Espresso in your local currency?
>>>>
>>>> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>>>> people would expect. Certainly more familiar than µBTC 3558 or BTC
>>>> 0.003578.
>>>>
>>>> Anyway, I was just sharing real-world experience: nobody is confused.
>>>>
>>>>
>>>> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>>>>> You give them a hard to interpret thing like mBTC and then wonder
>>>>> why they rather look at local currency. Because the choices you
>>>>> gave them are bad.
>>>>>
>>>>> I think Bitcoin would have a better chance to be percieved as a
>>>>> currency of its own if it had prices and fractions like currencies
>>>>> do.
>>>>>
>>>>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>>>>> would be.
>>>>>
>>>>>
>>>>> Tamas Blummer Bits of Proof
>>>>>
>>>>> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de
>>>>> <mailto:andreas@schildbach•de>
>>>>> <mailto:andreas@schildbach•de>>
>>>>> wrote:
>>>>>
>>>>>> btw. None of Bitcoin Wallet's users complained about confusion
>>>>>> because of the mBTC switch. In contrast, I get many mails and
>>>>>> questions if exchange rates happen to differ by >10%.
>>>>>>
>>>>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>>>>>> local currency that matters to the users.
>>>>>>
>>>>>>
>>>>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>>>>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>>>>>> µBTC.
>>>>>>>
>>>>>>> I must admit I was not aware if this thread. I just watched
>>>>>>> other wallets and at some point decided its time to switch to
>>>>>>> mBTC.
>>>>>>>
>>>>>>>
>>>>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>>>>>> The standard has become mBTC and that's what was adopted.
>>>>>>>> It's too late to try and sway this on a mailing list thread
>>>>>>>> now.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>>>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>
>>>>>>>> <mailto:g.rowe@froot•co.uk>
>>>>>>>> <mailto:g.rowe@froot•co.uk>> wrote:
>>>>>>>>
>>>>>>>> The MultiBit HD view is that this is a locale-sensitive
>>>>>>>> presentation issue. As a result we offer a simple
>>>>>>>> configuration panel giving pretty much every possible
>>>>>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
>>>>>>>> mXBT,  μXBT, sat along with settings for leading/trailing
>>>>>>>> symbol, commas, spaces and points. This allows anyone to
>>>>>>>> customise to meet their own needs beyond the offered default.
>>>>>>>>
>>>>>>>>
>>>>>>>> We apply the NIST guidelines for representation of SI unit
>>>>>>>> symbols (i.e no conversion to native language, no RTL giving
>>>>>>>> icon+m etc).
>>>>>>>>
>>>>>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>>>>>> the Font Awesome icon set. However reading earlier posts it
>>>>>>>> seems that μ+icon is more sensible.
>>>>>>>>
>>>>>>>> Let us know what you'd like.
>>>>>>>>
>>>>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>>>>>> Awesome icon:
>>>>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
>>>>>>>> <mailto:jgarzik@bitpay•com>
>>>>>>>> <mailto:jgarzik@bitpay•com>
>>>>>>>> <mailto:jgarzik@bitpay•com>> wrote:
>>>>>>>>
>>>>>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
>>>>>>>> several weeks ago, which was disappointing -- it sounded like
>>>>>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>>>>>> happen-- may result in additional user confusion, thanks to
>>>>>>>> yet another decimal place transition.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 





 permalink raw reply	[|nested]
2014-03-14 15:02                         ` Andreas Schildbach
  2014-03-14 15:12                           ` Tamas Blummer

  2014-03-14 15:56                             ` Andreas Schildbach
  
From: Mike Hearn @ 2014-03-14 15:32 UTC (permalink / raw)
  To: Andreas Schildbach;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 5883 bytes --]

The issue here is that most people are producing prices in BTC by just
multiplying through the spot rate with full precision. Obviously if you
converted dollar prices to Euro prices with the same technique, you'd also
end up with lots of numbers after the decimal point, but in the real world
nobody actually does this. They always "prettify" the price.

This practice often annoys people because they feel like they get short
changed. The most notorious example is Apple which likes (liked?) to charge
99 cents per iTunes song in the USA, and 99 pennies per song in the UK,
despite that the British pound is worth a lot more than the dollar. It
should be more like 60 pence.

Nothing stops BitPay rounding the mBTC price to look more natural, but
right now it's not common practice.


On Fri, Mar 14, 2014 at 4:02 PM, Andreas Schildbach
<andreas@schildbach•de>wrote:

> By that definition 3.56 is a price. Maybe I misunderstood you and you're
> lobbying for mBTC?
>
>
> On 03/14/2014 03:57 PM, Tamas Blummer wrote:
> > you miss the point Andreas. It is not about the magnitude but about
> > the form of a price.
> >
> > A number with no decimals or with two decimals is percieved as a
> > price in some currency.
> >
> > A number with more than two decimals is just not percieved as a price
> > but as a geeky something that you rather convert to local currency.
> >
> > Tamas Blummer
> > Bits of Proof
> >
> > On 14.03.2014, at 15:49, Andreas Schildbach <andreas@schildbach•de
> > <mailto:andreas@schildbach•de>> wrote:
> >
> >> How much do you pay for an Espresso in your local currency?
> >>
> >> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> >> people would expect. Certainly more familiar than µBTC 3558 or BTC
> >> 0.003578.
> >>
> >> Anyway, I was just sharing real-world experience: nobody is confused.
> >>
> >>
> >> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> >>> You give them a hard to interpret thing like mBTC and then wonder
> >>> why they rather look at local currency. Because the choices you
> >>> gave them are bad.
> >>>
> >>> I think Bitcoin would have a better chance to be percieved as a
> >>> currency of its own if it had prices and fractions like currencies
> >>> do.
> >>>
> >>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> >>> would be.
> >>>
> >>>
> >>> Tamas Blummer Bits of Proof
> >>>
> >>> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de
> >>> <mailto:andreas@schildbach•de>>
> >>> wrote:
> >>>
> >>>> btw. None of Bitcoin Wallet's users complained about confusion
> >>>> because of the mBTC switch. In contrast, I get many mails and
> >>>> questions if exchange rates happen to differ by >10%.
> >>>>
> >>>> I suspect nobody looks at the Bitcoin price. It's the amount in
> >>>> local currency that matters to the users.
> >>>>
> >>>>
> >>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> >>>>> Indeed. And users were crying for mBTC. Nobody was asking for
> >>>>> µBTC.
> >>>>>
> >>>>> I must admit I was not aware if this thread. I just watched
> >>>>> other wallets and at some point decided its time to switch to
> >>>>> mBTC.
> >>>>>
> >>>>>
> >>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
> >>>>>> The standard has become mBTC and that's what was adopted.
> >>>>>> It's too late to try and sway this on a mailing list thread
> >>>>>> now.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
> >>>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>
> >>>>>> <mailto:g.rowe@froot•co.uk>> wrote:
> >>>>>>
> >>>>>> The MultiBit HD view is that this is a locale-sensitive
> >>>>>> presentation issue. As a result we offer a simple
> >>>>>> configuration panel giving pretty much every possible
> >>>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
> >>>>>> mXBT,  μXBT, sat along with settings for leading/trailing
> >>>>>> symbol, commas, spaces and points. This allows anyone to
> >>>>>> customise to meet their own needs beyond the offered default.
> >>>>>>
> >>>>>>
> >>>>>> We apply the NIST guidelines for representation of SI unit
> >>>>>> symbols (i.e no conversion to native language, no RTL giving
> >>>>>> icon+m etc).
> >>>>>>
> >>>>>> Right now MultiBit HD is configured to use m+icon taken from
> >>>>>> the Font Awesome icon set. However reading earlier posts it
> >>>>>> seems that μ+icon is more sensible.
> >>>>>>
> >>>>>> Let us know what you'd like.
> >>>>>>
> >>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
> >>>>>> Awesome icon:
> >>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
> >>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> >>>>>>
> >>>>>>
> >>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
> >>>>>> <mailto:jgarzik@bitpay•com>
> >>>>>> <mailto:jgarzik@bitpay•com>> wrote:
> >>>>>>
> >>>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
> >>>>>> several weeks ago, which was disappointing -- it sounded like
> >>>>>> the consensus was uBTC, and moving to uBTC later --which will
> >>>>>> happen-- may result in additional user confusion, thanks to
> >>>>>> yet another decimal place transition.
>
>
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 8851 bytes --]

 permalink raw reply	[|nested]
2014-03-14 15:32                           ` Mike Hearn

  
From: Andreas Schildbach @ 2014-03-14 15:56 UTC (permalink / raw)
  To: bitcoin-development

Indeed, rounding is the obvious easy fix. Bitcoin Wallet rounds all
amounts except if you type amounts with a higher precision.


On 03/14/2014 04:32 PM, Mike Hearn wrote:
> The issue here is that most people are producing prices in BTC by just
> multiplying through the spot rate with full precision. Obviously if you
> converted dollar prices to Euro prices with the same technique, you'd
> also end up with lots of numbers after the decimal point, but in the
> real world nobody actually does this. They always "prettify" the price.
> 
> This practice often annoys people because they feel like they get short
> changed. The most notorious example is Apple which likes (liked?) to
> charge 99 cents per iTunes song in the USA, and 99 pennies per song in
> the UK, despite that the British pound is worth a lot more than the
> dollar. It should be more like 60 pence.
> 
> Nothing stops BitPay rounding the mBTC price to look more natural, but
> right now it's not common practice.
> 
> 
> On Fri, Mar 14, 2014 at 4:02 PM, Andreas Schildbach
> <andreas@schildbach•de <mailto:andreas@schildbach•de>> wrote:
> 
>     By that definition 3.56 is a price. Maybe I misunderstood you and you're
>     lobbying for mBTC?
> 
> 
>     On 03/14/2014 03:57 PM, Tamas Blummer wrote:
>     > you miss the point Andreas. It is not about the magnitude but about
>     > the form of a price.
>     >
>     > A number with no decimals or with two decimals is percieved as a
>     > price in some currency.
>     >
>     > A number with more than two decimals is just not percieved as a price
>     > but as a geeky something that you rather convert to local currency.
>     >
>     > Tamas Blummer
>     > Bits of Proof
>     >
>     > On 14.03.2014, at 15:49, Andreas Schildbach <andreas@schildbach•de
>     <mailto:andreas@schildbach•de>
>     > <mailto:andreas@schildbach•de <mailto:andreas@schildbach•de>>> wrote:
>     >
>     >> How much do you pay for an Espresso in your local currency?
>     >>
>     >> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>     >> people would expect. Certainly more familiar than µBTC 3558 or BTC
>     >> 0.003578.
>     >>
>     >> Anyway, I was just sharing real-world experience: nobody is confused.
>     >>
>     >>
>     >> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>     >>> You give them a hard to interpret thing like mBTC and then wonder
>     >>> why they rather look at local currency. Because the choices you
>     >>> gave them are bad.
>     >>>
>     >>> I think Bitcoin would have a better chance to be percieved as a
>     >>> currency of its own if it had prices and fractions like currencies
>     >>> do.
>     >>>
>     >>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>     >>> would be.
>     >>>
>     >>>
>     >>> Tamas Blummer Bits of Proof
>     >>>
>     >>> On 14.03.2014, at 15:05, Andreas Schildbach
>     <andreas@schildbach•de <mailto:andreas@schildbach•de>
>     >>> <mailto:andreas@schildbach•de <mailto:andreas@schildbach•de>>>
>     >>> wrote:
>     >>>
>     >>>> btw. None of Bitcoin Wallet's users complained about confusion
>     >>>> because of the mBTC switch. In contrast, I get many mails and
>     >>>> questions if exchange rates happen to differ by >10%.
>     >>>>
>     >>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>     >>>> local currency that matters to the users.
>     >>>>
>     >>>>
>     >>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>     >>>>> Indeed. And users were crying for mBTC. Nobody was asking for
>     >>>>> µBTC.
>     >>>>>
>     >>>>> I must admit I was not aware if this thread. I just watched
>     >>>>> other wallets and at some point decided its time to switch to
>     >>>>> mBTC.
>     >>>>>
>     >>>>>
>     >>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>     >>>>>> The standard has become mBTC and that's what was adopted.
>     >>>>>> It's too late to try and sway this on a mailing list thread
>     >>>>>> now.
>     >>>>>>
>     >>>>>>
>     >>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>     >>>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>
>     <mailto:g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>>
>     >>>>>> <mailto:g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>>> wrote:
>     >>>>>>
>     >>>>>> The MultiBit HD view is that this is a locale-sensitive
>     >>>>>> presentation issue. As a result we offer a simple
>     >>>>>> configuration panel giving pretty much every possible
>     >>>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
>     >>>>>> mXBT,  μXBT, sat along with settings for leading/trailing
>     >>>>>> symbol, commas, spaces and points. This allows anyone to
>     >>>>>> customise to meet their own needs beyond the offered default.
>     >>>>>>
>     >>>>>>
>     >>>>>> We apply the NIST guidelines for representation of SI unit
>     >>>>>> symbols (i.e no conversion to native language, no RTL giving
>     >>>>>> icon+m etc).
>     >>>>>>
>     >>>>>> Right now MultiBit HD is configured to use m+icon taken from
>     >>>>>> the Font Awesome icon set. However reading earlier posts it
>     >>>>>> seems that μ+icon is more sensible.
>     >>>>>>
>     >>>>>> Let us know what you'd like.
>     >>>>>>
>     >>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>     >>>>>> Awesome icon:
>     >>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>     >>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>     >>>>>>
>     >>>>>>
>     >>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
>     <mailto:jgarzik@bitpay•com>
>     >>>>>> <mailto:jgarzik@bitpay•com <mailto:jgarzik@bitpay•com>>
>     >>>>>> <mailto:jgarzik@bitpay•com <mailto:jgarzik@bitpay•com>>> wrote:
>     >>>>>>
>     >>>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
>     >>>>>> several weeks ago, which was disappointing -- it sounded like
>     >>>>>> the consensus was uBTC, and moving to uBTC later --which will
>     >>>>>> happen-- may result in additional user confusion, thanks to
>     >>>>>> yet another decimal place transition.
> 
> 
> 
>     ------------------------------------------------------------------------------
>     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@lists•sourceforge.net
>     <mailto:Bitcoin-development@lists•sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 





 permalink raw reply	[|nested]
2014-03-14 14:49                     ` Andreas Schildbach
  2014-03-14 14:57                       ` Tamas Blummer

  2014-03-14 16:15                         ` Alex Morcos
  
From: Mark Friedenbach @ 2014-03-14 16:01 UTC (permalink / raw)
  To: bitcoin-development

A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
numbers in both Chinas, Thailand, and other economically important East
Asian countries. Expect to pay hundreds of rupees in India, or thousands
of rupees in Indonesia.

This concept that money should have low, single digits for everyday
prices is not just Western-centric, it's English-centric. An expresso in
Rome would have cost you a few (tens of?) thousand lira in recent
memory. It was pegging of the Euro to the U.S. dollar that brought
European states in line with the English-speaking world (who themselves
trace lineage to the pound sterling).

No, there is no culturally-neutral common standards for currency and
pricing. But there are ill-advised, ill-informed "standards" in
accounting software that we nevertheless must live with. These software
packages do not handle more than two decimal places gracefully. That
gives technical justifications for moving to either uBTC or accounting
in Satoshis directly. An argument for uBTC is that it retains alignment
with the existing kBTC/BTC/mBTC/uBTC conventions.

However another limitation of these accounting software practices is
that they do not always handle SI notation very well, particularly
sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
(XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
compliant with any software accounting package out there.

We are still very, very early in the adoption period. These are changes
that could be made now simply by a few big players and/or the bitcoin
foundation changing their practice and their users following suit.

On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
> How much do you pay for an Espresso in your local currency?
> 
> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> people would expect. Certainly more familiar than µBTC 3558 or BTC
> 0.003578.
> 
> Anyway, I was just sharing real-world experience: nobody is confused.
> 
> 
> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>> You give them a hard to interpret thing like mBTC and then wonder
>> why they rather look at local currency. Because the choices you
>> gave them are bad.
>>
>> I think Bitcoin would have a better chance to be percieved as a
>> currency of its own if it had prices and fractions like currencies
>> do.
>>
>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>> would be.
>>
>>
>> Tamas Blummer Bits of Proof
>>
>> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de>
>> wrote:
>>
>>> btw. None of Bitcoin Wallet's users complained about confusion
>>> because of the mBTC switch. In contrast, I get many mails and
>>> questions if exchange rates happen to differ by >10%.
>>>
>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>>> local currency that matters to the users.
>>>
>>>
>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>>>> Indeed. And users were crying for mBTC. Nobody was asking for
>>>> µBTC.
>>>>
>>>> I must admit I was not aware if this thread. I just watched
>>>> other wallets and at some point decided its time to switch to
>>>> mBTC.
>>>>
>>>>
>>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>>>>> The standard has become mBTC and that's what was adopted.
>>>>> It's too late to try and sway this on a mailing list thread
>>>>> now.
>>>>>
>>>>>
>>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>> wrote:
>>>>>
>>>>> The MultiBit HD view is that this is a locale-sensitive
>>>>> presentation issue. As a result we offer a simple
>>>>> configuration panel giving pretty much every possible
>>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
>>>>> mXBT,  μXBT, sat along with settings for leading/trailing
>>>>> symbol, commas, spaces and points. This allows anyone to
>>>>> customise to meet their own needs beyond the offered default.
>>>>>
>>>>>
>>>>> We apply the NIST guidelines for representation of SI unit
>>>>> symbols (i.e no conversion to native language, no RTL giving
>>>>> icon+m etc).
>>>>>
>>>>> Right now MultiBit HD is configured to use m+icon taken from
>>>>> the Font Awesome icon set. However reading earlier posts it
>>>>> seems that μ+icon is more sensible.
>>>>>
>>>>> Let us know what you'd like.
>>>>>
>>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>>>>> Awesome icon:
>>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>>>>>
>>>>>
>>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com 
>>>>> <mailto:jgarzik@bitpay•com>> wrote:
>>>>>
>>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
>>>>> several weeks ago, which was disappointing -- it sounded like
>>>>> the consensus was uBTC, and moving to uBTC later --which will
>>>>> happen-- may result in additional user confusion, thanks to
>>>>> yet another decimal place transition.
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com 
>>>>> <mailto:w@grabhive•com>> wrote:
>>>>>> We're with uBTC too. Been waiting for the signal to do
>>>>>> this,
>>>>> let's do it right after the fee system is improved.
>>>>>>
>>>>>> -wendell
>>>>>>
>>>>>> grabhive.com <http://grabhive.com> |
>>>>>> twitter.com/hivewallet
>>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
>>>>>>
>>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>>>>>>
>>>>>>> Go straight to uBTC. Humans and existing computer
>>>>>>> systems
>>>>> handle numbers to
>>>>>>> the left of the decimals just fine (HK Dollars, Yen).
>>>>>>> The
>>>>> opposite is
>>>>>>> untrue (QuickBooks really does not like 3+ decimal
>>>>>>> places).
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- Jeff Garzik Bitcoin core developer and open source
>>>>> evangelist BitPay, Inc.      https://bitpay.com/
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
> 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@lists•sourceforge.net 
>>>>> <mailto:Bitcoin-development@lists•sourceforge.net> 
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> ------------------------------------------------------------------------------
>>>>> 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@lists•sourceforge.net 
>>>>> <mailto:Bitcoin-development@lists•sourceforge.net> 
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
> ------------------------------------------------------------------------------
>>>>> 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@lists•sourceforge.net 
>>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
> ------------------------------------------------------------------------------
>>>> 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@lists•sourceforge.net 
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>>
>>>
>>>>
> ------------------------------------------------------------------------------
>>> 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@lists•sourceforge.net 
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
> 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@lists•sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 



 permalink raw reply	[|nested]
2014-03-14 16:01                       ` Mark Friedenbach

  2014-03-14 16:51                           ` Ricardo Filipe
  
From: Alex Morcos @ 2014-03-14 16:15 UTC (permalink / raw)
  To: Mark Friedenbach;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 12346 bytes --]

I think Mark makes some good arguments.
I realize this would only add to the confusion, but...
What if we did relabel 100 satoshis to be some new kind of unit ("bit" or
whatever else), with a proper 3 letter code, and then from a user
standpoint, where people are using mBTC, they could switch to using Kbits
(ok thats obviously bad, but you get the idea) at the same nominal price.
 But accounting backends and so forth would operate in the "bit" base unit
with 2 decimals of precision.




On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach <mark@monetize•io> wrote:

> A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
> numbers in both Chinas, Thailand, and other economically important East
> Asian countries. Expect to pay hundreds of rupees in India, or thousands
> of rupees in Indonesia.
>
> This concept that money should have low, single digits for everyday
> prices is not just Western-centric, it's English-centric. An expresso in
> Rome would have cost you a few (tens of?) thousand lira in recent
> memory. It was pegging of the Euro to the U.S. dollar that brought
> European states in line with the English-speaking world (who themselves
> trace lineage to the pound sterling).
>
> No, there is no culturally-neutral common standards for currency and
> pricing. But there are ill-advised, ill-informed "standards" in
> accounting software that we nevertheless must live with. These software
> packages do not handle more than two decimal places gracefully. That
> gives technical justifications for moving to either uBTC or accounting
> in Satoshis directly. An argument for uBTC is that it retains alignment
> with the existing kBTC/BTC/mBTC/uBTC conventions.
>
> However another limitation of these accounting software practices is
> that they do not always handle SI notation very well, particularly
> sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
> (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
> compliant with any software accounting package out there.
>
> We are still very, very early in the adoption period. These are changes
> that could be made now simply by a few big players and/or the bitcoin
> foundation changing their practice and their users following suit.
>
> On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
> > How much do you pay for an Espresso in your local currency?
> >
> > At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> > people would expect. Certainly more familiar than µBTC 3558 or BTC
> > 0.003578.
> >
> > Anyway, I was just sharing real-world experience: nobody is confused.
> >
> >
> > On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> >> You give them a hard to interpret thing like mBTC and then wonder
> >> why they rather look at local currency. Because the choices you
> >> gave them are bad.
> >>
> >> I think Bitcoin would have a better chance to be percieved as a
> >> currency of its own if it had prices and fractions like currencies
> >> do.
> >>
> >> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> >> would be.
> >>
> >>
> >> Tamas Blummer Bits of Proof
> >>
> >> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de>
> >> wrote:
> >>
> >>> btw. None of Bitcoin Wallet's users complained about confusion
> >>> because of the mBTC switch. In contrast, I get many mails and
> >>> questions if exchange rates happen to differ by >10%.
> >>>
> >>> I suspect nobody looks at the Bitcoin price. It's the amount in
> >>> local currency that matters to the users.
> >>>
> >>>
> >>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> >>>> Indeed. And users were crying for mBTC. Nobody was asking for
> >>>> µBTC.
> >>>>
> >>>> I must admit I was not aware if this thread. I just watched
> >>>> other wallets and at some point decided its time to switch to
> >>>> mBTC.
> >>>>
> >>>>
> >>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
> >>>>> The standard has become mBTC and that's what was adopted.
> >>>>> It's too late to try and sway this on a mailing list thread
> >>>>> now.
> >>>>>
> >>>>>
> >>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
> >>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>> wrote:
> >>>>>
> >>>>> The MultiBit HD view is that this is a locale-sensitive
> >>>>> presentation issue. As a result we offer a simple
> >>>>> configuration panel giving pretty much every possible
> >>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
> >>>>> mXBT,  μXBT, sat along with settings for leading/trailing
> >>>>> symbol, commas, spaces and points. This allows anyone to
> >>>>> customise to meet their own needs beyond the offered default.
> >>>>>
> >>>>>
> >>>>> We apply the NIST guidelines for representation of SI unit
> >>>>> symbols (i.e no conversion to native language, no RTL giving
> >>>>> icon+m etc).
> >>>>>
> >>>>> Right now MultiBit HD is configured to use m+icon taken from
> >>>>> the Font Awesome icon set. However reading earlier posts it
> >>>>> seems that μ+icon is more sensible.
> >>>>>
> >>>>> Let us know what you'd like.
> >>>>>
> >>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
> >>>>> Awesome icon:
> >>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
> >>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> >>>>>
> >>>>>
> >>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
> >>>>> <mailto:jgarzik@bitpay•com>> wrote:
> >>>>>
> >>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
> >>>>> several weeks ago, which was disappointing -- it sounded like
> >>>>> the consensus was uBTC, and moving to uBTC later --which will
> >>>>> happen-- may result in additional user confusion, thanks to
> >>>>> yet another decimal place transition.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com
> >>>>> <mailto:w@grabhive•com>> wrote:
> >>>>>> We're with uBTC too. Been waiting for the signal to do
> >>>>>> this,
> >>>>> let's do it right after the fee system is improved.
> >>>>>>
> >>>>>> -wendell
> >>>>>>
> >>>>>> grabhive.com <http://grabhive.com> |
> >>>>>> twitter.com/hivewallet
> >>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
> >>>>>>
> >>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >>>>>>
> >>>>>>> Go straight to uBTC. Humans and existing computer
> >>>>>>> systems
> >>>>> handle numbers to
> >>>>>>> the left of the decimals just fine (HK Dollars, Yen).
> >>>>>>> The
> >>>>> opposite is
> >>>>>>> untrue (QuickBooks really does not like 3+ decimal
> >>>>>>> places).
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> -- Jeff Garzik Bitcoin core developer and open source
> >>>>> evangelist BitPay, Inc.      https://bitpay.com/
> >>>>>
> >>>>>
> ------------------------------------------------------------------------------
> >>>>>
> >>>>>
> > 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@lists•sourceforge.net
> >>>>> <mailto:Bitcoin-development@lists•sourceforge.net>
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>>> 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@lists•sourceforge.net
> >>>>> <mailto:Bitcoin-development@lists•sourceforge.net>
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>>> 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@lists•sourceforge.net
> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >
> ------------------------------------------------------------------------------
> >>>> 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@lists•sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >
> ------------------------------------------------------------------------------
> >>> 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@lists•sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> > 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@lists•sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 18827 bytes --]

 permalink raw reply	[|nested]
From: Andrew Smith @ 2014-03-14 16:25 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 93 bytes --]

Well, not sure I wanted to subscribe the mbtc vs ubtc list... its a
default, not a big deal.

[-- Attachment #2: Type: text/html, Size: 145 bytes --]

 permalink raw reply	[|nested]
2014-03-14 16:15                         ` Alex Morcos

  2014-03-14 16:58                             ` Allen Piscitello
  
From: Ricardo Filipe @ 2014-03-14 16:51 UTC (permalink / raw)
  Cc: bitcoin-development

so much discussion for a visual update...

make this a user experiment:
-give the user the possibility to use BTC/mBTC/uMTC
-retrieve the results after some time
-make the default the most used option


2014-03-14 16:15 GMT+00:00 Alex Morcos <morcos@gmail•com>:
> I think Mark makes some good arguments.
> I realize this would only add to the confusion, but...
> What if we did relabel 100 satoshis to be some new kind of unit ("bit" or
> whatever else), with a proper 3 letter code, and then from a user
> standpoint, where people are using mBTC, they could switch to using Kbits
> (ok thats obviously bad, but you get the idea) at the same nominal price.
> But accounting backends and so forth would operate in the "bit" base unit
> with 2 decimals of precision.
>
>
>
>
> On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach <mark@monetize•io> wrote:
>>
>> A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
>> numbers in both Chinas, Thailand, and other economically important East
>> Asian countries. Expect to pay hundreds of rupees in India, or thousands
>> of rupees in Indonesia.
>>
>> This concept that money should have low, single digits for everyday
>> prices is not just Western-centric, it's English-centric. An expresso in
>> Rome would have cost you a few (tens of?) thousand lira in recent
>> memory. It was pegging of the Euro to the U.S. dollar that brought
>> European states in line with the English-speaking world (who themselves
>> trace lineage to the pound sterling).
>>
>> No, there is no culturally-neutral common standards for currency and
>> pricing. But there are ill-advised, ill-informed "standards" in
>> accounting software that we nevertheless must live with. These software
>> packages do not handle more than two decimal places gracefully. That
>> gives technical justifications for moving to either uBTC or accounting
>> in Satoshis directly. An argument for uBTC is that it retains alignment
>> with the existing kBTC/BTC/mBTC/uBTC conventions.
>>
>> However another limitation of these accounting software practices is
>> that they do not always handle SI notation very well, particularly
>> sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
>> (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
>> compliant with any software accounting package out there.
>>
>> We are still very, very early in the adoption period. These are changes
>> that could be made now simply by a few big players and/or the bitcoin
>> foundation changing their practice and their users following suit.
>>
>> On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
>> > How much do you pay for an Espresso in your local currency?
>> >
>> > At least for the Euro and the Dollar, mBTC 3.56 is very close to what
>> > people would expect. Certainly more familiar than µBTC 3558 or BTC
>> > 0.003578.
>> >
>> > Anyway, I was just sharing real-world experience: nobody is confused.
>> >
>> >
>> > On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>> >> You give them a hard to interpret thing like mBTC and then wonder
>> >> why they rather look at local currency. Because the choices you
>> >> gave them are bad.
>> >>
>> >> I think Bitcoin would have a better chance to be percieved as a
>> >> currency of its own if it had prices and fractions like currencies
>> >> do.
>> >>
>> >> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>> >> would be.
>> >>
>> >>
>> >> Tamas Blummer Bits of Proof
>> >>
>> >> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de>
>> >> wrote:
>> >>
>> >>> btw. None of Bitcoin Wallet's users complained about confusion
>> >>> because of the mBTC switch. In contrast, I get many mails and
>> >>> questions if exchange rates happen to differ by >10%.
>> >>>
>> >>> I suspect nobody looks at the Bitcoin price. It's the amount in
>> >>> local currency that matters to the users.
>> >>>
>> >>>
>> >>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
>> >>>> Indeed. And users were crying for mBTC. Nobody was asking for
>> >>>> µBTC.
>> >>>>
>> >>>> I must admit I was not aware if this thread. I just watched
>> >>>> other wallets and at some point decided its time to switch to
>> >>>> mBTC.
>> >>>>
>> >>>>
>> >>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
>> >>>>> The standard has become mBTC and that's what was adopted.
>> >>>>> It's too late to try and sway this on a mailing list thread
>> >>>>> now.
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
>> >>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>> wrote:
>> >>>>>
>> >>>>> The MultiBit HD view is that this is a locale-sensitive
>> >>>>> presentation issue. As a result we offer a simple
>> >>>>> configuration panel giving pretty much every possible
>> >>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
>> >>>>> mXBT,  μXBT, sat along with settings for leading/trailing
>> >>>>> symbol, commas, spaces and points. This allows anyone to
>> >>>>> customise to meet their own needs beyond the offered default.
>> >>>>>
>> >>>>>
>> >>>>> We apply the NIST guidelines for representation of SI unit
>> >>>>> symbols (i.e no conversion to native language, no RTL giving
>> >>>>> icon+m etc).
>> >>>>>
>> >>>>> Right now MultiBit HD is configured to use m+icon taken from
>> >>>>> the Font Awesome icon set. However reading earlier posts it
>> >>>>> seems that μ+icon is more sensible.
>> >>>>>
>> >>>>> Let us know what you'd like.
>> >>>>>
>> >>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
>> >>>>> Awesome icon:
>> >>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
>> >>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>> >>>>>
>> >>>>>
>> >>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
>> >>>>> <mailto:jgarzik@bitpay•com>> wrote:
>> >>>>>
>> >>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
>> >>>>> several weeks ago, which was disappointing -- it sounded like
>> >>>>> the consensus was uBTC, and moving to uBTC later --which will
>> >>>>> happen-- may result in additional user confusion, thanks to
>> >>>>> yet another decimal place transition.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com
>> >>>>> <mailto:w@grabhive•com>> wrote:
>> >>>>>> We're with uBTC too. Been waiting for the signal to do
>> >>>>>> this,
>> >>>>> let's do it right after the fee system is improved.
>> >>>>>>
>> >>>>>> -wendell
>> >>>>>>
>> >>>>>> grabhive.com <http://grabhive.com> |
>> >>>>>> twitter.com/hivewallet
>> >>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
>> >>>>>>
>> >>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>> >>>>>>
>> >>>>>>> Go straight to uBTC. Humans and existing computer
>> >>>>>>> systems
>> >>>>> handle numbers to
>> >>>>>>> the left of the decimals just fine (HK Dollars, Yen).
>> >>>>>>> The
>> >>>>> opposite is
>> >>>>>>> untrue (QuickBooks really does not like 3+ decimal
>> >>>>>>> places).
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> -- Jeff Garzik Bitcoin core developer and open source
>> >>>>> evangelist BitPay, Inc.      https://bitpay.com/
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------------------------------------------------------
>> >>>>>
>> >>>>>
>> > 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@lists•sourceforge.net
>> >>>>> <mailto:Bitcoin-development@lists•sourceforge.net>
>> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >
>> > ------------------------------------------------------------------------------
>> >>>>> 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@lists•sourceforge.net
>> >>>>> <mailto:Bitcoin-development@lists•sourceforge.net>
>> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >
>> > ------------------------------------------------------------------------------
>> >>>>> 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@lists•sourceforge.net
>> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>
>> >
>> > ------------------------------------------------------------------------------
>> >>>> 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@lists•sourceforge.net
>> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>>
>> >
>> > ------------------------------------------------------------------------------
>> >>> 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@lists•sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >>
>> >>
>> > 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@lists•sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > 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@lists•sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> 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@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



 permalink raw reply	[|nested]
2014-03-14 16:51                           ` Ricardo Filipe

  
From: Allen Piscitello @ 2014-03-14 16:58 UTC (permalink / raw)
  To: Ricardo Filipe;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 15213 bytes --]

Fairly useless experiment, since the vast majority of users will almost
always stay at the default.  The winner will always be whatever was
selected as the default initially.  This might work if the default was
randomly chosen, and you see what actually annoyed users enough to switch
off of it most often.


On Fri, Mar 14, 2014 at 11:51 AM, Ricardo Filipe
<ricardojdfilipe@gmail•com>wrote:

> so much discussion for a visual update...
>
> make this a user experiment:
> -give the user the possibility to use BTC/mBTC/uMTC
> -retrieve the results after some time
> -make the default the most used option
>
>
> 2014-03-14 16:15 GMT+00:00 Alex Morcos <morcos@gmail•com>:
> > I think Mark makes some good arguments.
> > I realize this would only add to the confusion, but...
> > What if we did relabel 100 satoshis to be some new kind of unit ("bit" or
> > whatever else), with a proper 3 letter code, and then from a user
> > standpoint, where people are using mBTC, they could switch to using Kbits
> > (ok thats obviously bad, but you get the idea) at the same nominal price.
> > But accounting backends and so forth would operate in the "bit" base unit
> > with 2 decimals of precision.
> >
> >
> >
> >
> > On Fri, Mar 14, 2014 at 12:01 PM, Mark Friedenbach <mark@monetize•io>
> wrote:
> >>
> >> A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
> >> numbers in both Chinas, Thailand, and other economically important East
> >> Asian countries. Expect to pay hundreds of rupees in India, or thousands
> >> of rupees in Indonesia.
> >>
> >> This concept that money should have low, single digits for everyday
> >> prices is not just Western-centric, it's English-centric. An expresso in
> >> Rome would have cost you a few (tens of?) thousand lira in recent
> >> memory. It was pegging of the Euro to the U.S. dollar that brought
> >> European states in line with the English-speaking world (who themselves
> >> trace lineage to the pound sterling).
> >>
> >> No, there is no culturally-neutral common standards for currency and
> >> pricing. But there are ill-advised, ill-informed "standards" in
> >> accounting software that we nevertheless must live with. These software
> >> packages do not handle more than two decimal places gracefully. That
> >> gives technical justifications for moving to either uBTC or accounting
> >> in Satoshis directly. An argument for uBTC is that it retains alignment
> >> with the existing kBTC/BTC/mBTC/uBTC conventions.
> >>
> >> However another limitation of these accounting software practices is
> >> that they do not always handle SI notation very well, particularly
> >> sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
> >> (XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
> >> compliant with any software accounting package out there.
> >>
> >> We are still very, very early in the adoption period. These are changes
> >> that could be made now simply by a few big players and/or the bitcoin
> >> foundation changing their practice and their users following suit.
> >>
> >> On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
> >> > How much do you pay for an Espresso in your local currency?
> >> >
> >> > At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> >> > people would expect. Certainly more familiar than µBTC 3558 or BTC
> >> > 0.003578.
> >> >
> >> > Anyway, I was just sharing real-world experience: nobody is confused.
> >> >
> >> >
> >> > On 03/14/2014 03:14 PM, Tamas Blummer wrote:
> >> >> You give them a hard to interpret thing like mBTC and then wonder
> >> >> why they rather look at local currency. Because the choices you
> >> >> gave them are bad.
> >> >>
> >> >> I think Bitcoin would have a better chance to be percieved as a
> >> >> currency of its own if it had prices and fractions like currencies
> >> >> do.
> >> >>
> >> >> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
> >> >> would be.
> >> >>
> >> >>
> >> >> Tamas Blummer Bits of Proof
> >> >>
> >> >> On 14.03.2014, at 15:05, Andreas Schildbach <andreas@schildbach•de>
> >> >> wrote:
> >> >>
> >> >>> btw. None of Bitcoin Wallet's users complained about confusion
> >> >>> because of the mBTC switch. In contrast, I get many mails and
> >> >>> questions if exchange rates happen to differ by >10%.
> >> >>>
> >> >>> I suspect nobody looks at the Bitcoin price. It's the amount in
> >> >>> local currency that matters to the users.
> >> >>>
> >> >>>
> >> >>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
> >> >>>> Indeed. And users were crying for mBTC. Nobody was asking for
> >> >>>> µBTC.
> >> >>>>
> >> >>>> I must admit I was not aware if this thread. I just watched
> >> >>>> other wallets and at some point decided its time to switch to
> >> >>>> mBTC.
> >> >>>>
> >> >>>>
> >> >>>> On 03/13/2014 02:31 PM, Mike Hearn wrote:
> >> >>>>> The standard has become mBTC and that's what was adopted.
> >> >>>>> It's too late to try and sway this on a mailing list thread
> >> >>>>> now.
> >> >>>>>
> >> >>>>>
> >> >>>>> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
> >> >>>>> <g.rowe@froot•co.uk <mailto:g.rowe@froot•co.uk>> wrote:
> >> >>>>>
> >> >>>>> The MultiBit HD view is that this is a locale-sensitive
> >> >>>>> presentation issue. As a result we offer a simple
> >> >>>>> configuration panel giving pretty much every possible
> >> >>>>> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
> >> >>>>> mXBT,  μXBT, sat along with settings for leading/trailing
> >> >>>>> symbol, commas, spaces and points. This allows anyone to
> >> >>>>> customise to meet their own needs beyond the offered default.
> >> >>>>>
> >> >>>>>
> >> >>>>> We apply the NIST guidelines for representation of SI unit
> >> >>>>> symbols (i.e no conversion to native language, no RTL giving
> >> >>>>> icon+m etc).
> >> >>>>>
> >> >>>>> Right now MultiBit HD is configured to use m+icon taken from
> >> >>>>> the Font Awesome icon set. However reading earlier posts it
> >> >>>>> seems that μ+icon is more sensible.
> >> >>>>>
> >> >>>>> Let us know what you'd like.
> >> >>>>>
> >> >>>>> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
> >> >>>>> Awesome icon:
> >> >>>>> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
> >> >>>>> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
> >> >>>>>
> >> >>>>>
> >> >>>>> On 13 March 2014 12:56, Jeff Garzik <jgarzik@bitpay•com
> >> >>>>> <mailto:jgarzik@bitpay•com>> wrote:
> >> >>>>>
> >> >>>>> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
> >> >>>>> several weeks ago, which was disappointing -- it sounded like
> >> >>>>> the consensus was uBTC, and moving to uBTC later --which will
> >> >>>>> happen-- may result in additional user confusion, thanks to
> >> >>>>> yet another decimal place transition.
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com
> >> >>>>> <mailto:w@grabhive•com>> wrote:
> >> >>>>>> We're with uBTC too. Been waiting for the signal to do
> >> >>>>>> this,
> >> >>>>> let's do it right after the fee system is improved.
> >> >>>>>>
> >> >>>>>> -wendell
> >> >>>>>>
> >> >>>>>> grabhive.com <http://grabhive.com> |
> >> >>>>>> twitter.com/hivewallet
> >> >>>>> <http://twitter.com/hivewallet> | gpg: 6C0C9411
> >> >>>>>>
> >> >>>>>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> >> >>>>>>
> >> >>>>>>> Go straight to uBTC. Humans and existing computer
> >> >>>>>>> systems
> >> >>>>> handle numbers to
> >> >>>>>>> the left of the decimals just fine (HK Dollars, Yen).
> >> >>>>>>> The
> >> >>>>> opposite is
> >> >>>>>>> untrue (QuickBooks really does not like 3+ decimal
> >> >>>>>>> places).
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> -- Jeff Garzik Bitcoin core developer and open source
> >> >>>>> evangelist BitPay, Inc.      https://bitpay.com/
> >> >>>>>
> >> >>>>>
> >> >>>>>
> ------------------------------------------------------------------------------
> >> >>>>>
> >> >>>>>
> >> > 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@lists•sourceforge.net
> >> >>>>> <mailto:Bitcoin-development@lists•sourceforge.net>
> >> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >>>>> 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@lists•sourceforge.net
> >> >>>>> <mailto:Bitcoin-development@lists•sourceforge.net>
> >> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >>>>> 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@lists•sourceforge.net
> >> >>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >>>> 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@lists•sourceforge.net
> >> >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>>
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >>> 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@lists•sourceforge.net
> >> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> ------------------------------------------------------------------------------
> >> >>
> >> >>
> >> > 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@lists•sourceforge.net
> >> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >>
> >> >
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > 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@lists•sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >> >
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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@lists•sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 24139 bytes --]

 permalink raw reply	[|nested]
2014-03-14  0:34                     ` Jorge Timón

  2014-03-14 20:13                         ` Natanael
  
From: vv01f @ 2014-03-14 17:14 UTC (permalink / raw)
  To: bitcoin-development

I think
* if we change to mBTC because your state currencys price for bitcoin
make this a valid option we will change again in future
* users do not like changes
* we should keep a good standard

A good standard should be
* built on standards (e.g. SI)
* backed by best practice: never force the user to take an option he
cannot change
* do not make changes without users permission
* take care of users at fault when entering 5.967 ot should be pointed
out before sending that e.g.
the sw understood 5967.000 000 00 BTC
instead of 5.967 000 00 BTC
because the user failed to use the correct delimiter.

For now a good standard is
* simply bitcoin as BTC with eight decimal places
or could be
* uBTC as SI prefix, probably using XBT as a symbol for compatibility
with other software
* satoshis (w. SI prefixes if numbers are to big) for regions where
decimal places in prices are uncommon

So I'd prefer:
Make the choice transparent to users and set a standard that the user
alway should be empowered to use all available decimal places.
And there should be a set of official test-cases for wallet software and
the desired behavior.



 permalink raw reply	[|nested]
2014-03-14 17:14                       ` vv01f

  
From: Natanael @ 2014-03-14 20:13 UTC (permalink / raw)
  To: vv01f;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 2512 bytes --]

Regarding (ISO standards) currency symbols, XBT is already used as
equivalent to 1 Bitcoin in numerous places, and XBC is taken and BT*
belongs to Bhutan (and X** is already the default for non-national currency
common items of trade), so IMHO we should define something like XUB as
microbitcoins so we can have a symbol that doesn't require changing any
existing systems and that can be standardized globally. Then those with
accounting software that needs to deal with something that has two decimals
maximum without losing precision can use that while following well defined
standards. And those who don't like large numbers can still chose to show
mBTC.

- Sent from my phone
Den 14 mar 2014 18:18 skrev "vv01f" <vv01f@riseup•net>:

> I think
> * if we change to mBTC because your state currencys price for bitcoin
> make this a valid option we will change again in future
> * users do not like changes
> * we should keep a good standard
>
> A good standard should be
> * built on standards (e.g. SI)
> * backed by best practice: never force the user to take an option he
> cannot change
> * do not make changes without users permission
> * take care of users at fault when entering 5.967 ot should be pointed
> out before sending that e.g.
> the sw understood 5967.000 000 00 BTC
> instead of 5.967 000 00 BTC
> because the user failed to use the correct delimiter.
>
> For now a good standard is
> * simply bitcoin as BTC with eight decimal places
> or could be
> * uBTC as SI prefix, probably using XBT as a symbol for compatibility
> with other software
> * satoshis (w. SI prefixes if numbers are to big) for regions where
> decimal places in prices are uncommon
>
> So I'd prefer:
> Make the choice transparent to users and set a standard that the user
> alway should be empowered to use all available decimal places.
> And there should be a set of official test-cases for wallet software and
> the desired behavior.
>
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3146 bytes --]

 permalink raw reply	[|nested]
2014-03-13 12:56         ` Jeff Garzik
  2014-03-13 13:29           ` Gary Rowe
  2014-03-13 13:34           ` Wladimir

  
From: Odinn Cyberguerrilla @ 2014-03-14 21:56 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev, Wendell

Hello,

I see a lot of talk on this topic and get the senst that it is focused on
default display only regarding the mBTC / uBTC questions.  However, if the
focus is broader, involving whether or how to express other currencies or
moving further along to what that might even mean (since many people have
different ideas about what a currency is) perhaps there is another issue
to open, or a process BIP to address how to display other concepts, for
example:

other currencies

microdonations

etc.

I sense however that may be outside the scope of this thread, so I'll just
stop here and try to read samples of the other stuff going on here.

-Odinn
http://abis.io

> Resurrecting this topic.  Bitcoin Wallet moved to mBTC several weeks
> ago, which was disappointing -- it sounded like the consensus was
> uBTC, and moving to uBTC later --which will happen-- may result in
> additional user confusion, thanks to yet another decimal place
> transition.
>
>
>
> On Sun, Nov 17, 2013 at 9:28 PM, Wendell <w@grabhive•com> wrote:
>> We're with uBTC too. Been waiting for the signal to do this, let's do it
>> right after the fee system is improved.
>>
>> -wendell
>>
>> grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411
>>
>> On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
>>
>>> Go straight to uBTC. Humans and existing computer systems handle
>>> numbers to
>>> the left of the decimals just fine (HK Dollars, Yen). The opposite is
>>> untrue (QuickBooks really does not like 3+ decimal places).
>>
>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
> ------------------------------------------------------------------------------
> 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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>





 permalink raw reply	[|nested]
2013-11-14 11:45 Melvin Carvalho
                   ` 
  2013-11-14 22:27 ` 

  
From: Melvin Carvalho @ 2014-05-02 14:29 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

On 14 November 2013 12:45, Melvin Carvalho <melvincarvalho@gmail•com> wrote:

> Rationale
> =======
>
> Given the recent rise in value there seems to be anecdotal evidence that 1
> bitcoin being so high is putting off a lot of normal buyers, because they
> feel that putting down $400+ and only getting "1 coin", or having to buy in
> multiples of 1 whole coin, is too much.. only after it being explained that
> they can buy fractional amounts to they regain interest, apparently
> happening increasingly.
>
>
> Straw Poll
> ========
>
> 6 months ago there was a straw poll on this
>
> https://bitcointalk.org/index.php?topic=220322.0
>
> Roughly 2/3 of respondents favoured switching
>
> A further 20% said to switch after it hits 1000
>
> Satoshi's comments:
> ================
>
> Eventually at most only 21 million coins for 6.8 billion people in the
> world if it really gets huge.
>
> But don't worry, there are another 6 decimal places that aren't shown, for
> a total of 8 decimal places internally.  It shows 1.00 but internally it's
> 1.00000000.  If there's massive deflation in the future, the software could
> show more decimal places.
>
> If it gets tiresome working with small numbers, we could change where the
> display shows the decimal point.  Same amount of money, just different
> convention for where the ","'s and "."'s go.  e.g. moving the decimal place
> 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.
>
> https://bitcointalk.org/index.php?topic=44.msg267#msg267
>
>
> Would now be a good time to start thinking about changing the default
> display in the software.  Perhaps initially it could be a dropdown display
> option, then at some point mbtc becomes the default?
>
>
Just a FYI on this topic.  In Gavin's recent interview he described the
block reward as 25,000 millibits (about 25 minutes in).

https://www.youtube.com/watch?v=4pBd-OD9Rns

Decide for yourself whether or not that's meaningful :)

PS very enjoyable and accessible panel ...

[-- Attachment #2: Type: text/html, Size: 2891 bytes --]

 permalink raw reply	[|nested]
2013-11-14 21:55     ` Allen Piscitello
  2013-11-14 22:00       ` Alan Reiner

  2014-05-03  0:54         ` Ben Davenport
  2014-05-03  4:23         ` Tamas Blummer
  
From: Jeff Garzik @ 2014-05-02 19:17 UTC (permalink / raw)
  To: Allen Piscitello;  Bitcoin Development

<vendor hat: on>

Related: http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2014-05-02 19:17       ` Jeff Garzik

  2014-05-03  1:13           ` Alan Reiner
  2014-05-03  2:38           ` Luke Dashjr
  2014-05-03  4:23         ` Tamas Blummer
  
From: Ben Davenport @ 2014-05-03  0:54 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 1787 bytes --]

I fully support this (it's what I suggested over a year ago), but what it
comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
together, agreeing what they're going to use, and doing a little joint
customer education campaign around it. If there's community momentum around
"bits", great.

My only addition is that I think we should all stop trying to attach SI
prefixes to the currency unit. Name me another world currency that uses SI
prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
That may not be accepted form everywhere, but in any case it's an informal
format, not a formal one. The important point is there should be one base
unit that is not modified with SI prefixes. And I think the arguments are
strong for that unit being = 100 satoshi.

Ben




On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:

> <vendor hat: on>
>
> Related:
> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2745 bytes --]

 permalink raw reply	[|nested]
2014-05-03  0:54         ` Ben Davenport

  2014-05-03  1:50             ` Aaron Voisine
  2014-05-03  2:10             ` Matias Alejo Garcia
  2014-05-03  2:38           ` Luke Dashjr
  
From: Alan Reiner @ 2014-05-03  1:13 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 3537 bytes --]

I've been a strong supporter of the 1e-6 unit switch since the beginning
and ready to do whatever I can with Armory to help ease that
transition.  I'm happy to prioritize a release that updates the Armory
interface to make "bits" the default unit, when the time is right.  I
think it makes sense to get as many apps and services to upgrade nearly
simultaneously.

My plan is to have a popup on the first load of the new version that
briefly introduces the change, and mentions that they can go back to the
old way in the settings, but make them work to do it.  For the transient
period (6 months?) all input boxes will auto-update nearby labels with
the converted-to-BTC value as they type, so that they don't have to do
any math in their head.  Similarly, all displayed BTC values will show
both.  But the 1e-6 unit will always be default or first unless they
explicitly change it in the interface.




On 5/2/2014 8:54 PM, Ben Davenport wrote:
> I fully support this (it's what I suggested over a year ago), but what
> it comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
> together, agreeing what they're going to use, and doing a little joint
> customer education campaign around it. If there's community momentum
> around "bits", great.
>
> My only addition is that I think we should all stop trying to attach
> SI prefixes to the currency unit. Name me another world currency that
> uses SI prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted
> standard at least in the US is <currency-symbol><amount><modifier>,
> i.e. $63k or $3M. That may not be accepted form everywhere, but in any
> case it's an informal format, not a formal one. The important point is
> there should be one base unit that is not modified with SI prefixes.
> And I think the arguments are strong for that unit being = 100 satoshi.
>
> Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik@bitpay•com
> <mailto:jgarzik@bitpay•com>> wrote:
>
>     <vendor hat: on>
>
>     Related:
>     http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>
>     --
>     Jeff Garzik
>     Bitcoin core developer and open source evangelist
>     BitPay, Inc.      https://bitpay.com/
>
>     ------------------------------------------------------------------------------
>     "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>     Instantly run your Selenium tests across 300+ browser/OS combos.  Get
>     unparalleled scalability from the best Selenium testing platform
>     available.
>     Simple to use. Nothing to install. Get started now for free."
>     http://p.sf.net/sfu/SauceLabs
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists•sourceforge.net
>     <mailto:Bitcoin-development@lists•sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Type: text/html, Size: 6110 bytes --]

 permalink raw reply	[|nested]
2014-05-03  1:13           ` Alan Reiner

  2014-05-03  2:10             ` Matias Alejo Garcia
  
From: Aaron Voisine @ 2014-05-03  1:50 UTC (permalink / raw)
  To: Alan Reiner;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 3979 bytes --]

It will also be important to chose the currency symbol for "bits" at the
same time. Lowercase stroke "b" I think is the obvious choice.
Unicode U+0180

Aaron

On Friday, May 2, 2014, Alan Reiner <etotheipi@gmail•com> wrote:

>  I've been a strong supporter of the 1e-6 unit switch since the beginning
> and ready to do whatever I can with Armory to help ease that transition.
> I'm happy to prioritize a release that updates the Armory interface to make
> "bits" the default unit, when the time is right.  I think it makes sense to
> get as many apps and services to upgrade nearly simultaneously.
>
> My plan is to have a popup on the first load of the new version that
> briefly introduces the change, and mentions that they can go back to the
> old way in the settings, but make them work to do it.  For the transient
> period (6 months?) all input boxes will auto-update nearby labels with the
> converted-to-BTC value as they type, so that they don't have to do any math
> in their head.  Similarly, all displayed BTC values will show both.  But
> the 1e-6 unit will always be default or first unless they explicitly change
> it in the interface.
>
>
>
>
> On 5/2/2014 8:54 PM, Ben Davenport wrote:
>
> I fully support this (it's what I suggested over a year ago), but what it
> comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
> together, agreeing what they're going to use, and doing a little joint
> customer education campaign around it. If there's community momentum around
> "bits", great.
>
>  My only addition is that I think we should all stop trying to attach SI
> prefixes to the currency unit. Name me another world currency that uses SI
> prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
> least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
> That may not be accepted form everywhere, but in any case it's an informal
> format, not a formal one. The important point is there should be one base
> unit that is not modified with SI prefixes. And I think the arguments are
> strong for that unit being = 100 satoshi.
>
>  Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik@bitpay.com<javascript:_e(%7B%7D,'cvml','jgarzik@bitpay•com');>
> > wrote:
>
>> <vendor hat: on>
>>
>> Related:
>> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>>  "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
>> unparalleled scalability from the best Selenium testing platform
>> available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>>  _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net<javascript:_e(%7B%7D,'cvml','Bitcoin-development@lists•sourceforge.net');>
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."http://p.sf.net/sfu/SauceLabs
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists•sourceforge.net <javascript:_e(%7B%7D,'cvml','Bitcoin-development@lists•sourceforge.net');>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>

-- 
There's no trick to being a humorist when you have the whole government
working for you -- Will Rodgers

[-- Attachment #2: Type: text/html, Size: 6372 bytes --]

 permalink raw reply	[|nested]
2014-05-03  1:13           ` Alan Reiner
  2014-05-03  1:50             ` Aaron Voisine

  
From: Matias Alejo Garcia @ 2014-05-03  2:10 UTC (permalink / raw)
  To: Alan Reiner;  Bitcoin Dev

I live in Argentina. Here, 1BTC is around half of a monthly average
wage (net), so, as you
can imagine, the value of 1 BTC is *very* inconvenient  for everyday
transactions.

 Also it presents an important entry barrier for new adopters: It would be
easier to accept buying thousands of "bits" than buying a tiny fraction
of a Bitcoin, for the same amount of pesos.

Changing to 1e-6 "bits" will solve both problems. Changing to 1e-6
"microbitcoins" will
solve the first one, but not sure about the second one. Buying (or
earning) mili or micro
something  isn't that sexy either.

Finally, against "micro" and in favor of "bits", micro is noted "μ",
which is also
 inconvenient (I had to copy and paste it from an other site). Many
different notations will be used like:  μBTC, uBTC,  "microBTC" and
even "mBTC".
Please prevent that.

These arguments also applies to many places in the  world (Argentina
is 40 out of 72 listed countries in
http://en.wikipedia.org/wiki/List_of_countries_by_average_wage).

matías




On Fri, May 2, 2014 at 10:13 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> I've been a strong supporter of the 1e-6 unit switch since the beginning and
> ready to do whatever I can with Armory to help ease that transition.  I'm
> happy to prioritize a release that updates the Armory interface to make
> "bits" the default unit, when the time is right.  I think it makes sense to
> get as many apps and services to upgrade nearly simultaneously.
>
> My plan is to have a popup on the first load of the new version that briefly
> introduces the change, and mentions that they can go back to the old way in
> the settings, but make them work to do it.  For the transient period (6
> months?) all input boxes will auto-update nearby labels with the
> converted-to-BTC value as they type, so that they don't have to do any math
> in their head.  Similarly, all displayed BTC values will show both.  But the
> 1e-6 unit will always be default or first unless they explicitly change it
> in the interface.
>
>
>
>
>
> On 5/2/2014 8:54 PM, Ben Davenport wrote:
>
> I fully support this (it's what I suggested over a year ago), but what it
> comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting together,
> agreeing what they're going to use, and doing a little joint customer
> education campaign around it. If there's community momentum around "bits",
> great.
>
> My only addition is that I think we should all stop trying to attach SI
> prefixes to the currency unit. Name me another world currency that uses SI
> prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
> least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
> That may not be accepted form everywhere, but in any case it's an informal
> format, not a formal one. The important point is there should be one base
> unit that is not modified with SI prefixes. And I think the arguments are
> strong for that unit being = 100 satoshi.
>
> Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
>>
>> <vendor hat: on>
>>
>> Related:
>> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
>> unparalleled scalability from the best Selenium testing platform
>> available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Matías Alejo Garcia
Skype/Twitter: @ematiu
Roads? Where we're going, we don't need roads!



 permalink raw reply	[|nested]
2014-05-03  0:54         ` Ben Davenport
  2014-05-03  1:13           ` Alan Reiner

  2014-05-03  2:41             ` Ben Davenport
                               ` (3 more replies)
  
From: Luke Dashjr @ 2014-05-03  2:38 UTC (permalink / raw)
  To: Ben Davenport;  bitcoin-development

On Saturday, May 03, 2014 12:54:37 AM Ben Davenport wrote:
> My only addition is that I think we should all stop trying to attach SI
> prefixes to the currency unit. Name me another world currency that uses SI
> prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard at
> least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
> That may not be accepted form everywhere, but in any case it's an informal
> format, not a formal one. The important point is there should be one base
> unit that is not modified with SI prefixes. And I think the arguments are
> strong for that unit being = 100 satoshi.

Huh? Your examples demonstrate the *opposite* of your point. 'k' and 'M' *are* 
the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one 
to admit SI is terrible, but I don't understand your argument here.

Luke

P.S. Note that SI units haven't actually ever been adopted, except by force of 
law. "Name me ... that uses SI" is a silly thing to say, since virtually all 
naturally-or-freely-adopted units of any measure have been based on a number 
that factor to twos and threes (not fives, like decimal).



 permalink raw reply	[|nested]
2014-05-03  2:38           ` Luke Dashjr

  2014-05-03  2:43             ` Peter Todd
                               ` (2 subsequent siblings)
  
From: Ben Davenport @ 2014-05-03  2:41 UTC (permalink / raw)
  To: Luke Dashjr;  bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

Luke,

My point is that you never apply the prefixes to the currency unit itself.
We don't spend kilodollars or megadollars.

Ben


On Fri, May 2, 2014 at 7:38 PM, Luke Dashjr <luke@dashjr•org> wrote:

> On Saturday, May 03, 2014 12:54:37 AM Ben Davenport wrote:
> > My only addition is that I think we should all stop trying to attach SI
> > prefixes to the currency unit. Name me another world currency that uses
> SI
> > prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted standard
> at
> > least in the US is <currency-symbol><amount><modifier>, i.e. $63k or $3M.
> > That may not be accepted form everywhere, but in any case it's an
> informal
> > format, not a formal one. The important point is there should be one base
> > unit that is not modified with SI prefixes. And I think the arguments are
> > strong for that unit being = 100 satoshi.
>
> Huh? Your examples demonstrate the *opposite* of your point. 'k' and 'M'
> *are*
> the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first
> one
> to admit SI is terrible, but I don't understand your argument here.
>
> Luke
>
> P.S. Note that SI units haven't actually ever been adopted, except by
> force of
> law. "Name me ... that uses SI" is a silly thing to say, since virtually
> all
> naturally-or-freely-adopted units of any measure have been based on a
> number
> that factor to twos and threes (not fives, like decimal).
>

[-- Attachment #2: Type: text/html, Size: 1916 bytes --]

 permalink raw reply	[|nested]
2014-05-03  2:38           ` Luke Dashjr
  2014-05-03  2:41             ` Ben Davenport

  2014-05-03  3:35             ` Un Ix
  2014-05-03 12:32             ` Roy Badami
  
From: Peter Todd @ 2014-05-03  2:43 UTC (permalink / raw)
  To: Luke Dashjr, Ben Davenport;  bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



>Huh? Your examples demonstrate the *opposite* of your point. 'k' and
>'M' *are*
>the SI prefixes. People *do* use 63k USD, $63k, and $3M.

Excellent point.

Also, I frequently hear statements referring to mili-bitcoins, mBTC, pronounced as "mili-bits" or "m-bits"; the term "bits" is very much already in use and not to refer to uBTC.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFQBAEBCAA6BQJTZFfuMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhRSfB/434bom68YyzgW0rPek
wrkjBHtxK7BgrPvkpMsBpAIWQ+NbKZBNTIZfp78rbUlGdj+3mXc5e+QXSnKHJn6V
azUtn4PsvL/iNAIZ91vdMYKRvFkAPfS+XBxR0J3JiAzQb6dshyUm9X6UQyJHGs8O
EOS2sQ/c2ZY6hFVE5JfA3jH8ykQy36MNfehbT290kppkcRq24JAVLYz66444CHA1
iMHCfnlcR9hMUVQmzds4QLIPHLLjEqkMxJUe5yxFVeW0MFxu2sG3jfYcOwoqQbBY
N+hLHOKuH5mOm6mfJ3/IHVj2dM9jok+JKG0GytZA1kKGbh/KGIhxIxE/06dNakfW
QzfS
=666/
-----END PGP SIGNATURE-----




 permalink raw reply	[|nested]
* 
  2014-05-03  2:38           ` Luke Dashjr
                               ` 
  2014-05-03  3:35             ` 

  3 siblings, 0 replies; 112+ messages in thread
From: Roy Badami @ 2014-05-03 12:32 UTC (permalink / raw)
  To: Luke Dashjr;  bitcoin-development

> the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one 

As a counter argument, many sources (including the BBC) abbreviate
million to 'm' (and billion to 'bn'), e.g. $3m, $3bn.

I think any similarity with SI units here is coincidental.

roy



^ permalink raw reply	[|nested] 112+ messages in thread
2014-05-02 19:17       ` Jeff Garzik
  2014-05-03  0:54         ` Ben Davenport

  
From: Tamas Blummer @ 2014-05-03  4:23 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Development


[-- Attachment #1.1: Type: text/plain, Size: 1072 bytes --]

Excellent move Jeff.

Best would now be to establish XBT as the ISO code for bits.

Regards,

Tamas Blummer
http://bitsofproof.com

On 02.05.2014, at 21:17, Jeff Garzik <jgarzik@bitpay•com> wrote:

> <vendor hat: on>
> 
> Related: http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
> 
> -- 
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 


[-- Attachment #1.2: Type: text/html, Size: 4640 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

 permalink raw reply	[|nested]
2014-05-03  2:38           ` Luke Dashjr
                               ` 
  2014-05-03  3:35             ` 

  
From: Roy Badami @ 2014-05-03 12:32 UTC (permalink / raw)
  To: Luke Dashjr;  bitcoin-development

> the SI prefixes. People *do* use 63k USD, $63k, and $3M. I'll be the first one 

As a counter argument, many sources (including the BBC) abbreviate
million to 'm' (and billion to 'bn'), e.g. $3m, $3bn.

I think any similarity with SI units here is coincidental.

roy



 permalink raw reply	[|nested]


  
From: Jannis Froese @ 2014-05-03 18:46 UTC (permalink / raw)
  To: bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 03.05.2014 02:54, Ben Davenport wrote:
> No one quotes amounts as 63 k$ or 3 M$. The accepted standard at 
> least in the US is <currency-symbol><amount><modifier>, i.e. $63k 
> or $3M.

As you said, that's in the US, and I strongly suspect the sole reason
is that in the US the currency symbol is written in front of the
amount. I often pronounce $10k as ten kilodollar, using it exactly
like a SI-prefix.

The much better argument against SI prefixes is that the prefixes for
values less than 1 tend to be much less well known: Most people know
that kilo means 1000, many know that mega means 1,000,000, but few
know that micro means 0.0000001, and those that do tend to confuse
micro and nano.

Jannis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIbBAEBAgAGBQJTZTmNAAoJEBrvn3PsoRcmrzYP9R0cch42wV+I21MNVbWEEhfw
GjuCqE2Vz7QtI4nhRZ0Eas+MOY6iZD1c2A7cr4BjWx+MdQQwJSMKg/UKruE3j9xs
4QAFQtjvQ69Yd5ztq3ISWM/DpGfPXRvRdIf02ldz0Sf4HMxvqHCcYov3/laOrFnF
3ECpd+JLrU/Wq/HWwuFFXbfyQnpn+9LHx5gcfhV/pW7PwAjwzeaKhY1neQRHhQWq
pD8iv2dikqs30nO6bhnrCv/u0N+2iwV4e+J0E+kpBwrCZLeG8MirRRdnLruJ5mnT
nGyRNdfPKl5n0Gm4AFkBC3a4VIYwOxAzxdfA55Hn27yxll0GFEQNqR9OCNblGUbQ
RWa3Nywa22aYHOTi7evmuP6dVFjF4T8dl8LzDBmeawBsbOeHAUYJgLoHezdwEoto
Dt01ML4CmCINnPIFiuab17gpUYg7OXKomOQPrdyaVnP2abgvQCV5bYhMnKKVa25U
mW5PK02stxKcTEyHBsz0BG8zmdx5+7A5ySaUHrXs+l3YNBp3idlDUeYIsEBKFAtR
vNEGLbV2ZvteOb+tflxuPSjgIaMHD9w6vX2l7+VgkRTms743s/wbQuLb2fXq7osM
zws5D/L74zG1ZwsNM04Ygs2GJoJhkb1QXxY9EuoIeiuK3nVeJEWeRGHBEmqCXOPx
FB/2U/d69fUTbvUzOXA=
=Qo8z
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]