There is an additional subtle divergence from the consensus mechanism as outlined in the tendermint paperand the mechanism as implemented in this codebase that was discovered in discussion with @milosevic @josef-widder and @cmwaters .

In the Tendermint paper, a correct process will only issue a prevote for a value v in round r in one of two cases:

case 1: The process receives a proposal issued in round r for value v and receives +2/3 prevotes for the value in round r. [arXiv paper line 30].
case 2: The process receives a proposal issued in round r for value v and previously stored v as its lockedValue. [arXiv paper line 24]

The tendermint implementation diverges slightly from this. If the go consensus algorithm has a locked block in a round it will prevote this locked block even if it did not see a proposal in the round. Additionally, it will prevote its locked block even if it does not match the proposed block.

These inconsistencies should be removed. Namely, the algorithm should be amended to ensure 1) a block was proposed in a round when a process with a locked block is going to prevote and 2) the proposed block matches the process's locked block when it is going to prevote.