Quote from: Jeweller on January 31, 2013, 07:23:52 AM

Certainly from a software engineering point of view, medium-term scalability is a trivial problem. An extra zero in the

Code:

static const unsigned int MAX_BLOCK_SIZE = 1000000;

line would be fine for a good while.

Yes please, 10 megabyte per block is the right answer.

Also 100 MB may be considered in the future, but for some users it would be lots of traffic these days.
Also it would be nice to have the old tx pruning function some day as the database starts growing faster.

Quote from: Jeweller on January 31, 2013, 07:23:52 AM

So... what happens then? What is the method for implementing a hard fork? No precedent, right? Do we have a meeting? With who? Vote? Ultimately its the miners that get to decide, right? What if the miners like the 1MB limit, because they think the imposed scarcity of blockchain space will lead to higher transaction fees, and more bitcoin for them? How do we decide on these things when nobody is really in charge? Is a fork really going to happen at all?

Actually there is a hard fork in progress right now: there is a database locking glitch in <=v0.7.2 so everyone needs to upgrade to v0.8.1 by 15/May/2013.

Increasing block size does not seem significantly different.
First there is selected a block number from which the increased block size applies. For example block >=261840 which is expected around Oct 2013.
Then - few months before Oct 2013 - this logic is implemented in the full-node clients - Satoshi client, bitcoinj, ... - and people are asked to upgrade, or have their old clients stop working after Oct 2013.
That's all.