Did you read the comment below yours? It is from Rusty Russell, a software genius who is behind parts of the Linux kernel. He and Kalle Rosenbaum exchange notes on their
independently developed implementations of IBLT tested using tx recovered from the Bitcoin blockchain. It is not pie-in-the-sky. It works!
http://rustyrussell.github.io/pettycoin/2014/11/05/Playing-with-invertible-bloom-lookup-tables-and-bitcoin-transactions.htmlRegarding "compression rate increase" == "system will need be highly centralized".
Successful compression rate increase is a function of the synchronization of node mempools, remember they are already all running the same software (consensus code), and receiving the same cascading p2p unconfirmed tx. They don't need to be centralized, they just need to
avoid applying their own personal tx censorship rules (e.g. like Eligius who regards Counterparty tx as spam while encoding books is fine and dandy).
If all miners already have a copy of (nearly) all transactions and they only need to confirm that, then that is indeed very low entropy. For example it doesn't allow for any network disruption hiccups. When all-for-one-and-one-for-all (Communism, low entropy) have to agree on (nearly) everything then oligarchies naturally form into that power vacuum.
Again you are asking small miners to have connectivity, memory, and processing power to listen all transactions or trust a proxy (pool) to do it for them.
This worsens centralization egregiously when moving to micropayments scale.
Some have stated Bitcoin can never work for micropayments scale, so if that is not the goal, and if pools are an acceptable outcome, then this IBLT method probably suffices for scaling Bitcoin within that low entropy paradigm and the potential Sybil attacks on pools.
I guess it is because I am looking at this from the perspective of my (conceptual) solution which makes orthogonal what must be centralized from what can be decentralized, and thus achieves an overall provable decentralization (no Sybil attack possible, no low entropy power vacuum, transactions can't be unspent by orphaned chains, etc) and micropayments scaling.
Agreed IBLT can be shown to work in such a low entropy constraint (all-for-one and very limited headroom scaling), which was the point of my comment. Thus afaics, Rusty has not refuted my comment (don't know if he was trying to).
IBLT doesn't alleviate the advantage w.r.t. higher orphan rate for larger pools with better connectivity (if the smaller miner can't listen to all micropayment transactions any way) which ameliorates cypherdoc's retort against one of my threat vectors. Again if Bitcoin isn't going to scale, then fine you can use IBLT up to Visa scale perhaps. But realize Visa was for brick and mortar industrial age and we are headed towards millions and billions of transactions per second in the knowledge age.
Some of you mention side-chains, but it doesn't matter where you put the chain, you just have to solve the fundamental design issue else you've just sugarcoated more centralization (e.g. you'll end up with a few behemoths such as Coinbase, Circle, Paypal, Facebook, etc processing the micropayments offchain).
I suppose any way you head off into the maze, you will always end up back at my solution.