Reward drop effects

[DannyHamilton]

skateboards, oranges

No.  Once you get down to a single skateboard (or orange), you really can't divide it any further and still have it be useful as a skateboard (or orange).

Fair point. But my point still stands; Bitcoin as we know it is finite. A future version that divides it further is a blockchain fork and is not Bitcoin as we know it today.

. . . the current precision seems like a design flaw . . . It seems that in the initial design it would have made more sense to have 11 decimal places.  Then the maximum output in a transaction would be 92,233,720.36854775807 (92 million) . . .

I've lobbied for the creation of three more decimal places in the past (as it would fit into the infrastructure), however, it was rejected on the premise that 2.1 quadrillion units is sufficient for the next year or so.

Yeah, I can see why such a change in the current design would be considered low priority, I just can't understand why 8 decimal places instead of 11 were chosen in the initial design.  Seems like a rather rookie mistake.

[dree12]

skateboards, oranges

No.  Once you get down to a single skateboard (or orange), you really can't divide it any further and still have it be useful as a skateboard (or orange).

Fair point. But my point still stands; Bitcoin as we know it is finite. A future version that divides it further is a blockchain fork and is not Bitcoin as we know it today.

. . . the current precision seems like a design flaw . . . It seems that in the initial design it would have made more sense to have 11 decimal places.  Then the maximum output in a transaction would be 92,233,720.36854775807 (92 million) . . .

I've lobbied for the creation of three more decimal places in the past (as it would fit into the infrastructure), however, it was rejected on the premise that 2.1 quadrillion units is sufficient for the next year or so.

Yeah, I can see why such a change in the current design would be considered low priority, I just can't understand why 8 decimal places instead of 11 were chosen in the initial design.  Seems like a rather rookie mistake.

8 was probably chosen because nobody really cared about it back then. Bitcoin was supposedly designed with the average CPU miner mining 50 BTC a day in mind.

[CoinDiver]

I look at the price of BTC as this equation:

Utility/Availability = Price

Don't try to quantify them, who cares. What is important is the rate of increase. Isolating the reward rate's effect on availability, currently at +50BTC/10 minutes. Without an increase in utility, the currently would be slowly inflating, and the price would drop accordingly. Since it's not, we can assume the increase in utility is matching (if the price is stagnant) our outpacing (if the price is rising) the increase in availability. So what happens when you cut the rate of increase of availability without changing the rate of increase of utility? You get a raise in the rate of the price increase.

Of course, that's all without speculation. A fair number of people seem to think the price is going to magically go up. Without the speculation, that is obviously not the case. What you can almost always count on though, is individuals being somewhat sane, and masses being somewhat insane. Expect rational individuals to react to the actions of the irrational masses. If people expect the prices to go up, the prices will go up. If people expect, people to expect the price to go up, the price will get capped by sell orders.

My prediction: Expect prices to fluctuate the day it halves, but to come out the other end basically unchanged or slightly up. Afterwards, I would expect a dip as people sell due to the disappointment in the rise. That followed by a increase in the historic rate of rise of BTC.

(I define "Utility" as the number of people using BTC x how much it is used... basically the total utility of BTC as a whole. Availability is the total amount of BTC available for exchange. Not just on the markets for fiat, but also those BTC being used in transactions for goods and services.)

[kjj]

Also, they're not infinitely divisible, but only down to a minimum of eight decimal places (0.00000001).

The current client only divides them down to eight decimal places, but there is nothing in the protocol that prevents them from being divided further.  If the need should arise, they could be divided further by upgrading the client program. They are essentially infinitely divisible.

Well, there would need to be a hard fork.

What really happens is that the tx_out contains a field of int64_t with the value in protocol units (a satoshi currently).  I think that much more likely than adding 3 more places and keeping int64_t, we'll go to int128_t and add a whole bunch more places.  Either way, it would require bumping the transaction version number, and that would break all old clients (more or less, I don't remember off the top of my head if that is a hard fork or not, I think it is, but even if it isn't, it would still mess them up pretty bad).

It is actually a good thing that int64_t has a lot of headroom above the maximum number of coins that can ever exist.  It means that we can still use 64 bit math to do (exact) accounting of value denominated in satoshis.  For example, at current market prices, we could do accounting for a 400+ billion USD entity in bitcoin before we have to start worrying about running out of bits.