From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WOYTw-0003xk-UX for bitcoin-development@lists.sourceforge.net; Fri, 14 Mar 2014 20:13:28 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.50 as permitted sender) client-ip=74.125.82.50; envelope-from=natanael.l@gmail.com; helo=mail-wg0-f50.google.com; Received: from mail-wg0-f50.google.com ([74.125.82.50]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WOYTu-0006Eh-UL for bitcoin-development@lists.sourceforge.net; Fri, 14 Mar 2014 20:13:28 +0000 Received: by mail-wg0-f50.google.com with SMTP id x13so2649122wgg.9 for ; Fri, 14 Mar 2014 13:13:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.192.132 with SMTP id hg4mr8414205wjc.28.1394827998909; Fri, 14 Mar 2014 13:13:18 -0700 (PDT) Received: by 10.194.54.10 with HTTP; Fri, 14 Mar 2014 13:13:18 -0700 (PDT) Received: by 10.194.54.10 with HTTP; Fri, 14 Mar 2014 13:13:18 -0700 (PDT) In-Reply-To: <532338DD.4050901@riseup.net> References: <52852C2D.9020103@gmail.com> <52853D8A.6010501@monetize.io> <20140313160850.GW3180@nl.grid.coop> <532338DD.4050901@riseup.net> Date: Fri, 14 Mar 2014 21:13:18 +0100 Message-ID: From: Natanael To: vv01f Content-Type: multipart/alternative; boundary=047d7b87389665dc5e04f496b314 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (natanael.l[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WOYTu-0006Eh-UL Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] moving the default display to mbtc X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 20:13:29 -0000 --047d7b87389665dc5e04f496b314 Content-Type: text/plain; charset=UTF-8 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" : > 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 > --047d7b87389665dc5e04f496b314 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Regarding (ISO standards) currency symbols, XBT is already u= sed 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 currenc= y common items of trade), so IMHO we should define something like XUB as mi= crobitcoins so we can have a symbol that doesn't require changing any e= xisting systems and that can be standardized globally. Then those with acco= unting software that needs to deal with something that has two decimals max= imum without losing precision can use that while following well defined sta= ndards. 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" &l= t;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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--047d7b87389665dc5e04f496b314--