Quote from: iamnotback on November 13, 2016, 05:29:49 PM

Quote from: tonych on November 13, 2016, 04:44:14 PM

Quote from: iamnotback on November 13, 2016, 02:19:14 PM

Quote from: tonych on November 13, 2016, 02:05:39 PM

Quote from: iamnotback on November 13, 2016, 01:29:21 PM

Quote from: tonych on November 13, 2016, 11:03:21 AM

Quote from: iamnotback on November 13, 2016, 08:16:47 AM

But sorry to say the flaw I see in your analysis is that you don't appear to consider the case where a new branch appears (which was formerly hidden by network disruption, propagation delays, or intentionally) which has a sufficiently different set of witnesses from the "current MC" which any particular node analyzed.

There can't be a branch with substantially different set of witnesses. There are no forks by design. This is because the stability point can't advance without support of the majority of witnesses named in the previous stability point. And there is a rule that the set of witnesses in new units should differ from the witness list at the stability point (specified in the new unit) by no more than one mutation. The rules are really tight, you can't go too far from the witness list at the stability point.

Can't I sign a unit that has as its parent the, differs by 1 witness from the, genesis. Then sign a unit that has as its parent the, differs by 1 more witness from the, unit I signed in the prior sentence. Repeat as necessary. All those witness can be ones I control which I have sign units in my chain. If necessary I can control different addresses to make it appear that many people were using this chain branch.

So I can build a secret chain branch that double-spends one of my units from the public chain, then I release this secret chain branch. Then it is entirely ambiguous which of the double-spends is first and which of the chain branches is the "real" one, i.e. finality was not reached and the "stability" point was not stable.

I repeat that afaics your design is flawed unless you set a static global list of 12 witnesses.

Your second step (bolded) won't work, therefore all subsequent reasoning doesn't hold.
It won't work because it breaks one of protocol rules.
When you compose a new unit, you include a reference to last ball. Balls are units that became stable (in your view), and last ball is the latest of such balls, AKA last stability point. The rule says that your witness list must be compatible with that of last ball, and you are breaking this rule by introducing a second mutation.

That means that before introducing a second mutation you have to wait that your first mutation reaches stability, and this is impossible if your chain is secret and the old witnesses can't see it.

Referring the part I bolded for emphasis, I can Sybil attack with numerous addresses. I can make my secret chain branch appear just as "real" as the public one. I can have millions of "users" on my secret chain branch (which are all controlled by me) with witnesses (which are all controlled by me) that aren't on the public chain branch.

Please re-read the part you did not bold, is it clear?
You can have millions of "users" on your secret branch but how would you make it appear more "real"? Remember, you can't advance the stability point on your secret branch, hence you can't replace more than one witness with yours. Let me know if anything's still unclear.

If what you are claiming (for your protocol design) is that a majority of the 11 old witnesses have to sign units on my secret chain for it to advance in terms of the stability point (i.e. that you don't let me select new witnesses when the old ones fail to sign), ....

That's correct, I'm glad it is clear now.

Quote from: iamnotback on November 13, 2016, 05:29:49 PM

... then the problem shifts to one where if 6 of 12 witnesses stop signing (or don't sign enough to provide convergence to a total order) then the stability point never moves forward in the entire system (not just on my secret chain). The entire Byteball system can become suck and nothing can become final.

Either way, it is a flaw. So which is your choice of poison in your design?

To address this issue, we have sufficiently large number of witnesses, so that we can afford to lose 5 witnesses and still continue operation.
If we lose 6 or more, all at the same time, yes we become stuck.
Remember, witnesses are elected for a number of criteria, and one of them is that the would-be witness is not going to disappear suddenly. Even if this happens, the community has a chance to replace the inactive witness before another such failure.

Quote from: iamnotback on November 13, 2016, 05:29:49 PM

Edit: also I can devise an attack to side-step your protocol rule. Build a chain branch that has no double-spends and make it public. Gradually change my list of witnesses one-by-one on the units I sign as the old witness happily sign units on my chain branch to advance the stability point. I can spam with as many Sybil address signed units as necessary to convince the witnesses that my chain branch is "real". Then once I've got the old witness down to a minority, I can take my chain branch private and complete the attack I explained to you before.

Again, seems like you are assuming you can convince somebody with the number of your Sybil units. And not just somebody -- the acting witnesses. The acting witnesses, and other users likewise, are not going to change their own witness lists to stay compatible with your Sybil units. Your Sybil units will be accepted into the DAG, but, being incompatible, they are not going to be selected as best parent, hence they have no chance to appear on the MC, hence none of them can ever become last ball (which necessarily lies on MC).