More on Simple Random
If not already clear, transactions are listed in order and added on by transaction-time. In this way, an unambigious list and hash is created, for whatever length. When same-length lists of different nodes disagree, it is because a transaction is missing.
When a node receives mini-blocks, it has the same infomation more or less as the other nodes, and it becomes clear what hash is considered best by the collection, even if it doesn't have the latest transactions. In this case, it could wait for more transactions to arrive.
All nodes recieve nearly the same mini-blocks. If 100% of them are received, then the choice of which hash is best, is simple. If less than 100% are received, then a best-choice hash is picked. With normal processing and strategic filtering, the nodes will separately choose the same hash, or very likely will. When this fails to happen the network may get conflicting super-blocks, in which case it will pick the earliest one with the most signatures.
Basically a node gets impatient when mini-blocks do not arrive within statistically acceptable times, and it guesses what the best-choice super-block will be. If it cannot guess with a very high tolerance, it will show a little more patience. By this time, another node will probably be more sure of itself and broadcast its correct answer.
All the nodes must count on each other to come up with the same hash/block. If all nodes are struggling it probably means there are multiple good answers. So each node slows down a little, and does some extra work. It may pick an older, more conservative answer/hash, based on the percentage of mini-blocks it has received. And it could apply a perdetermined algorithm that sets aside one good answer as best. If all nodes experience the same mini-blocks not arriving, what they choose will very likely match the 100% case.
Even if different nodes are chosen by the network (unlikely), the same transactions will be verified, and only the random-key will differ; In this case, more than one collection will be chosen, and the smaller collection will fizzle out, even if over multiple generations. (The 60% threshold may be lowered when too few mini-blocks come.)
I thought there was more written on this, but I do not see any more.
to the timing attack question…
Basically those merchants/users who are either very slow, or are part of a widespread attack on the network are dealt with in a slowed approach. A main principle is to ignore bad behavior or put it on the backburner.
So a bunch of users start sending transactions who send-time is falsely early possibly to give themselves a greater likelihood of being included in a block. The nodes who first receive the transaction realize that time between send and receive is big or questionable. Perhaps a penalty is attached and the problem is ignored. If another node sends on the same transaction without a penalty, then the earliest one is used.
But if many such slow transactions are coming in, a node ignores the bad transaction and waits for another node to send it the same transaction. If this never happens, it eventually sends it on. So it may end up feeling like a really slow credit card transaction.
Toward the end of a block time, all slow and questionably timed transactions are left out in a higher degree than usual, rewarding good/normal transactions.
What happens is the node waits an arbitrary, lets say 1.5 - 3 seconds. Other nodes do the same but with different times. Chances are a node will get some other transactions before sending on its own. In other words the network/nodes slow to the point where latency isn't really much of an issue. The lesson is don't be slow on purpose or accident.
With many 'slow' transactions the curve sharpens, such that more waiting or penalties happen to slow ones, while normal ones may just get faster.
Those with the main role of bunching transactions do not bother doing most of this. They probably just send on everything as quickly as possible, acting as the outside circle to faster nodes on the central internet. When you think about it, a bunch of organized decentralization is like wide spread centralization without the weaknesses. These bunching nodes or typical users may sign the time into transactions or groups they send on.
In conclusion, Nodes actually send on less total transactions in case of attack, possibly making everything faster and smoother. It's just a little slower for the slow, during an attack. Eventually an attacker dealt with this way runs out of free transactions.
By the way, internet transfer is all supposed to be one way if possible, such that one checks back for confirmation. Maybe then no such thing as true sybil attack. (If this is allowed on internet protocols... my one-way paradigm, do not see why not.)
Thinking about this, it is really hard to attack the network, because the first priority of nodes is communication with other trusted nodes, some of whom are owned by exchanges, services or wallets. A node will respond as well as possible to requests, but it is free to filter for good users and requests. Many users may actually use services who handle blockchain connection themselves, using their own full node. Remember nodes are listed and trustworthy as part of governance. Plus, certain nodes dedicate themselves to just providing realtime transaction /block information, so such an attack may not really slow normal operations.