Yes, you can easily change the code to modify the coin-introduction function.

However, if you did, all your blocks would be ignored by people that use the original client, and more importably, you'd ignore theirs, effectively separating you in a different network with all those who run your modified client.

What guarantees are there that the supply will be limited? The fact that the community has agreed on accepting bitcoin's rules, which dictate how many coins are introduced.

To be clear, not anyone could do it. It would have to be the core developers who make the decision to do that, as they are the only ones that, in general can release/approve any code updates without forking the blockchain. The problem is, this change would be so dramatic and controversial, it's likely to fork the blockchain anyway, and throw the entire project into chaos. X% of people would whole-heartedly disagree, and fork the project with the original code and original philosophy. 100%-X% would just follow the core developers and go with it. I believe that this would cause all sorts of controversy, and frustration, and loss of morale among BTC supporters. It would probably start a downward spiral of BTC. I assume X > 10.

Only with an extraordinary level of "consensus," whatever that means, could the developers make such a drastic change and keep the unanimous support of the current user base. The problem is, there's not really a way to get a consensus. Even if the software design was truly a democratic process, there's no way to know what users would agree to do. I think the only way for Bitcoin to continue is with the core philosophical elements intact.

Other people have decided they don't like the way BTC works, and have made their own forks (one of them, I forget which, uses constant inflation rate). But to date, none of them have attracted any significant portion of BTC users, and thus, the devs have no reason to believe this is a desirable change (plus, they'd have to believe in it themselves, first).

Sure they can. They just download the source, edit the function GetBlockValue() in main.cpp, and recompile. And if they only comment out the line that shifts nSubsidy, it'll still work fine for another 60,000 odd blocks.

Less than a full world economy, large enough to not promote too much hoarding... My guess is a integer value is 2.1billion, and with the decimal shift maybe that has some significance but I also know that the storage is double integer so it should support trillions easily.

I don't think Satoshi ever really said in the documents his personal reason for choosing the number?

What was the original thinking behind 21 million bitcoins? Why is that number magical?

It's not magical, it's "just some number to limit the supply". The number itself doesn't mean anything.

Bitcoin Core developer [PGP]Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.

The market would decide - the bitcoin block chain would fork and you could choose to go with the new fork or stick with the old one. If you have bitcoins you would almost certainly stick with the original one.

The market would decide - the bitcoin block chain would fork and you could choose to go with the new fork or stick with the old one. If you have bitcoins you would almost certainly stick with the original one.

I see what you're saying. Seems like a design flaw when you look at future acceptance. With multiple block chains wouldn't every vendor at that time need to then accept 2 or more systems of exchange with different rates? I can see why there would be a fight at that time to leave the system alone but can also see the need to make a decision to change it now while it can have a more limited effect.

This is why there won't be multiple chains. And also why we don't have to worry much about the rules changing.

The market would decide - the bitcoin block chain would fork and you could choose to go with the new fork or stick with the old one. If you have bitcoins you would almost certainly stick with the original one.

I see what you're saying. Seems like a design flaw when you look at future acceptance. With multiple block chains wouldn't every vendor at that time need to then accept 2 or more systems of exchange with different rates? I can see why there would be a fight at that time to leave the system alone but can also see the need to make a decision to change it now while it can have a more limited effect.

Exactly - no merchant would want to change, so the new fork would be useless.

Thanks, I thought there was some deep hidden reason. If that's the case then I understand the OP's question and have one of my own.

If bitcoin did become widely accepted at some point in time it would then be possible to increase the supply of btc based on demand instead of simply relying on shifting the base-10 numeral system down another decimal fraction (i.e. printing more money). Yes?

Yes, it would be possible to increase the supply. If you can convince the majority to accept it.

Are you suggesting that shifting the decimal point is the same as printing more money? Because it's not. It's cutting the same pie into smaller pieces. The larger pieces still exist and still have the same value.

No, I was suggesting increasing the supply of btc was increasing the money supply instead of just shifting the decimal. It seems clumsy to have say a billion people worldwide sharing the use of 21 Million coins but that's obviously a long way off.

A billion people worldwide will be sharing 2,099,999,997,690,000 satoshis, so it's no problem at all.

There are only 982 billions USD hard currency in existence currently, and yet the world seems to function fine upon it.

If you have bitcoins you would almost certainly stick with the original one.

