You've glossed over it, and the paper doesn't cover it. This is the core of your consensus mechanism. You've asked for feedback on your whitepaper in this thread, I've taken the time to read it, the least you can do is to address the concerns I've raised without glibly just directing me to re-read the paper.
Sorry if we may seem dismissive of criticism, especially when we're actually trying to receive feedback.
All the issues you're raising are actually addressed in those 2 paragraphs in the paper though.
There are two possible solutions to mitigate the problem you're raising: either having lockers from consecutive rounds communicate with one another, and do a passing of the account state at the end of the round, with signatures to back it up, or require that each transaction is signed by lockers from the previous round and from the current round. Both of these solutions are presented in the paper, and each of them solves the problem you keep coming to (spamming the network with transactions, until an inconsistency is approved).
I know they're not expanded on, but is it really not clear why this would work? For us it seemed enough at this point.
If you think that anything more needs to be said here, let us know, but please try to at least acknowledge the argument.
Thank you for clarifying. As far as I can see, the first of those proposed solutions will result in a 'no consensus' result in the best case, as the account state will look to both lockers like each of them has the correct spend individually.
The second solution sounds like it will lead to all lockers being forced to sign all transactions as there is no way to tell there is going to be a double spend, so lockers from round A will have to be online to sign round B and so on and so forth.