
[debug.log.txt](https://github.com/bitcoin/bitcoin/files/592002/debug.log.txt)

My node is being swamped with cmpctblocks from nodes, when as far as I understood it, only 3 nodes at a time were supposed to be announcing via cmpctblocks. Not only this, but many of the cmpctblocks arrive quite a while after I have received the block from other nodes, so surely my node should be requesting the announcement via cmpctblocks stops, or disconnecting the nodes that continue to announce via cmpctblocks after they've been requested not to.

As a bolt-on question: why is the contents of every cmpctblock received different?
/**
     * Sources of received blocks, saved to be able to send them reject
     * messages or ban them when processing happens afterwards. Protected by
     * cs_main.
     * Set mapBlockSource[hash].second to false if the node should not be
     * punished if the block is invalid.
     */
    map<uint256, std::pair<NodeId, bool>> mapBlockSource;
    /**
     * Filter for transactions that were recently rejected by
     * AcceptToMemoryPool. These are not rerequested until the chain tip
     * changes, at which point the entire filter is reset. Protected by
     * cs_main.
     *
     * Without this filter we'd be re-requesting txs from each of our peers,
     * increasing bandwidth consumption considerably. For instance, with 100
     * peers, half of which relay a tx we don't accept, that might be a 50x
     * bandwidth increase. A flooding attacker attempting to roll-over the
     * filter using minimum-sized, 60byte, transactions might manage to send
     * 1000/sec if we have fast peers, so we pick 120,000 to give our peers a
     * two minute window to send invs to us.
     *
     * Decreasing the false positive rate is fairly cheap, so we pick one in a
     * million to make it highly unlikely for users to have issues with this
     * filter.
     *
     * Memory used: 1.3 MB
     */
    std::unique_ptr<CRollingBloomFilter> recentRejects;
    uint256 hashRecentRejectsChainTip;