Quote from: Mike Hearn on March 12, 2013, 08:09:33 AM

To be accurate, it wasn't "the lead developer" who suggested raising the block size limit, it was me. I am a Bitcoin developer, but Gavin is the lead. So you can blame me if you like.

Apologies to "the lead developer". I have amended my original post. That portion of my original post was not intended so much as to cast blame on an individual as to point out a fundamental flaw in the process that permitted an "off-the-cuff" remark to be taken seriously (and almost simultaneously) by many miners. I am a software developer, and I know what it is like to release upgrades to large legacy projects. [Yuck, usually.] Assuming you guys follow *some* process, a planned line-item in a scheduled release to increased the blocksize should have led to significant testing of that line-item.

Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork. (Early adopters of "big block 0.8 release" would have found they were generating blocks that quickly became orphans. There would have been no panic and no great urgency to solve the problem by fiat.)

[I'm not trying to second-guess the developers. It's always easy to see with 20/20 hindsight. But there should be a process. And the process should be followed.]

There are two lessons here:
1. Avoid off-the-cuff suggestions unless you *know* the impact is minor.
2. Where possible, roll out the tested releases gradually -- especially to mining pools, who have become so centralized, a few of them can easily tip the scales to 51%.