since small pools can also connect to the relay network, and i assume they do, there is no reason to believe that large miners can attack small miners with large blocks. in fact, we've seen the top 5 chinese miners deprecated due to the GFC making it clear they CANNOT perform this attack despite what several guys have FUD'd.
Basic misunderstanding there--- Being a larger miner has two effects: One is throughput not latency related: Being larger creates a greater revenue stream which can be used to pay for better resources. E.g. if the income levels support one i7 CPU per 10TH/s of mining, then a 10x larger pool can afford 10x more cpus to keep up with the overall throughput of the network, which they share perfectly (relay network is about latency not so much about throughput-- its at best a 2x throughput improvement, assuming you were bandwidth limited); the other is latency related, imagine you have a small amount of hashpower-- say 0.01% of the network-- and are a lightsecond away on the moon. Any time there is a block race, you will lose because all of the earth is mining against you because they all heard your block 1+ seconds later. Now imagine you have 60% of the hashpower on the moon, in that case you will usually win because even though the earth will be mining another chain, you have more hashpower. For latency, the size of miner matters a lot, and the size of the block only matters to the extent that it adds delay.
When it comes to orphaning races miner sizes matters, in some amount that is related to the product of the size-of-the-miner and time it takes to validate a block.
how can that be? mining pools all use a full node around which they coordinate their mining. all full nodes are relatively in sync with their mempools
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes. The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.
IBLT doesn't currently exist, and other mechenisms like the relay network protocol don't care about mempool synchronization levels.
pt being, it's statistically unlikely that full blocks today represent the magical level of "large" blocks that Satoshi set 6 yrs ago. the problems we are having with the forks are a result of the defensive tactics being taken from those full blocks.
Almost none of the blocks have been 1MB, the issues arise before then. _Consistent_ 1MB blocks wouldn't have been supportable on the network at the time that limit was put in place-- back in the 0.5.x-ish days we were getting up to 2minutes for a 100k block to reach the whole network; the 1MB was either forward-looking, set too high, or only concenred about the peak (and assuming the average would be much lower) ... or a mixture of these cases.
have the Chinese miners given you a technical reason why they're SPV'ing?
F2Pool reported that as block sizes grew they saw increased orphaning rates and that they were seeing an orphan rate of 4% though this was at a time before the relay network and when GHash in europe had ~50% of the hashpower under them. Excluding the recent issues they've had almost no orphans since, they report.
Then why don't we decrease the blocktime from 10 min down to let's say 2 min. This way we can also have more transactions/second without touching the blocksize.
Ouch, the latency related issues issues are made much worse by smaller interblock gaps once they are 'too small' relative to the network radius. When a another block shows up on the network faster than you can communicate about your last you get orphaned. And for throughput related bottlenecks it doesn't matter if X transactions come in the form of a 10mb block or 10 1mb blocks.