I've updated the gist, and added an additional proposal that I think meshes well: https://gist.github.com/kazcw/43c97d3924326beca87d#ultra-fast-block-validation
sparseblocks + UFBV would tighten the new-block process to this (when txes have been received in advance): - receive block (~2kB for 1000 tx) - check whether block contains txes known to belong to conflict-sets, and if so whether more than one tx from a single conflict-set has been included (a few operations on very small sets) - relay block (~2kB) The benefits of these changes only occur when the transactions have been seen in advance, but incentivizing ahead-of-block transaction propogation is a plus, as Jeff mentioned; working on a block without first ensuring peers have its transactions would be very expensive from a miner's point of view. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
