for instance if we naively go by the every tx is 226byte right now..
1mb block= ~4400tx so segwit would be 7920(4400*1.8 )
then others say that the average is 400bytes but core will eventually allow 2mb in 2017
1mb block = 2500tx so 1mb segwit would be 4500tx(2500*1.8 ) and 2mb segwit 9500
then others say that the average is 500bytes but core will eventually allow 2mb in 2017
1mb block = 2000tx so 1mb segwit would be 3600tx(2000*1.8 ) and 2mb segwit 7200
but remember a 2mb segwit is not actually 2mb of real data.. its actually 3.6mb where 1.6mb is still there but blockstream wont talk about it because "there is no witness"
also remember there are extra bytes being added for the other features, flags, etc.. so the blocks would actually be much higher then 3.6mb when a block is 'full'.
but seeing as Gmaxwell has withdrawn his plan to add CT to bitcoin. the bloat wont be as much as over 5mb. so lets just take the stats of the 3.6mb as a guideline expectation..
7200tx for 3.6mb
or if we were to stick with traditional transactions and just a blocksize increase.
at 226byte tx 3mb block without segwit 13200tx (15400tx if blocks 3.5mb)
Compare apples to apples and oranges to oranges, the closest your quoted post provides to such a comparison is as follows:
15400tx (blocksize 3.5 mb) @ vs 15840tx (segwit w/ 2mb)
It's not accurate since 3.5 mb < 2mb segwit, but none of the other numbers line up at all.
To be clear, I'm in the hard fork camp. I'm not 100% pro or anti regarding segwit or blocksize, but I am anti regarding a soft fork for a major change. However, I'm calling you out because you shouldn't be playing their game. It isn't right when they're playing it anti blocksize, and playing the same game anti segwit doesn't make it any better.