...mit would be raised, but the discussions about whether it would be raised at all with opposition from a significant amount of people. That turned the idea of raising the limit into a complete non-starter since it requires a hard fork, despite the fact that changing the maximum block size has been the plan since the very beginning. ...
Do you have anything by way of actual evidence of this? Not that I do or don't believe it, but it is easy and common on this forum for people to pull shit like this right out of their ass.
Why did the limit get set as it is knowing that it was going to be a nightmare if/when it ever was to be changed (if you have any real clue?)
That realization about the impossibility of raising the maximum block size via a hard fork worried me enough to the point where I actually think that my statement that it would require a hard fork might be wrong.
![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
But seriously, I think that I've come up with a soft-fork version of accomplishing the same thing. A soft-fork would allow us to deploy the rules for increasing the maximum block size in less then a month instead of several years, assuming it was coded ahead of time and it was considered extremely high priority. It's a terrible hack job, but to the users it would be fairly seamless. Not to give too much away just yet, but it'll be fully backwards compatible functionality wise down to version 0.6.0. I'll post the technical details in the next few days.