Quote from: sor.rge on June 12, 2013, 12:29:46 PM

Quote from: AnonyMint on June 12, 2013, 07:06:57 AM

Those assumptions won't provide the required randomized entropy for deciding the order of signing.

Now you came up with another argument, one which is completely unrelated with what was discussed yesterday I must add, and pretend that you've closed the question. You argument includes no details, just a keyword. That doesn't work that way, you didn't convince me of anything - I didn't follow the entropy talk of the last month. As I said, either an attack is spelled out, in whatever form, or it doesn't exits.

It's ok for me if you don't want to continue the discussion, you don't have to. The final answer should come out of an implementation anyway, not from the arguments.

The discussion in the prior day or two was Etlase2 trying to find a solution to the 51% attack that you and I explained. But any signing of TBs will require a deterministic order as explained below. Thus that discussion does not escape from the insoluble problem below.

What part of the UNARGUABLE logic did you not comprehend? Let me try to summarize it again, and then you may tell me which part(s) you need more elaboration on.

1. For a SH peer to sign a TB and have it accepted by the consensus, there must be a determined order for signing. Without a deterministic order, which SH would go first or next? Obviously there must be an order.

2. This order needs to be randomized, otherwise it is possible to game the system.

3. The only way to randomize this order, is for the prospective SH peers to sign a CB, then all those who sign are eligible to be selected to sign TBs in the next CB period. The order of those selected is determined from the entropy of all those signatures on the CB. The first N closest hash keys are selected in a determined order, where N is the number of SHs peers that sign TBs per CB.

All of the above was already presented in upthread discussion between myself and Etlase2.

Now I discovered an insoluble problem.

4. There is no way to generate the signed CB. I quote what I wrote upthread:

Quote from: AnonyMint on June 12, 2013, 07:06:57 AM

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.

If you can find any holes in the above logic, please tell me.