its possible to construct a transaction that takes up almost 1MB of space and which takes 30 seconds or more to validate on a modern computer (blocks containing such transactions have been mined). In 2MB blocks, a 2MB transaction can be constructed that may take over 10 minutes to validate which opens up dangerous denial-of-service attack vectors. Other lines of code would need to be changed to prevent these problems.
sauceThis is a known protocol design bug: signatures were defined in such a way that the cost of validating a transaction with N signatures is proportional to N
2 rather than N.
It has a known simple solution: limit the number of inputs of a transaction to some reasonable value, say 20 or 100, independent of the block size limit. That will keep the cost of verifying one transaction bounded, and will inconvenience only a few users, by forcing them to break any big transaction into a chain of smaller ones.
IIRC, BiotcoinXT included this simple solution. Hopefully it will be included in Classic too.
XT simply made a more accurate count of the number of ECDSA ops to validate the block,( and put a proportional limit on this), but more importantly estimated the amount of *data* needed to do so. This is where the real performance hit was - the block quoted took 1.2Gb to store the hashes.
An average single core cpu can do around 10K sig hashes per second with libsecp258, so sigops in of themselves is not the issue.
So it limited sigops to 80k for a 8mb block, but crucially, limited no. of bytes needed to calc. sig hashes ( up to 1.3Gb for an 8mb block) where
previously this was unlimited.
These are not difficult problems to solve. There just needs to be a will. I think core much rather keep the problem so they can point to it and say "Look what will happen!!"