questions:
3. what are the most common problems that could occur if adopted?
I'll just start by describing what seems to be a downside to the proposal: weakening of blockchain consensus.
At present anyone can get a copy of the blockchain and verify it
offline using a "recent" version of Bitcoin software that they trust or have verifid the code themselves. The problem with accepting or rejecting blocks based upon message length (<=1MB) is that this decision is not preserved in the blockchain history. i.e. you can't look back later and see that a 2MB block is OK, because it was sent compressed, or not OK because it is present and somehow never compressed. This can't be resolved in isolation, but can be by connecting to the network and getting a download of all the headers to verify the blockchain. The active network has the correct state.
Is this really a problem?
A blockchain is pretty useless without an active network to process a tx built from it. The network has consensus on software as well as the blockchain, and this proposal relies upon the continuance of software consensus.
Other risks relate to the viability of compression techniques in situations such as reorgs. Since Gavin suggested IBLT in the first place, and it has been unit tested, I think it is reasonable to accept that compression can work, smoothly and long-term.
1. how much work and time is involved in decompressing an IBLT for verification/validation and addition of unknown tx's compared to the current method of receiving decompressed tx's contained within a block?
This is the trade-off, bandwidth is saved but extra CPU effort is expended by the sender and receiver. While unused (free) cpu is available and bandwidth is limited, costing money, then there is probably an overall benefit. We are going to have to wait for the numbers on this.
2. how strong is the assumption that nodes and miners have nearly identical mempools?
Gavin has done some work trying to get metrics in this area. So has Rusty
http://rusty.ozlabs.org/?p=486Nodes should have nearly identical mempools except at the margins i.e. new transactions coming in and old ones dropping off, so the middle 95% would be the best selection when forming an IBLT. Only nodes which apply their own non-standard tx filtering rules are likely to differ significantly,
I like it too but havent analyzed IBLT yet. One possible concern is that it discourages miner's personal choice to add or remove a txn from the block. But is this even bad? If it is a simple addition to the protocol could be a list of modification s to the canonical txn ordering.
IBLT will always allow some flexibility for personal tx choices by miners.
A ball-park maximum number for this is taking the size of the IBLT and allowing half of it to be comprised by tx unknown to the network. So, a 100KB IBLT could have 50KB (or 100 personal tx deliberately added). The more unknown tx that are added, the more the block is likely to fail decoding by the network and get orphaned.