not sure which parts you found insightful, but here's the gist about this proposed application of IBLT (invertible bloom lookup tables) from my point of view for anyone who wants a tldr on this:
IBLTs (Invertible Bloom Lookup Tables) are a data structure of tremendous beauty. They allow synchronization of sets of key/value pairs using constant (pre-determined) size of the synchronization message. They work well if the differences are expected to be small, but can potentially fail completely if they are too large for the size chosen. Another nice feature is that in case of a one way master -> slave synchronization, there is only one synchronization message that can be used in identical form to synchronize an unlimited number of potentially different 'slave' sets. Essentially the synchronization method contains information about the complete master set, but in a lossy way such that it can only be retrieved if a large enough number of key/values of the set are already known by the slave.
The idea is to apply this to the problem of bitcoin block transmission. The assumption can be made that the set of transactions in a freshly found block is already known to a large extent by the other miners because transactions have already been broadcast and inclusion policies are fairly uniform or at least predictable. So an IBLT of a chosen size (the miner can choose the size) can be used to propagate the transactions of the block (master) to the other miners (slaves). Since the slaves can make a pretty good estimate of the set of transactions that might be in a newly found block by using some standard inclusion policy, the size of the IBLT can likely be chosen to be quite small.
One effect of this scheme is that this IBLT synchronization message would be the same size, no matter how many transactions are included in a block. This is in contrast to the current situation where the synchronization message is essentially the block itself, so its size depends greatly on the number and size of transactions included. It is clear that miners are incentivized to mine smaller blocks because that greatly increases the probability of winning a potential race in case another miner found a block at a similar time due to transmission and therefor block propagation delays in the network. Thus using this scheme would remove the incentive to mine small blocks by removing the cost of larger blocks. Gavin calculated this cost to be some non-negligible number.
A possible downside could be that non-standard inclusion policies (think eligius, for example) might necessitate a large IBLT und thus be disincetivised.
What this doesn't do: it doesn't magically solve any scaling issues. At most it reduces the overall bandwidth requirements by 50%. Miners still need to have enough bandwidth to receive all transactions that are being broadcast.
