Quote from: pj on December 28, 2010, 01:16:31 PM

You seem to assume that it is desirable that bitcoin be good at micro-payments, I don't think it has any importance whether the core protocol is inefficient at it or not.

I think we need to clarify 2 issues, which are really distinct. Since I started this thread I'm responsible for not clarifying this. When we are talking about "micropayments" (a bad choice of a term on my end) there are 2 issues:

Payments that are an order of magnitude less than normal "useful" transactions (eg. .001 USD)
Payments that happen at greater than 2 decimal places precision

These are actually 2 distinct concerns, and it is the 2nd issue that I'm most concerned with. Mainly because BTC is by design a natural deflationary currency (its value of BTC relative to USD has already gone up 5x since July).

Even if Bitcoin only achieves a moderate success of having 200K active users, given the fact that only 5M BTC are in existence, this is going to lead to heavy deflationary pressure.

I don't have an economic concerns about this - as the Keynesians have been consistently been proved wrong with regard to liquidity concerns - double so since as a purely electronic currency its trivial for us move a decimal place over.

So, my point is that inevitably *all* transactions are going naturally require moving one decimal place over. We are going to have a sort of reverse Zimbabwe problem on our hands, particularly how to on-the-fly add more decimal places.

Honestly, I think the choice of only having 21M possible BTC was a design flaw. Precisely because its going to force us into an unnatural and unwieldily situation with regards to decimal places. What do you even call .00001? Why introduce this complexity in the first place? In retrospect I think it would've been better to have a 2B maximum cap, solely for the reason is it would help keep notional representations into the whole integer range.