Re: BYTEBALL: Totally new consensus algorithm + private untraceable payments
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.
Afaics your design has the "nothing-at-stake" flaw. This is a generalized flaw that applies to most designs that don't use proof-of-work. I suggest you read Vitalik's blogs about this:
https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
https://blog.ethereum.org/2014/07/05/stake/
When I entered Dash's (DarkCoin's) thread and explained to Evan that he had a flaw. He invented masternodes to solve the problem. Dash then became the #1 anonymity coin, because I had helped him early identify a flaw.
i enter in this discution without experience..but from a logical point of view..i think that "imnotback" raise a probleme of security..because if one user can become full witness..this one can troll her confirmation branch if this one isn't confirmed by witness genese..user can buil her branch of confirmation and rob bytes of other user passing on her branch..If he no longer needs to report to the genese witnesses.
testnet (tn) work good
but i dont undersand..chatbot said distrib starting after 25 december..it isn't the first begin of livenet distrib 
in more chatbot cant check address balance of btc testnet..i suppose this is normal ?!