from Hacker News

Bitcoin block propagation with IBLT, Part I

by martinkallstrom on 10/12/15, 9:21 AM with 5 comments

  • by kang on 10/12/15, 10:55 AM

    The problem statement is not so simple; one one hand there is incentive for the miner to keep the block small so that it propagates the network faster but that is looking at immediate profit, however, on the other hand, Peter Todd has shown[1] in the bitcoin-dev mailinglist that actually "increasing" the blocksize and even withholding it for some time significantly increases profit in the near long term.

    Now, even ignoring this, if we assume the problem statement just as what the author describes, there are problems with his approach. Firstly, big pools have said that they operate at a loss and their aim is not to earn profit from mining but by providing value-added services like 'guaranteed tx confirmation', which big pools can. Secondly, and technically, this only works if data set is low so as to keep collision low [2]. Beyond a certain point there are many false positives and worst case all transactions might be needed to sent anyways.

    So although this is not worse than the current status, but certainly could end up not even being useful.

    [1] http://www.mail-archive.com/bitcoin-development@lists.source... [2] https://en.wikipedia.org/wiki/Bloom_filter#Interesting_prope...

  • by placeybordeaux on 10/12/15, 4:24 PM

    The abstract problem is there is a set of objects and all peers have access to some subset of them. You want to communicated an ordered list of them plus some arbitrary data (your winning hash) to as many peers in as little data as possible.

    It seems to me that the best solution is to have a well agreed upon function that keeps them in an ordered state and simply keep track of what transactions your neighbors know about, the information should largely already be there due to the fact that the transactions are dissiminated by a gossip protocol in the first place.

  • by kanzure on 10/12/15, 12:13 PM