http://gavintech.blogspot.co.nz/?view=classic
He means using IBLT, and IBLT is so powerful that it can squeeze a 100MB new block announcement into 1MB, the size in use today. It is also less work overall than LN or SC. i.e. simplest.
It does need prototyping, testing and benchmarking, and the breakeven point is unknown. But like JR's node services payment channels, it is a Cinderella of software where the focus of attention is mostly elsewhere.
Gavin's own comments was that IBLT probably doesn't not make sense with blocks under "hundreds of megabytes":
09:49 < gavinandresen> morcos: e.g. the IBLT work really doesn’t make any sense until blocks are in the hundreds of megabytes size range.
Given my expirence with an attempted implementation of the earlier block network coding proposal, I wouldn't be shocked to find there was no size at which using set reconciliation over the whole block was a win for normal connectivity and normal CPU speeds (as opposed to things like sattelite connectivity) though we won't know for sure until its implemented.
Regardless, the data still has to be sent a first time-- which is why in terms of overall capacity (rather than latency) the greatest improvement available from fancier relay is a doubling of capacity from eliminating double transmission-- and this is the case with both IBLT and the relay network protocol. The relay network protocol reduces some bad incentives in mining (e.g. mining without validating or mining empty blocks for faster relay) but it not a silver bullet, nor is IBLT. (Though it does have the advantage of being simple, already existing, avoids some bad incentives against including censored transactions, and likely being much faster than IBLT for current block sizes: Already the relay network protocol is CPU bottlenecked with much of its delay just computing the hashtree (even with a fancy AVX sha256 implementation in the client)). (At least for large block reed solomon codes, it appears even highly optimized implementations cannot run faster than a few megabits per second on current CPUs... the fountain code like IBLTs should be somewhat faster, but it's unclear how much, especially when operating at near their recovery limit--- the IBLT also requires a CreateNewBlock in the reciever which is currently slower than the whole block-relay-network-process...)
Lightning network and sidechains are not magical things, they're orthorgonal and not alternatives to relay improvements. But since you bring them up: They're both at a _futher_ level of development than IBLT at the moment; though given the orthogonality it's irrelevant except to note how misdirected your argument is...