Why not adjust the block reward on every retarget?

[giszmo]

I know, I know, do a fork. That's not the point. I wonder if there is any good reason to change the block reward every 4 years rather than every retarget. Cutting it in half is so disruptive and causing so much discussions for most likely one year and it is actually making things more complicated than having the adjustment on every retarget. As we will learn a lot when it actually happens, traders will anticipate what we learned for the next retarget and render all predictions pointless opening up for discussing the effect again in 4 years for a year or so.

For this reward change the mining investments are done but maybe if all hell breaks loose this could be enough reason to think about smoothing things at the next reward change.

[bulanula]

Same as why 21 million ... because the Japanese Satoshi said so. He is god !

Because we like to see our coins double in fiat value.

Pyramid FTW !

Sorry but there is no explanation. It is just the way things are. Like the laws of physics.

Why is gravity 9.8 ? Because God ( Satoshi ) said it will be

Don't like the design create fork.

[FreeMoney]

Division by two is very simple and clear to code, that's something.

[evoorhees]

I really don't think the halving block reward in December will be very disruptive. All parties know A) that it will happen and B) when it will happen. Markets are very good at pricing in information that's widely known. It might cause a little volatility in one way or another, but it will be temporary and highly manageable.

[hazek]

Division by two is very simple and clear to code, that's something.

This, it's easy precise code..

I really don't think the halving block reward in December will be very disruptive. All parties know A) that it will happen and B) when it will happen. Markets are very good at pricing in information that's widely known. It might cause a little volatility in one way or another, but it will be temporary and highly manageable.

Precisely, because the information is completely public and available to everyone game theory suggest the market will price the reduction in before it will actually happen and the change wont be disruptive at all.

[giszmo]

Division by 2 every 200000 blocks is just as easy as division by 1.000003466 every block.

Markets being able to fix problem is no reason to cause them.

https://bitcointalk.org/?topic=7496.0

[Stephen Gornick]

I really don't think the halving block reward in December will be very disruptive.

To someone holding bitcoins, that is correct.

To a mining operator whose margins are marginal (e.g., paying average or above-average electric rates and mining using GPUs) or even mining profitably at these levels, the block halving will be brutal to GPU mining.  Like ... come block 210,000 it will be exit stage left, NAO!

Incidentally, by late fall FPGAs will probably already have pushed those GPU mining to make plans to shut down GPUs at block 210,000.  If the ASICs start shipping before then, the date for exiting simply gets pulled forward a matter of weeks is all.

[John Kirk]

Division by 2 every 200000 blocks is just as easy as division by 1.000003466 every block.

No, it isn't.

You forget that Bitcoins are only divisible down to 8 decimal places. When the reward gets small enough, dividing it by 1.000003466 is equivalent to dividing by 1.00000. In other words, the reward would stop getting smaller and the eventual number of Bitcoins generated would no longer be limited to 21 million(ish).

On the other hand, on any binary computer, division by 2 is identical to performing a right bit-shift. For example, the bit pattern for 50 Bitcoins is represented in binary as:

0000 0000 0000 0000 0001 0011 1000 1000 0000 0000 0000 0000 0000 0000 0000 0000

The bit pattern for 25 Bitcoins is represented as

0000 0000 0000 0000 0000 1001 1100 0100 0000 0000 0000 0000 0000 0000 0000 0000

Note that the only difference is that there is one less zero on the right and one more zero on the left. Thus, the bits have been moved, or shifted, over by one place.

A right bit-shift always guarantees that the output is smaller than the input.  Because of this, when the reward is 1 satoshi:

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001

and it is time to lower it further, the code will perform a right bit-shift on that value, which will result in a reward of zero:

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Thus, no more Bitcoins will ever be generated. This is no mistake. Satoshi knew what he was doing.

[foo]

A right bit-shift always guarantees that the output is smaller than the input.  Because of this, when the reward is 1 satoshi:

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001

and it is time to lower it further, the code will perform a right bit-shift on that value, which will result in a reward of zero:

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Thus, no more Bitcoins will ever be generated. This is no mistake. Satoshi knew what he was doing.

...and in case anyone is wondering, this will happen approximately in the year 2140.

[giszmo]

Division by 2 every 200000 blocks is just as easy as division by 1.000003466 every block.

No, it isn't.

You forget that Bitcoins are only divisible down to 8 decimal places. When the reward gets small enough, dividing it by 1.000003466 is equivalent to dividing by 1.00000. In other words, the reward would stop getting smaller and the eventual number of Bitcoins generated would no longer be limited to 21 million(ish).

On the other hand, on any binary computer, division by 2 is identical to performing a right bit-shift. For example, the bit pattern for 50 Bitcoins is represented in binary as:

