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.
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.