Quote from: solex on January 05, 2015, 06:10:13 AM

Quote from: Peter R on January 05, 2015, 05:47:29 AM

Quote from: solex on January 05, 2015, 05:28:05 AM

Quote from: brg444 on January 05, 2015, 05:12:52 AM

The problem is not so much the storage. Bandwidth is where you'll run into a bottleneck

With that, IBLT can slash bandwidth requirements by at least 2 orders of magnitude. Only full node bootstrapping and re-sync will remain bandwidth intensive.

It will cut full-node bandwidth requirements by no more than in half.

IBLTs make propagation of solved blocks orders of magnitude more efficient, but that's only because the nodes already have the TXs in mempool. The TXs still need to be processed by each node as they're broadcast across the network; IBLTs simply prevent the TXs from being transmitted a second time with each solved block.

Yes, but "simply" is an understatement. Real-time tx cross the network uniformly, with enormous capacity already available, perhaps 1000 TPS. It is block propagation which is time critical where milliseconds count. When a block is solved the rest of the mining network is then hashing uselessly until the block is fully propagated. Incentives are perverse, against large blocks which are ultimately needed to fund the network via fees rather than rewards. Removing the bottleneck for block propagation is a huge win for scaling Bitcoin.

how does the IBLT scale with the size of the ~~block~~ UTXO set? linearly or by some other ratio?

edit: actually iirc, it scales with the size of the difference btwn UTXO set estimates across the network. iow, a UTXO set estimated to be 99% similar across the network will allow a miner to send a smaller IBLT when solving a block than a UTXO set estimated to be only 89% similar across the network. is that right?