Okay I worked through all the possibilities as explained upthread and below, and have concluded that Proof-of-Consensus can't work. I will now be stopping all further work on this dead-end. And all those who have a well functioning brain stem will stop this now.
As I wrote from the very beginning of my involvement in this thread (which is why
I had stopped work on my Proof-of-Hard Disk version of Proof-of-Consensus on May 13, 2013, before Etlase2 emailed me to check out his idea), there is no way to get the randomized entropy to randomize the order of which peers can sign the TBs. Upthread we had discussed the impossibility (network overload scenarios) of allowing all (potentially unlimited if attacker spams) SHs to sign within a CB, so Etlase2 offered the clever solution of using the signatures on the prior CB to randomize the order and we convinced ourselves that this could not easily be gamed if we used a function to modulate the self-chosen hash keys of the SHs with this random entropy.
But the problem is that there is no way to have consensus on who has signed the CB. If peers (wanting to be SHs on next CB) will separately broadcast their signatures, then who decides which were broadcast within the time limit and compiles it into a CB? If those peers will instead sign a CB that was signed by a prior peer until all who want to sign have signed it (within a deadline), the problem is who decides the order that they sign?
There is no possible solution. This is why only Proof-of-Work is viable for achieving consensus.
So we are done. End of story. STOP.
Incorrect, because every fork can pick up this transaction in its next CB. The evil fork has to broadcast the CB else the fork doesn't exist in public view.
This can be made impossible by spending the money on this wallet and not including this transaction. On block N the attacker broadcasts a transaction which spends all money from his wallet, but doesn't include it in his CB, using 1 CB "grace" period. On block N+1 he announces and includes 10 transactions involving money on the same wallet. The honest guys can't include them since they already confirmed the money spent, and the bad guy wins by 9 transactions. If you didn't observe this happening and you just see the blocks, you can never tell whose version is honest.
Along with the need to sign the CB periodically to gain the randomized entropy I mentioned above, I also admitted this possibility of double-spends in my prior post. And both of these reasons are why only the 51% fork can be the consensus. And thus why I have concluded that 51% attack is possible (in any form of P2P decentralized consensus, not just money). But we can't even accomplish the required randomized entropy so as I stated above Proof-of-Consensus does not work. This is a dead end.
It does nothing to solve the 51% attack with signing of the CB. Signing of the CB is necessary to decide the order of peers who can sign TBs.
Imagine the CB is signed continuously, with every TB.
Then can't get the randomized entropy for deciding the order of signing.
We are walking in circles going no where. The 51% attack can not be avoided by any decentralized design.
Then you'll have to explain how the attack works, under the new set of assumptions
Those assumptions won't provide the required randomized entropy for deciding the order of signing.