The O(n^2) sigop attack cannot be mitigated with Electrum X or by simply buying a faster Xeon server.
As Gavin said, we need to move to Schnorr sigs to get (sub)linear sig validation time scaling.
And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.
Informed Bitcoiners like Adam Back and the rest of Core plan to do segwit first, because it pays off technical debt and thus strengthens the foundation necessary to support increased block sizes later.
As Gavin said, we need to move to Schnorr sigs to get (sub)linear sig validation time scaling.
And AFAIK moving to Schnorr sigs at minimum requires implementing Core's segwit soft fork.
Informed Bitcoiners like Adam Back and the rest of Core plan to do segwit first, because it pays off technical debt and thus strengthens the foundation necessary to support increased block sizes later.
So you are saying their Developer is not competent enough to find a solution.
I think if the Developer of electrum was actually worried about it , he would have mentioned it when asked point blank on the blocksize issue.
Electrum devs cannot change the fact Bitcoin uses Lamport sigs. As currently implemented, Lamport sig validation scales quadratically with tx size.
Nobody can fix that until we have segwit and may then change to Schnorr sigs.
Source:
Too sad, that science dictates to have SW first and than Schnorr... What a pity!