Quote from: Blinknet on February 22, 2018, 10:44:44 AM

"The protocol assumes the nodes are not necessarily up to date with the state of all the
accounts, but they should be when it comes to those accounts for which they are
supposed to act as lockers. To achieve consistency, the nodes that are lockers for the same
account in consecutive rounds will communicate with each other. The old locker will
pass on the state of the account to the new locker.
Should the network have a low trust in lockers, at the expense of a small increase in
bandwidth and CPU usage, transactions can also be signed by the lockers of the current
round and also by the lockers of the previous round. This would ensure that no
transactions could ever be invalidated when lockers from consecutive rounds are not in
sync"

This part could probably be better emphasized.

That's hardly an analysis. This is core of your consensus protocol, you can't gloss over it with a throwaway paragraph.

With a horizontal consensus like this (as opposed to a vertical chain of consensus, like a PoW chain) it is possible for the consensus to stall completely due to inability to reach an agreement. You've allowed a maximum of two rounds of consensus to occur, so what happens when both of these fail to reach an agreement? Why can't that happen?