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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WO8Ke-0007I5-JG for bitcoin-development@lists.sourceforge.net; Thu, 13 Mar 2014 16:18:08 +0000 X-ACL-Warn: Received: from nl.grid.coop ([50.7.166.116]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WO8KX-0008Mk-Ab for bitcoin-development@lists.sourceforge.net; Thu, 13 Mar 2014 16:18:08 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by nl.grid.coop with local; Thu, 13 Mar 2014 11:17:53 -0500 id 000000000006A32F.000000005321DA31.00002D8D Date: Thu, 13 Mar 2014 11:17:53 -0500 From: Troy Benjegerdes To: Mike Hearn Message-ID: <20140313161753.GX3180@nl.grid.coop> References: <52852C2D.9020103@gmail.com> <52853D8A.6010501@monetize.io> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1WO8KX-0008Mk-Ab Cc: Bitcoin Dev , Wendell 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: Thu, 13 Mar 2014 16:18:08 -0000 On Thu, Mar 13, 2014 at 04:50:14PM +0100, Mike Hearn wrote: > On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik 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.