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 

FLUSH_STATE_NONE,
    FLUSH_STATE_IF_NEEDED,
    FLUSH_STATE_PERIODIC,
    FLUSH_STATE_ALWAYS
};
/**
 * Update the on-disk chain state.
 * The caches and indexes are flushed depending on the mode we're called with
 * if they're too large, if it's been a while since the last write,
 * or always and in all cases if we're in prune mode and are deleting files.
 */
bool static FlushStateToDisk(CValidationState &state, FlushStateMode mode) {
    const CChainParams& chainparams = Params();
    LOCK2(cs_main, cs_LastBlockFile);
    static int64_t nLastWrite = 0;
    static int64_t nLastFlush = 0;
    static int64_t nLastSetChain = 0;
    std::set<int> setFilesToPrune;
    bool fFlushForPrune = false;
    try {
    if (fPruneMode && fCheckForPruning && !fReindex) {
        FindFilesToPrune(setFilesToPrune, chainparams.PruneAfterHeight());
        fCheckForPruning = false;
        if (!setFilesToPrune.empty()) {
            fFlushForPrune = true;
            if (!fHavePruned) {
                pblocktree->WriteFlag("prunedblockfiles", true);