Average blocks per hour is way more than 6

[grondilu]

I thought the target blocks creation rate was 6 blocks/hour.

On bitcoinwatch.com I see that it is usually 9 or more.

Is there something wrong about that ?

[1714018748]

1714018748

[1714018748]

1714018748

[db]

People bringing large amounts of additional hashing power to the network probably wait until just after difficulty adjustments to get the most out of it.

[caveden]

Since I know bitcoin watch, every time I access it the average blocks per hour counter is closer to 10 than 6.

[ShadowOfHarbringer]

Since I know bitcoin watch, every time I access it the average blocks per hour counter is closer to 10 than 6.

So if the block generation speed will keep accelerating in current manner, does that mean that number of bitcoins will actually rise 50% faster than it should in theory ?

And can this be prevented by a release of an updated client ?

[m0mchil]

Difficulty adjustment will take place in less than 300 blocks.

[ribuck]

...does that mean that number of bitcoins will actually rise 50% faster than it should in theory ?

Not really. The number of bitcoins is increasing exactly as it should in theory.

Bitcoin's rules say that 6 blocks per hour is the target rate used for difficulty adjustments. The rules don't (and can't) say anything about what the average number of blocks per hour will be.

However, the "Total bitcoins over time" graph (at the Wiki) will need to be tweaked now and then to keep it in step with reality.
http://www.bitcoin.org/wiki/lib/exe/detail.php?id=bitcoins&media=total_bitcoins_over_time_graph.png

[FreeMoney]

People bringing large amounts of additional hashing power to the network probably wait until just after difficulty adjustments to get the most out of it.

No. Why would they be ready, but wait until it would be harder to generate?

What happens is that generating power is increasing all the time so the power at the end of a period is always higher than the average for the period, so difficulty resets to the point where the average generation from last period would make it 6/hr, but we are always higher than that so even at the beginning we are above 6/hr. This will last at least until bitcoin commerce has saturated the globe :-)

Any guesses as to how soon blocks will drop to 25 coins? Does anyone have the date of first generation?

[FlyingMoose]

I thought the transitions were based on the block number, not actually the number of weeks, so wouldn't this faster generation speed up the new timeline?  I saw that the time for the adjustment was given as a block number and not as a date.

[ribuck]

Does anyone have the date of first generation?

3 January 2009

[FreeMoney]

I thought the transitions were based on the block number, not actually the number of weeks, so wouldn't this faster generation speed up the new timeline?  I saw that the time for the adjustment was given as a block number and not as a date.

Yes, it is based on the block number. I was asking just to get an idea of how fast it has been going long term.

[grondilu]

Yes, it is based on the block number. I was asking just to get an idea of how fast it has been going long term.

Every 210,000 blocks.  It should be about every 4 years.

[jgarzik]

I thought the transitions were based on the block number, not actually the number of weeks, so wouldn't this faster generation speed up the new timeline?  I saw that the time for the adjustment was given as a block number and not as a date.

Yes, it is based on the block number. I was asking just to get an idea of how fast it has been going long term.

The transition is based on a wall-clock time span.  It looks at the timestamp in each block.  See GetNextWorkRequired() in main.cpp.

[FreeMoney]

I thought the transitions were based on the block number, not actually the number of weeks, so wouldn't this faster generation speed up the new timeline?  I saw that the time for the adjustment was given as a block number and not as a date.

Yes, it is based on the block number. I was asking just to get an idea of how fast it has been going long term.

The transition is based on a wall-clock time span.  It looks at the timestamp in each block.  See GetNextWorkRequired() in main.cpp.

Wait, are you saying reducing the coin per block award is not block number based?

[jgarzik]

I thought the transitions were based on the block number, not actually the number of weeks, so wouldn't this faster generation speed up the new timeline?  I saw that the time for the adjustment was given as a block number and not as a date.

Yes, it is based on the block number. I was asking just to get an idea of how fast it has been going long term.

The transition is based on a wall-clock time span.  It looks at the timestamp in each block.  See GetNextWorkRequired() in main.cpp.

Wait, are you saying reducing the coin per block award is not block number based?

Yeah, you're right.  My apologies, I thought the difficulty transition was being discussed, rather than the transition to 25 BTC blocks.

[FlyingMoose]

I thought the transitions were based on the block number, not actually the number of weeks, so wouldn't this faster generation speed up the new timeline?  I saw that the time for the adjustment was given as a block number and not as a date.

Yes, it is based on the block number. I was asking just to get an idea of how fast it has been going long term.

The transition is based on a wall-clock time span.  It looks at the timestamp in each block.  See GetNextWorkRequired() in main.cpp.

Wait, are you saying reducing the coin per block award is not block number based?

Yeah, you're right.  My apologies, I thought the difficulty transition was being discussed, rather than the transition to 25 BTC blocks.

I *was* talking about the difficulty transition.  I saw it listed as "90,7xx" blocks somewhere on the forum.

[MoonShadow]

Yeah, you're right.  My apologies, I thought the difficulty transition was being discussed, rather than the transition to 25 BTC blocks.

I *was* talking about the difficulty transition.  I saw it listed as "90,7xx" blocks somewhere on the forum.

The retarget occurs at a specific block, not at a specific time.  The difficulty is then adjusted in order to attempt to stretch out the block generation over the next 2016 blocks to a full two weeks.  As far as I know, we have yet to actually hit those full two weeks since at least March, 2009.  The transition to a 25 coin block reward will occur before the fourth anniversary if the current trend continues.

[FlyingMoose]

So what would happen if someone with massive computing power (say, a supercomputer or custom hardware) slammed the network for 2016 blocks, and then stopped?

Would the difficulty adjustment make the next 2016 blocks possibly take months or years to process?  (just a possible type of DOS that someone with a supercomputer might do).  Something like this might happen when the bonus per block goes down to 25, a bunch of people might take their hardware offline because it's not profitable, so it could take a long time for the difficulty to readjust.

[MoonShadow]

So what would happen if someone with massive computing power (say, a supercomputer or custom hardware) slammed the network for 2016 blocks, and then stopped?

Would the difficulty adjustment make the next 2016 blocks possibly take months or years to process?  (just a possible type of DOS that someone with a supercomputer might do).  Something like this might happen when the bonus per block goes down to 25, a bunch of people might take their hardware offline because it's not profitable, so it could take a long time for the difficulty to readjust.

There is also an adjustment limit to impede just this kind of thing.  The difficulty is not permitted to adjust more than 4 times up or down (one-fourth) in a single adjustment.  So if an attack such as this were to happen, the worst that could be done by an attacker with limited access to supercomputing level resources is to extend the two weeks to eight weeks; and even this would require some serious firepower, considering the current difficulty implies that the network is already supercomputer class on it's own.  In order to do more, the attacker would have to be willing and able to dominate the network for two or more adjustments.  We are talking nation-state level capabilities right now, and at the rate of current increases, it will not be long before most nation-states wouldn't have that kind of collective power at their singular command.

Even if this were to occur, the current generation isn't likely to just stop.  Most generation doesn't occur with profit as the primary motive, as it's already not strictly profitable for the vast majority of people.  As I have noted before in other threads, much generation is 'co-generation', allowing the user to put their computer to good use heating their living space, for people who do not have access to cheaper forms of heat than electro-resistive heating.  Also, under your scenario, as others drop out for fear of an impossible difficulty, the odds that any one particular machine will find the next solution increases; so it's a self-regulating system.  I can't say that no one will ever try it, but it's not going to break the network, and anyone who would try it is going to have to commit some serious resources simply to temporarily frustrate the network.