So, one very large transaction with numerous sigops leads to the quadratic growth. Hmm, so blindly increasing the block size is asking for trouble. How many of these troublesome transactions are launched against us recently? Or is it an unexploited vulnerability?
Perhaps we could increase the block size *and* constrain sigops/transaction until we get SegWit out the door?
Well the problem is only minor at a 1 MB block size limit.
Segwit should scale it down and make it linear. It should be released in April (from the initial estimates), so I don't see how you plan to deploy the block size limit and a sigops limitation in <2 months.
and now you see why a 2mb+segwit released in april with 6month grace is not a problem
i love it when lauda debunks his own doomsday scenario
having the 2mb block limit included in aprils release is easy. plus it incentivises more people to download the april version ensuring a real chance of no contention, instead of having upgrades every couple months EG march april july. which just mess with the community too much
That is a valid point. There is no reason why the code can't be in the April client, with miners only triggered to make the big blocks if there is both consensus (95%) *and* nearly full blocks.
That way if segwit does what we believe it will, the 2MB blocks never happen. But if number of transactions making it into blocks is large enough that even with segwit the blocks are full, the code is already in the clients.