Quote from: I-am-not-anonymous on February 18, 2010, 07:36:51 AM

Quote from: Suggester on February 18, 2010, 07:12:50 AM

Every four years, the average BTC generator will need to spend double the effort to create the same amount of coins.

As I understood it people will not need to double their CPU power to get the same amount of coins, rather there'd be half as many coins "up for grabs" by anybody with enough CPU power.

In other words, let's say a Powerful CPU can pull in 500 coins a day and a weaker CPU can pull in 300 coins per day from a pool of 10,500,000.

After 4 years, they are still pulling in 500 coins and 300 coins respectively, but now they can only access a pool of 5,250,000.

I could be wrong though. Somebody who know what they're talking about please comment instead of me!

The plan is to halve the value of the block every four years. So if your PC is making 6 blocks/day now (i.e 300 BTC/day), in 4 years it could be also be making 6 blocks/day, but your balance will only increase by 150 because the block would equal 25 instead of 50 BTCs

Edit 24 May 2011: These are the removed paragraphs from the original 2010 first post. They are obsolete and no longer relevant as the post is now heavily edited. Nevertheless I thought I'd include them for anyone who wishes to understand the full context of the 2010 discussion (up to page 7).

So what's the solution? Well, as you might have already guessed, we should remove both the 4-years interval thing and the 21M limit. Just let BTCs continue to be created forever at a constant rate*. The rate should be divisible enough to give up to, say, 100,000 people an incentive to run the network simultaneously. In other words, the current 144 daily blocks (or units) aren't enough because this means that @ 100,000 users, one has to wait an average of 757.6 days (that's 2+ years) to see something pop up on his screen. 100k is an arbitrary figure, but remember that we need to mobilize as many nodes as possible to resist the tampering attempts of supercomputer-owning governments who can and will try to generate their own proof of work to ruin the project if it ever reaches mainstream. Also note that this will not lead to inflation in the foreseeable future, because the user base of bitcoin will continue to grow for years to come, let alone natural economic and population growth (unless the Mayans turn out to be right, of course).

This way, when the number of bitcoin-generating nodes approaches stability, we will end up with a slowly-growing number of bitcoins matching a slowly-growing number of nodes, resulting in the currency's relative price stability, leading in turn to the ultimate goal of it being used for exchange purposes.

Now for the fun part, a numerical example: If the system is producing 10k bitcoins/day at a constant rate (with difficulty adjusted by collective CPU power just like it is now), and the number of users attempting to generate BTCs was 10k after 1,000 days from now, and increasing at a constant rate of 10 new users/day, we will have and continue to have an average of 1,000 BTCs/user. No inflation, no deflation, no incentive to hoard BTCs, and no incentive to spend BTCs quickly (though that wouldn't necessarily be a bad thing!). Remember that we can always add or remove zero's if the numbers turned out to be awkward at some point, like Germany did in the 1920's hyper-inflation. Note that under this model, an initial price surge is inevitable because the number of nodes increases at abnormal rates at the project's beginning. As the project matures, there would be only reasonable user-base increases, so the price won't fluctuate much any longer (think the percentage increase in newly opened email accounts from 2000 to 2001 vs from 2020 to 2021, for example).

*Another idea would be to set the BTCs creation's difficulty irrelevant of total CPU power in the network so that, say, the average computer would create 1 BTC/day. The global price would then automatically adjust to the participants' average electricity and machine consumption cost. It would be sort of like buying some electricity from the utilities company and loading it on your machine as transferable BTCs. If electricity happens to be cheapest in India, Indians will initially profit from creating BTCs, but as their proportion among the nodes increases, the BTCs price will decrease as it approaches India's average electricity cost. Exchangers will quickly balance supply and demand just as in ForEx fluctuations, Econ 101, remember? Non-Indians would purchase BTCs from Indian exchangers at a very small profit margin because of competition. I personally prefer this model to the constant rate one because the amount of BTCs in circulation would generally be proportionate to the amount of users (sort of like farming gold in MMORPGs), instead of picking an arbitrary constant figure and letting users adjust to it. Thus this model avoids the initial price surge because there will be a balance from day one.

Admittedly, BTCs' price would be tied to energy's under this model. But then again, this is also the case in both my other and the current model. Besides, using Bitcoin for casual quick transfers (rather than as savings) would virtually eliminate this risk. Also granted that creating zillions of BTCs (eg. via governmental sabotage) would lead to inflation in this case if they flood the market with cheap coins, but then again this problem exists in the other two models as well, and can also be avoided by those using the coin for transfers only. But whereas in the other two models a supercomputer-or-two can ruin the whole project by barring most of the honest nodes from creating coins (via controlling most of the CPU power and skyrocketing coin-generating needed effort), under this uber-flexible model everybody will be able to create some coins and use them for transfers regardless of sabotage attempts.