Quote from: chrisrico on March 12, 2013, 06:46:44 AM

Quote from: Blowfeld on March 12, 2013, 06:45:01 AM

It *was* indirectly because of the size of the block. Even at 166 bytes each (or whatever the minimum size of transaction), a 250K block cannot contain 1700+ transactions. And a number of transactions that exceeds the BDB configuration is believed to be the root of the problem. I know hindsight is 20/20, but I will give the developers credit and assume testing all extremes from 1 really big transaction to many really tiny transactions probably would have been in a formal release cycle. No such testing was done, chiefly because this was an off the cuff suggestion, not a formal release.

The problem is with the old version, and is a previously unknown bug. Are you saying the developers should have thought to test the old version for an unknown bug before releasing the new version?

It is quite normal, when developing a complex system, that a new release must maintain compatibility with some of the "bugs" that were present in the old release. I believe the developers of bitcoin follow that philosophy. By definition, a *unexpected* difference in behavior between the old client and the new client is a bug in the new client.

I believe if the developers had decided to raise the blocksize before releasing 0.8, they may have found this bug during their testing. The problem is that NO FORMAL TESTING was performed before the lead developer's suggestion was taken to heart by several mining pools. Don't ask your "customers" to do X, unless you have tested that doing X causes no harm. As someone else already pointed out on this thread, the development team was well aware that changing to a new database was a possible source of trouble. I will give the developers credit and assume they tested thoroughly. So I repeat, if the blocksize had been raised *before* the official release of 0.8, at least there would have been a chance of detecting the difference in behavior, and thus a chance of avoiding this fork.