Quote from: sor.rge on June 12, 2013, 06:07:44 PM

Quote from: AnonyMint on June 12, 2013, 03:16:40 PM

Let me try to summarize it again, and then you may tell me which part(s) you need more elaboration on.
...
2. This order needs to be randomized, otherwise it is possible to game the system.

This one please. What exactly do you mean by "randomized", and what kind of attack you imagine if this property is not present?
In cryptography "random" usually means "unpredictable", which cannot be the case here, as you say in point 1. Why can't we just let SHs sign TBs in alphabetical order of their IDs? If this is bad for some reason, there's an infinite number of other ways to do it.

Etlase2 and I discussed this upthread and I think he and I agreed that without randomization of the order, that there was a threat.

The threat we discussed was that evil peers could position themselves to always be the chosen SHs and thus control all signing of TBs.

Randomized in this case means the selection order can't be known a priori when prospective SH peers chose their ID.

No there are not infinite number of ways. There is either randomization or there isn't. This is fundamental to cryptography. I suggest that you are not qualified in cryptography, and are only a (n exceptionally astute) layman. Otherwise you would have known what I meant. Am I correct?

Quote from: sor.rge on June 12, 2013, 06:07:44 PM

Quote

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.

Depends on what definition you will give to randomness in this case, but in general "the only way" is always a very strong statement about an algorithm, which can practically never be true. You can only say "the only way I'm aware of currently". The "entropy of signatures" and its use to find the order has to be explained, after you explain the need for it in point 2. above.

You fail to understand a basic premise of cryptography, which is that entropy can't come from an algorithm, it can only come from instances of uncertainty occurring in nature (e.g. how often does the bee land on your flower). Thus I can for sure say that it can only come from the outside inputs to the process. And those signatures are the only outside inputs in our system. We could also use the entropy from the transactions, but that doesn't eliminate the insoluble problem I showed.

Quote from: sor.rge on June 12, 2013, 06:07:44 PM

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?

Every peer will decide for himself. Remember the assumption of bounded time guaranteed broadcast.

Ludicrous. Then there must be a fork for every observing peer. You fail to reason that the consensus CB entropy determines the signing order for the fork in the next CB period.

Quote from: sor.rge on June 12, 2013, 06:07:44 PM

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

There is no possible solution. This is why only Proof-of-Work is viable for achieving consensus.

Even if that solution didn't work out, there is no proof of this statement.

The proof is that the only way you get the necessary entropy is by having every peer compete to be first. Everyone other form of entropy has a point of failure that there is no decision, the consensus is required ad infinitum at every point where you design it away to another point.