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.

if (pa->nChainWork > pb->nChainWork) return false;
            if (pa->nChainWork < pb->nChainWork) return true;
            
            if (pa->nSequenceId < pb->nSequenceId) return false;
            if (pa->nSequenceId > pb->nSequenceId) return true;
            
            
            if (pa < pb) return false;
            if (pa > pb) return true;
            
            return false;
        }
    };
    CBlockIndex *pindexBestInvalid;
    /**
     * The set of all CBlockIndex entries with BLOCK_VALID_TRANSACTIONS (for itself and all ancestors) and
     * as good as our current tip or better. Entries may be failed, though, and pruning nodes may be
     * missing the data for the block.
     */
    set<CBlockIndex*, CBlockIndexWorkComparator> setBlockIndexCandidates;
    
    int nSyncStarted = 0;
    /** All pairs A->B, where A (or one of its ancestors) misses transactions, but B has transactions.
     * Pruned nodes may have entries where B is missing data.
     */
    multimap<CBlockIndex*, CBlockIndex*> mapBlocksUnlinked;
    CCriticalSection cs_LastBlockFile;
    std::vector<CBlockFileInfo> vinfoBlockFile;