Short-circuit bloom checking if we will always return true. #2338

This allows full nodes to use bloom filters as an optimization when downloading blocks (dont double-relay txn) as long as we have a sufficiently large mempool.

I figure I get this simply included in the protocol so that we can later bother with the actual download optimizations.

Automatic sanity-testing: WARNING, see http://jenkins.bluematt.me/pull-tester/cbfc77352d095d562860fa8695ada5ac73cf7f67 for binaries and test log.

This pull decreases total test coverage, please add unit tests to test all new code and help us add test cases for existing code. Coverage report can be found at http://jenkins.bluematt.me/pull-tester/cbfc77352d095d562860fa8695ada5ac73cf7f67/bitcoin/src/total.coverage/

Hah, neat. Do the merkle blocks generated by such a filter have much overhead for the representation vs just a generic list of hashes?

@mikehearn 8 bytes + 0.25 byte/tx + overhead of sending the transactions in separate messages instead of inline in a block.

Actually 32.25 bytes per tx (we chatted about it offline)

Yea, I think thats pretty good considering you have to atleast transfer the 32-byte sha256 hash of the tx (atleast given that you've already received most, if not all, of the txn in question).

@TheBlueMatt not horrible, though a protocol made just for this could transmit— say— 8 bytes instead, and then just pull the whole block in the insanely rare case that there is a collision. Probably not worth doing inside the bitcoin p2p protocol however.

Yea, absolutely could do better, but since this is already in the protocol, I figured I might as well enable it without wasting tons of CPU cycles hashing.