interestingly.
a native(legacy) tx of 4k txsigops is treated as 16k txsigops in core v0.14 due to the WITNESS_SCALE_FACTOR (which is 4x)
so to correct myself about worry of propagation delay, native(legacy) tx does not/cannot perform 16k actual CPU intensive sigops. its still only 4000 real CPU intensive operations(just treated as 16k after the fact purely for cludgy mathematics of filling the limit)
yes lauda, cludgy code can lead to semantics games which core devotee's love.
but segwit still doesnt make the native keys disarmed from the 4k CPU intensive time that existed in 0.12 either
so segwit for CPU intensive purposes is no better or worse
however there is still the 5tx's to fill the 80k issue
where it doesnt need to be 16k/tx of actual sigops.. only 4k/tx..
that means 5tx's can hold up and prevent even segwit transactions utilising the 3mb weight area because those 5tx's have used up all of the block sigops due to all the cludgy maths of 80/5/4
is using up all 20k legacy treated as using up all 80k block sigops.
a legacy sigop counts as 4 segwit sigops
so 20k legacy sigops would fill a block
just as 1MB of non-segwit transactions would fill the whole block, not leaving space for segwit transactions
tl:dr;
ok so segwit doesnt make native tx's able to be more quadratically CPU intensive. to cause more propagation delay
but it doesnt make native tx's any less quadratically CPU intensive than v0.12 (still 4k)
it doesnt stop native tx's making just 5tx's to fill a block (cludgy maths sigop count limit)
so to amend it - 3 attack vectors
1. just fill a block of native data to 1mb (data/byte bloat fill attack)
2. use up the block sigops limit with say 1000tx of just 20sigops each for example (cludgy maths sigopcount fill attack)
3. use up the block sigops limit with say 5tx of just 4,000sigops each for example (cludgy maths sigopcount fill attack)