Quote from: monsterer2 on February 23, 2018, 11:30:36 AM

Quote from: Blinknet on February 23, 2018, 11:23:29 AM

Our entire algorithm is focused around the idea that independent transactions can be treated independently. So in that round all the other transactions will be accepted, except those that were performed on accounts which had unresponsive lockers.

Ok, so, 10/20 go through in this round.

...What happens when the 10 which were offline, weren't actually offline at all, but just delayed due to latency and they produce a fork of the just submitted round with the last 10/20 transaction in it?

There's no way to create a fork on those transactions, since the majority of the network needs to receive them in the next round at most, to confirm them. Think of lockers as a pre-validation step, gatekeeper to the system if you will. Since those transactions were not confirmed by a majority of the network, that means that those transactions will never be accepted, and everyone the applied them will undo them.

Between the time a transaction is signed by a locker and confirmed by the network, it's essentially pending. We expect running a full node to be something that only servers with decent processing power and good internet should do, so delays are rare. The latency between almost any pair of servers with decent internet in the world is less than 300ms. Even if delays happen between some pairs of nodes, there would have to be a global internet problem in order for a majority of the network to have these issues.

In essence, we want to optimize the system as much as possible for the average case, while still being robust for any worse case.