Quote from: tokeweed on June 20, 2015, 01:13:55 AM

He was being sarcastic...? Is Jon Matonis against the hard fork? If he is, he's trying to say Gavin's move is a precursor to a shit storm coming in BTC land.

If XT succeeds, increasing the 21m cap would not seem farfetched. At least in his eyes.

Would someone who was once the Director of the Bitcoin Foundation really think that the two are even remotely comparable? Because the differences between the two proposals are enormous. Satoshi always intended for the block size limit to be increased at some point in the future. That was always part of Bitcoin's design and it was never a question of "if" but "when". That the majority of miners would someday support a hard fork that aims to increase the max block size is to be expected:

Quote from: satoshi

The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.

Link: http://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html

Arbitrarily increasing the total number of coins changes a fundamental aspect of what Bitcoin is and Satoshi's comments make it clear that such a thing would be very undesirable. Even if there is no centralized party trying to enforce a fork, I find it unlikely that miners would accept the latter or even equate the two proposals as being anything remotely similar.

Quote from: knightdk on June 20, 2015, 03:38:05 AM

How, exactly, would such a change roll out? There is actually no point in the code (that I could find) that specifically imposes such a cap. The only thing that this cap comes from is the method which the block reward comes from, simply dividing by two. There is a point where the rounding used in the code simply returned zero, and that was when the block reward went to zero. This just so happens to be just under 21 million Bitcoin, which is likely just a coincidence, not a specifically hard coded thing.

It would be a hard fork that involves a change in the coin emission algorithm. You're correct that there is nowhere in the code that specifically calls for a max cap of 21 million coins. However, this number can be deduced by looking at the emission rate (50 BTC blocks every 10 minutes with a halving every ~4 years). Changing the specifics of the emission algorithm would change the maximum number of coins but to do so would require a hard fork.

Acceptance of the hard fork can be measured by looking at the proportion of miners who switch to the new chain. Most likely the chain would bifurcate since any proposal to change the maximum number of coins would be very controversial (to put it lightly), and you would have two chains on either side that exist independently of the other.