While starting up a node (commit 6fc6325), it was apparently taking curiously long to load the ban list. RPC (in warmup mode) kept returning `Loading banlist...`. When I checked the log I happened upon the following:

```
2016-05-30 07:35:00 init message: Loading banlist...
2016-05-30 07:35:26 UpdateTip: new best=0000000000000000045614e4901f822a86e4015543acc6a68653cc9450f0f330 height=410222 version=0x20000000 log2_work=84.600836 tx=126776938 date='2016-05-04 18:0
1:59' progress=0.984518 cache=8.8MiB(5488tx)
...
2016-05-30 07:39:43 DNS seeding disabled
2016-05-30 07:39:43 opencon thread start
2016-05-30 07:39:43 msghand thread start
2016-05-30 07:39:43 addcon thread start
2016-05-30 07:39:43 init message: Done loading
2016-05-30 07:39:43 net thread start
```

I think it's a matter of the init message not being updated for a new initialization phase after loading the banlist.

int nLastBlockFile = 0;
    /** Global flag to indicate we should check to see if there are
     *  block/undo files that should be deleted.  Set on startup
     *  or if we allocate more file space when we're in prune mode
     */
    bool fCheckForPruning = false;
    /**
     * Every received block is assigned a unique and increasing identifier, so we
     * know which one to give priority in case of a fork.
     */
    CCriticalSection cs_nBlockSequenceId;
    
    uint32_t nBlockSequenceId = 1;
    /**
     * Sources of received blocks, saved to be able to send them reject
     * messages or ban them when processing happens afterwards. Protected by
     * cs_main.
     */
    map<uint256, NodeId> 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