> Then a "forkable string" assumes that s3 knows about B[s2], and since s3 is honest (as we assumed for our scenario) she will commit her new block C, >2 blocks away from O. Suppose she commits it 3 blocks away:
I think you're misunderstanding the protocol.
The purpose of the PVSS scheme outlined in section 5.2 is to provide all stakeholders with a verifiable random seed R, which they then independently use to identify all slot leaders for the epoch. This means that—irrespective of honesty—stakeholder si can only create a block in slot i. In particular, in your example stakeholders s2, s3, and s5 can only create blocks in slots 2, 3, and 5, respectively.
The strategy left to the dishonest stakeholder si is to create duplicate blocks in slot i and distribute them to different portions of the network. See figure 5 on p. 17 for an example.
> If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings.
The protocol definitely does not make this assumption. The purpose of the forkable strings analysis is to show that the probability that a random seed R generates an advantageous slot assignment for forking attacks decays exponentially with the number of slots in the epoch.
If honest nodes could all communicate reliably this analysis would be unnecessary. For example in the case given in figure 5, stakeholders s3 and s5 could both abandon their tines and fill in slots 3 and 5 on the middle tine.
I think you're misunderstanding the protocol.
The purpose of the PVSS scheme outlined in section 5.2 is to provide all stakeholders with a verifiable random seed R, which they then independently use to identify all slot leaders for the epoch. This means that—irrespective of honesty—stakeholder si can only create a block in slot i. In particular, in your example stakeholders s2, s3, and s5 can only create blocks in slots 2, 3, and 5, respectively.
The strategy left to the dishonest stakeholder si is to create duplicate blocks in slot i and distribute them to different portions of the network. See figure 5 on p. 17 for an example.
> If every honest node can reliably receive all honest nodes' blocks, we don't need any complex leadership selection algorithm nor the idea of forkable strings.
The protocol definitely does not make this assumption. The purpose of the forkable strings analysis is to show that the probability that a random seed R generates an advantageous slot assignment for forking attacks decays exponentially with the number of slots in the epoch.
If honest nodes could all communicate reliably this analysis would be unnecessary. For example in the case given in figure 5, stakeholders s3 and s5 could both abandon their tines and fill in slots 3 and 5 on the middle tine.