It seems that currently, when we start the node, the best_beefy_block is going to be simply set to best_grandpa_block (See here)

This makes it hard for multiple nodes to agree on the starting block and consequently on a block to vote on. (also related #162)

Instead we should make sure that the nodes that are starting up set the starting block to a value that is roughly the same, no matter at which point they were started.

Possible options:

1. Set the starting block to 0 - this could be implemented, but only with a cap added on the power-of-two selection rule, so that the numbers don't go crazy high.
2. Set the starting block to latest session boundary - we could try to figure out where the session boundary is - that should align us with all other peers that participate in the protocol (because there should be one BEEFY commitment on the last block of the session).
3. Reverse engineer the starting block by observing votes - after seeing some votes being cast by other validators, try to figure out what their starting block is (we need (at least) 2 votes from the same validator + the assumption that both rounds are not concluded (which is reasonable, because if it's concluded we should update best_beefy_block anyway).

The last solution seems overcomplicated and error prone. I think option (2) is the most reasonable. There is probably a RuntimeApi that would help us figure out at what point of the session we currently are, and from this we can figure out the beginning (or rather the end of previous session).