Agree that the paper is hard to read, and that's partially unavoidable due to the complexity of the algorithm, and how all the parts are actually needed to work together. What exactly would you say is babble?

We haven't seen anyone understand the way the system works in under a day (including any of us), and you started making comments about an hour after we posted, so pretty sure you just skimmed through the paper.
It's understandable that you may not have the time to do a rigorous analysis, we're just some guys asking for advice on a forum, but what's the point in asking for attack vectors of a thing you don't understand?

We've actually pointed you to page 31 in a previous post, where we explicitly state that a majority of the network needs to agree on the state within a certain number of rounds, or else it's considered void, penalizing nodes essentially. Can you say why this doesn't say that consensus will freeze in the worst case?

There are a lot of other bits of analysis we could have added to the paper, but it would have made it over 100 pages long, without anything essential to understanding the core, since we've seen these naturally clear-up for the people that understood the core protocol, realizing that those issues apply to blockchain-based consensus and not to our algorithm.

I know you may be used to people posting crap algorithm that are easily dismissed by showing their obvious holes, and it's understandable why you'd fire some automatic arguments, they're usually valid. Still, I hope you can see that's not the case with us and that we're working on different assumptions than blockchain consensus developers.