Quote from: piotr_n on March 12, 2013, 05:09:54 PM

Quote from: tvbcof on March 12, 2013, 05:04:40 PM

Quote from: Mike Hearn on March 12, 2013, 10:08:26 AM

...

Also, I'm afraid it's very easy to say "just test for longer" but the reason we started generating larger blocks is that we ran out of time. We ran out of block space and transactions started stacking up and not confirming (ie, Bitcoin broke for a lot of its users). Rolling back to the smaller blocks simply puts us out of the frying pan and back into the fire.

We will have to roll forward to 0.8 ASAP. There isn't any choice.

I would like to understand with better precision what you mean by this. Can you point to a particularly enlightening bit of documentation or discussion about this issue?

I believe he means that if you have a constant rate of 6 blocks/hour and a fixed number of the maximum transaction per block, when the number of transaction is going up they will eventually go above the limit and instead of being mined at the time when they are made, they are getting queued...
Which is exactly what I have been observing for the last few weeks - even transaction with proper fees are mined like hours later.

Bitcoin really needs to start handling bigger blocks - otherwise soon our transactions will need ages to get confirmed.
The network will get stuck if we stay at the limit.

So the solution is to continue to increase the block size as demand provokes this issue then? It does not strike me as a particularly good strategy for a lot of reasons. Among them, I can envision demand side growth growing exponentially and at a much faster rate than processing capacity can be developed even by highly capitalized and proficient entities.

The only up-side to this solution in the not to distant future only a handful of large entities will have problems because only they will be forming critical infrastructure part of the Bitcoin network. In fact it could be legitimately argued that we are already at that point due to the makeup of the mining pools. At the time of this last issue they seem cooperative and in favor of the dev team's desired 'fix'. Or at least the consensus of the current dev team. What happens in future 'events' will be interesting to observe.