There are some potential feefilter cleanups mentioned and motivated in comment https://github.com/bitcoin/bitcoin/pull/21509#issuecomment-805808485 . If you address the locking one, please be careful and make sure that `round()` is only called under a lock. See https://github.com/bitcoin/bitcoin/pull/21509#issuecomment-807992199

#### Useful skills:

* Bitcoin protocol messages
* Bitcoin Core P2P design
* Running our unit and functional tests

#### Want to work on this issue?

For guidance on contributing, please read [CONTRIBUTING.md](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md) before opening your pull request.

Mutex m_misbehavior_mutex;
    
    int m_misbehavior_score GUARDED_BY(m_misbehavior_mutex){0};
    
    bool m_should_discourage GUARDED_BY(m_misbehavior_mutex){false};
    
    Mutex m_block_inv_mutex;
    /** List of blocks that we'll announce via an `inv` message.
     * There is no final sorting before sending, as they are always sent
     * immediately and in the order requested. */
    std::vector<uint256> m_blocks_for_inv_relay GUARDED_BY(m_block_inv_mutex);
    /** Unfiltered list of blocks that we'd like to announce via a `headers`
     * message. If we can't announce via a `headers` message, we'll fall back to
     * announcing via `inv`. */
    std::vector<uint256> m_blocks_for_headers_relay GUARDED_BY(m_block_inv_mutex);
    /** The final block hash that we sent in an `inv` message to this peer.
     * When the peer requests this block, we send an `inv` message to trigger
     * the peer to request the next sequence of block hashes.
     * Most peers use headers-first syncing, which doesn't use this mechanism */
    uint256 m_continuation_block GUARDED_BY(m_block_inv_mutex) {};
    
    std::atomic<int> m_starting_height{-1};
    
    std::atomic<uint64_t> m_ping_nonce_sent{0};
    
    std::atomic<std::chrono::microseconds> m_ping_start{0us};
    
    std::atomic<bool> m_ping_queued{false};