I see what you mean, it does seem a bit odd to use the head block time as the seed, and not hardware time or similar. I can't pretend to understand why they would have done that.
Is it because it must be deterministic across witnesses, and so can't actually be random at all?
That's right, it actually does have to be deterministic, to keep a deterministic schedule.
Not only that, what guarantee is there that any given witness has not altered this code with a whitelist and the witness can then use this information to time flood attacks or for that matter, knowing that a certain witness (or witnesses) will approve, because of altered code, invalid transactions? Given enough witnesses under your control (ie, special code added to them to privilege you), you can rewrite the chain as you wish.
Yeah, I guess any decentralised system has these kinds of issues though.
This is what Proof of Work specifically avoids. The Solidus protocol specifically uses PoW to select a 'committee' (like the witness set)
I am going to have to think about this, because it is an obvious and simple way to get past this problem.
I see. So it's a weakness of 'DPOS'?
It's exactly what Solidus has solved. Nothing is stopping me from using a PoW election to select the schedule. You can see easily enough that the algorithm in the code cannot be left how it is.
Will you not find one thousand things that need improvement though, and take one thousand days to rectify them? I get the feeling this is a recognised weakness of DPoS, but any PoW presumably opens other possible attack vectors. Not that I know much about any of this.
PoW is very strong against prediction/timing attacks. It has a place, but I don't think it is necessary to use it to regulate currency issuance, because you can instead prevent timing attacks (and thereby also collusion) by making it impossible to know which witness is going to be up to make a block.
Moreover, when you discard the primacy of the tamper-proof blockchain as the primary propagation, you can use other mechanisms to certify. SporeDB uses these, and its' design is based on epidemic protocols, which also reduce messaging cycles. SporeDB also uses Strong Eventual Consistency to prevent a consensus on data which has not propagated well enough, which is in principle how Bitcoin and Ethereum, which have different mechanisms for selecting the canonical chain, Ethereum uses 'longest chain wins', and I forget exactly what Bitcoin uses edit: most confirmations. This kind of mechanism can actually be made stronger if the ordering (whether by block, or within the block) becomes unimportant using acyclic graphs (like what Git uses to determine order of changes without knowing timing) and Interval Tree clocks.
So, in a short answer, there is many extra mechanisms that must be applied. This is just an answer to eliminating determinism in the witness schedule, at this point.
As for what changes to include, basically, if it's a removal, it's easily in the list. If it's an addition, I would prefer to avoid it. If it's a modification, it should be simple, and clearly enhance security of the data, as well as preventing existing, well known attack vectors.