I suppose you forgot already why this thread started - we ran out of block space and transactions started stacking up, unconfirmed. This almost immediately caused lots of user complaints.
Exactly because people did NOT upgrade to Bitcoin 0.8 fast enough, which fixed the bug in 0.7 and below, now we are now back to square one - stuck with blocks that are too small to meet demand for transactions. Expect the complaints to start again soon unless filtering of SD becomes common.
The options I listed in my first post are still the only options. If you don't want to filter out SD transactions then the default "do nothing" option means that transactions will become very expensive, and small quantities of Bitcoin won't be spendable at all.
The fork is certainly a big problem: unfortunately, nobody realized it would happen. It's not even clear yet what kind of testing would have revealed this issue. Simply making big blocks is apparently not enough to trigger it. That said, we knew that BDB was generally a rats nest of weird problems which is one reason why I ported Bitcoin to LevelDB. If the block sizes had been raised a few months from now, we'd probably have just abandoned the 0.7 users to their fate, but we got unlucky with the timing.
Assuming we want Bitcoin to scale up, we'll have to fork 0.7 and lower off the chain sooner rather than later and then raise the block size limits again.
Users will not upgrade on your schedule, except very begrudingly! Yet, the sky is not falling. When the problem is better understood, it should be possible for miners to raise the soft block-size limits. When the actual limit in BDB that causes 0.7.x clients to fail a block is well understood, that condition needs to be added (by miners, only) to the 0.8 code they use to generate and verify a block. Then, after some testing and a gentle roll-out of bigger block sizes, that buys some breathing room. You can add a couple of factors of 2 in this manner, but it appears to me this won't keep up with SD's growth rate for long.
[As I currently understand it, the problem is thought to be a limit on the number of locks on the BDB database, which is in turn a function of the number of transactions in a block and/or the number of transactions referenced by a block, which is indirectly related to the size of a block.]
@all: Gamblers, have a different mindset than those who are engaged in commerce. Let's just call it entertainment, and not get too preachy. Gamblers will pay substantial fees for entertainment that those engaged in ordinary commerce will not (or cannot) pay. (15%-20%, typically, at a parimutuel US horse race; 40-50% at a typical US State lottery; 5% at American roulette; etc.) I don't think it is possible to raise the fees in a way that would make SD unprofitable, without raising the fees in a way that makes bitcoin unprofitable for many other economic purposes.