Noticed this in my code review: https://petertodd.org/2016/segwit-consensus-critical-code-review#peer-to-peer-networking

Basically it looks like an attacker may be able to send nodes transactions with malleated witness data, which we don't consistently mark as possibly corrupted in AcceptToMemoryPool(). Result would be those txids being added to recentRejects, messing up propagation.

That said, I haven't actually tested this yet; about to go off to a conference, so if someone else wants to confirm for me that'd be much appreciated! Or if I'm wrong you're welcome to all laugh at my expense. :)

CC: @sdaftuar @sipa 

* 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
     */
    boost::scoped_ptr<CRollingBloomFilter> recentRejects;
    uint256 hashRecentRejectsChainTip;
    
    struct QueuedBlock {
        uint256 hash;
        CBlockIndex* pindex;                                     
        bool fValidatedHeaders;                                  
        std::unique_ptr<PartiallyDownloadedBlock> partialBlock;  
    };
    map<uint256, pair<NodeId, list<QueuedBlock>::iterator> > mapBlocksInFlight;
    
    list<NodeId> lNodesAnnouncingHeaderAndIDs;
    
    int nPreferredDownload = 0;
    
    set<CBlockIndex*> setDirtyBlockIndex;
    
    set<int> setDirtyFileInfo;