Disclaimer: This is subtle but not severe.

When the node is caught-up, we expect the following property to hold, closely following the behavior of an idealized "paper-Praos" node:

Once a node has observed a block B giving rise to a chain preferrable to the current selection, we will change our selection accordingly after we had the time to validate the new chain.

With Genesis, this is currently not true in an edge case when a node just concluded that it is caught-up; ie it will temporarily have selected a suboptimal chain, which in particular means that if it mints a block, the minted block will be suboptimal.

This seems very unlikely under honest peer behavior, and it is not clear if an adversarial peer inducing this behavior would actually gain anything here (compared to simply withholding its blocks). Nevertheless, it should ideally be fixed.

Concretely, consider k=1 (security parameter), consider that our node is Syncing :: GsmState, and that there are two peers P1 and P2 serving the following candidate fragments (without having sent MsgAwaitReply yet, at which point the GSM will conclude that we are caught-up):

ImmTip - A     [P1]
       \ B     [P2]

Suppose that there is a third block C on top of A, and P1 is serving that one. Then, due to the LoE, it will not be selected as it would advance the immutable tip beyond the common intersection of the candidate fragments. Therefore, C is only stored in the ImmutableDB.

Next, P1 either disconnects or rolls back to A, and both P1 and P2 send MsgAwaitReply. Then, the GSM will conclude that we are caught-up, so the LoE gets disabled (in particular), so it would now be fine (and even desirable) to select C as it is preferrable to A and B.

However, we currently don't trigger another chain selection in this case, so we only select C if we later receive another block buildin on top of C.

The fix is simply to trigger chain selection again once we are caught-up.

Also, it should be possible to write a regression test for this using io-sim (potentially via IOSimPOR to avoid hardcoding a particular scheduling of actions).