Quote from: Blinknet on February 23, 2018, 02:22:28 PM

In the case you presented, if 10/20 lockers appear offline and later they try to broadcast the transactions for which they were the assigned lockers, the other nodes would simply ignore those transactions. Honest nodes always ignore transactions that were signed more than 2 rounds in the past. But indeed, there could be a conflict if the lockers come back online in the middle of the following round.

After the transaction broadcasting phase follows the sync & commitment. During this second phase nodes solve any kind of inconsistencies, e.g. revert double spends. Only after syncing there is a commitment vote on the global state some X rounds in the past. Anything that happened during those last X rounds is still subject to change through the sync process. A fork can only happen if the network doesn't agree on the commitment state.

As for the propagation times, check out this screenshot from the paper you linked:

. Our transactions currently have ~300 bytes, that's why the propagation times of Blockchain based protocols don't apply to us.

The problem that you're facing is that of network partition combined with the fact that you allow a subset of lockers to participate in the sequence of processes that finalise the state.

You can end up with a fork if you allow a subset of all allocated lockers to finalise the state, due to network partition. If you require a majority to participate, you will get a stalled consensus until the partition resolves itself.