Yup -- that is the winning answer. Changes that work in the favor of those who hold the already-issued bitcoins are possible if enough of those users accept the changes. Changes that would harm the value of those existing bitcoin users would likely not get adopted and would stay as an unused fork.

There are at least two examples of changes occurring and being adopted.

Another example is with Namecoin merged mining. That is a change that requires buy-in from existing namecoin users (i.e., to use the new client that changes the rules). If merged mining was rejected by those holding namecoins, the change would simply be a fork with few or no users as the namecoins issued or used in trade on the fork would not be accepted by those earlier users.

Your specific question of issuing a greater amount of currency is a change that be harmful to those holding bitcoins (it would devalue their holdings) and therefore it is unlikely that change would be accepted.

Thanks, I thought there was some deep hidden reason. If that's the case then I understand the OP's question and have one of my own.

If bitcoin did become widely accepted at some point in time it would then be possible to increase the supply of btc based on demand instead of simply relying on shifting the base-10 numeral system down another decimal fraction (i.e. printing more money). Yes?

Let me sum up for you what would happen in short IF the developers increased the money supply:

1. The blockchain would split into the NEW chain (with more inflation) and the OLD chain (with unchanged inflation)2. Most of people, including me, would abandon the NEW chain and go back to OLD chain3. Bitcoins from the NEW chain would enter a downward spiral until they would become worthless

Seriously, who would want to be robbed ? And that is exactly what increased inflation is - common thievery.

I'm reading about the problems if the limit is higher but this same reasons seem to work fine for a greedy community if they decide to lower the limit to 18000000 or what ever number. If business people starts to use it as a deposit for value and price really moves upwards, this limit change could be moved on, lets suppose automatic upgrade feature is installed and widely adopted, and so this could work for some days before everythings falls having made some really rich and all the others really poor.

I'm reading about the problems if the limit is higher but this same reasons seem to work fine for a greedy community if they decide to lower the limit to 18000000 or what ever number.

When I participate, I know the rules -- 50 BTC / block every 10 minutes, 21 million total, etc. Now if there were a fork with a change like that which only favors those who already hold the coins then that would, to me, be an unacceptable breach and I would either only trade with the client that doesn't include that change or would abandon bitcoin at that point. I would probably not be alone with that decision, and thus the value of bitcoin would be harmed. I couldnt see that happening.

lets suppose automatic upgrade feature is installed and widely adopted, and so this could work for some days

Having an auto-upgrade for the Bitcoin client would not be a good idea.

It might be a good idea for the downloadable reference client (opt-out of course), although obviously not for mining platforms that enforce the security of the network.

I am in greater fear of an attacker finding a flaw in the client software and continuing to exploit unpatched nodes than, say, Gavin's keys being compromised and a fake update (with a back door) being issued.

But for that reason I don't expect automatic updates would never be implemented. If you fail to patch your software, it's your fault. OTOH, if Gavin's keys are compromised one could make the case of (criminal?) negligence against him.

I'm an independent developer working on bitcoin-core, making my living off community donations.If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP

lets suppose automatic upgrade feature is installed and widely adopted, and so this could work for some days

Having an auto-upgrade for the Bitcoin client would not be a good idea.

It might be a good idea for the downloadable reference client (opt-out of course), although obviously not for mining platforms that enforce the security of the network.

Having an automatic update feature opens a whole world of possible security breaches and it could potentially damage the network.

Consider the following scenario:

1. Automatic update servers are cracked, 2. Depending on the attacker (casual thief or government) a trojan OR modifiied client is planted in place of the legitimate client3. 80% of users download the fake client

Now, there are 2 options:4a. The hacker steals wallets of 80 percent of the bitcoin users. OR4b. The hacker uses the modified client to damage the network, split chains, implant child pornography into chain or whatever else

5. ?? ??6. PROFIT !

Such damage could be fatal to the network and could actually destroy the people's faith in the currency.

So no, having an automatic update feature is definately NOT a good idea.

We may discover that the hashing power of BTC drops once inflation slows or ends, and the whole tx fee thing doesn't support enough hashing power to make all us BTC holders feel secure from a 51% attack. Thus to incentivize more mining, we may slow the inflation rate to something small, i dunno maybe 1%/year or so. Would still make BTC a very strong currency, but also keep blocks clipping along.

Maybe this is off topic. But why don't they change the block generation from 50 BTC every 10 minutes to 5 BTC every minute? That would cut the tx time and quicken the flow of confirms. I know some of the alt chains tried this. Does it work, and why can't we do this with the mainline client?