0000 0000 0000 0000 0001 0011 1000 1000 0000 0000 0000 0000 0000 0000 0000 0000

The bit pattern for 25 Bitcoins is represented as

0000 0000 0000 0000 0000 1001 1100 0100 0000 0000 0000 0000 0000 0000 0000 0000

Note that the only difference is that there is one less zero on the right and one more zero on the left. Thus, the bits have been moved, or shifted, over by one place.

A right bit-shift always guarantees that the output is smaller than the input.  Because of this, when the reward is 1 satoshi:

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001

and it is time to lower it further, the code will perform a right bit-shift on that value, which will result in a reward of zero:

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Thus, no more Bitcoins will ever be generated. This is no mistake. Satoshi knew what he was doing.

Of course it is not smart to do
reward=reward*x long before the result equals the input
You would rather implement it like
reward=50BTC*(pow(x,blockId))

This adds dramatic complexity to the Bitcoin client

[wabber]

Why is gravity 9.8 ? Because God ( Satoshi ) said it will be

nah it's because of the mass and the size of the earth

[phelix]

it is so we have a date to celebrate 

[Meni Rosenfeld]

Of course it is not smart to do
reward=reward*x long before the result equals the input
You would rather implement it like
reward=50BTC*(pow(x,blockId))

This adds dramatic complexity to the Bitcoin client

Floating-point operations are inherently inexact, making the amount of bitcoins generated dependent on them is just asking for trouble. If anything it would be better to make integer multiplication/division once every several blocks.

Discontinuously diminishing block rewards is less mathematically elegant, but much simpler. The disruption it will cause is fairly minor.

You may also be interested in http://bitcoin.stackexchange.com/questions/1526/what-are-the-advantages-disadvantages-of-a-continuously-decreasing-block-reward.

EDIT: To improve accuracy when doing decay for every block, work by BTC remaining, not by BTC for this block. That is, in the beginning there are 2,100,000,000,000,000 satoshis remaining. In every block, multiply the amount remaining by 1120732551094 and divide by 1120736250303. The block reward will be the difference between the current remaining amount and the previous remaining amount. This ensures that exactly 2,100,000,000,000,000 satoshis total will be paid. It also means, though, that decay will be faster than intended when the rounding starts being significant, but by then we may move to a finer division than satoshis.

To a mining operator whose margins are marginal (e.g., paying average or above-average electric rates and mining using GPUs) or even mining profitably at these levels, the block halving will be brutal to GPU mining.  Like ... come block 210,000 it will be exit stage left, NAO!

Any GPU miner will pull out sooner or later, does it matter if they do it one by one or many of them at once? Besides, people (should) take into account the future halving in current hardware purchase decisions, and variations in electricity costs mean that the halving alone won't cause everyone to quit.

[JoelKatz]

Actually, it could have been done without too much difficulty. The trick would simply be to select two integers 'a' and 'b' correctly and then doing this at each difficulty adjustment:

blockReward = (blockReward * a) / b;

Integer math is used, so the results are exact. With a bit of care, 'a' and 'b' could be selected such that the total number of bitcoins produced is still well-known in advance and still very close to 21 million and still takes about the same amount of time. While an integer multiplication and division do take longer than a shift, they're trivial compared to the many other operations that have to be performed on every single block, and this is only done on each retarget.

Most likely, a solution could be found with 'b' being a power of two. So at least the division would just be shift.

[Kupsi]

In a few years, before the halving from 12.5 to 6.25 is my guess, transaction fees will be larger than the block reward. After that, the block reward halving will not make a big impact any longer.

[Technomage]

The reward drop is no more disruptive to a miner than it is to any Bitcoin user. Miners can price in the drop in their own mining profitability calculations just as well.

[Meni Rosenfeld]

Actually, it could have been done without too much difficulty. The trick would simply be to select two integers 'a' and 'b' correctly and then doing this at each difficulty adjustment:

blockReward = (blockReward * a) / b;

Integer math is used, so the results are exact. With a bit of care, 'a' and 'b' could be selected such that the total number of bitcoins produced is still well-known in advance and still very close to 21 million and still takes about the same amount of time. While an integer multiplication and division do take longer than a shift, they're trivial compared to the many other operations that have to be performed on every single block, and this is only done on each retarget.

Most likely, a solution could be found with 'b' being a power of two. So at least the division would just be shift.

You can use for example a=39455940911, b=39719364610 or a=1172761792249825816554, b=2^70. If you require b to be a power of 2, a needs to be much higher to obtain the same accuracy, so you don't really gain much.

Anyway, as I mentioned it's more accurate to work with satoshis remaining.