Quote from: monsterer2 on February 25, 2018, 10:59:28 AM

Quote from: Blinknet on February 24, 2018, 05:33:22 PM

Nothing the lockers say finalizes the state. A locker signed transaction needs to be confirmed by a majority of nodes to be accepted.
Like previously stated, consensus is delayed until approved by the majority, even with the risk of voiding the round. The fact that you keep mentioning a fork means that you're not very clear on how the algorithm works. Did you understand this from the consensus section? It could be the paper is not clear on it, but please try reading it again.

To be honest, the paper very hard to read. A lot of babble, and hardly anything about the attack vectors, or failure modes.

I'd like to see a description of how the consensus will freeze in the worst case, rather than forking in the case of a network partition, for example.

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.