Quote from: acoindr on February 22, 2013, 08:16:13 PM

Quote from: tvbcof on February 22, 2013, 05:37:10 PM

...
I find it neither surprising nor unhealthy that the various primary developers have different ideas about what is important.
...

I agree. I call it free market forces check and balance.

Quote from: Zangelbert Bingledack on February 22, 2013, 06:14:03 PM

No hard fork will be introduced unless it's clear who will win.
...

Yes, that appears to be the case. I like Gavin's approach to upgrading:

Quote from: Gavin Andresen on February 20, 2013, 10:09:02 PM

A hard fork won't happen unless the vast super-majority of miners support it.

E.g. from my "how to handle upgrades" gist https://gist.github.com/gavinandresen/2355445

Quote

Example: increasing MAX_BLOCK_SIZE (a 'hard' blockchain split change)

Increasing the maximum block size beyond the current 1MB per block (perhaps changing it to a floating limit based on a multiple of the median size of the last few hundred blocks) is a likely future change to accomodate more transactions per block. A new maximum block size rule might be rolled out by:

New software creates blocks with a new block.version
Allow greater-than-MAX_BLOCK_SIZE blocks if their version is the new block.version or greater and 100% of the last 1000 blocks are new blocks. (51% of the last 100 blocks if on testnet)
100% of the last 1000 blocks is a straw-man; the actual criteria would probably be different (maybe something like block.timestamp is after 1-Jan-2015 and 99% of the last 2000 blocks are new-version), since this change means the first valid greater-than-MAX_BLOCK_SIZE-block immediately kicks anybody running old software off the main block chain.

This ensures consensus vote from the field.

If the approeach as described by Gavin, some concensus of 10%%~99% of the hashing power, then it should be able to maintain the confidence.
To me, the size itself is not the problem, it is the confidence that is the problem.