I think there is another possible improvement in [PBTS-ALG-UPON-PROP.1].

The timely check is added to the upon clause, but, in the case where we have lockedValue_p = v, we should not call timely for the same reason we don't call timely in lines 28-33 of the arXiv algorithm.

I think there is another possible improvement in [PBTS-ALG-UPON-PROP.1].

The timely check is added to the upon clause, but, in the case where we have lockedValue_p = v, we should not call timely for the same reason we don't call timely in lines 28-33 of the arXiv algorithm.

Potential fix.

upon ⟨PROPOSAL, h_p, round_p, v, −1⟩ from proposer(h_p, round_p) while step_p = propose do {
  if (lockedValue_p = v) || (lockedRound_p = −1 && valid(v) && timely(v)) {
    broadcast ⟨PREVOTE, h_p, round_p, id(v)⟩ 

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Hey, getting here late. I don't see any practical effect from this change. The point of that line is to ensure that the current time is higher than the timestamp of the previous block. This (being too fast) can happen in any scenario, but it is much more likely to happen in round 0, when we don't have a valid block. We can only have a valid block from round 1, when it is pretty unlikely that we have to wait for the local time to be higher than last block's time.

In summary, this wait is just a safety anchor to slow down fast validators. It should not really impact the practical operation of any node, and if it does it will be at round 0, when there is no valid block. I would keep as it was, mostly because I can't see any benefits from this change, and it is also more clear (and the goal of the spec is this) to just do this check in every round.

Some more context, which should have been in the description.
We have been discussing how to implement PBTS at the app level. In this case, delaying the proposal is made inside prepareProposal. However, if there is a validBlock, prepareProposal is not called.
By fixing the spec in the proposed way, it captures this behavior as valid.

A similar argument serves for the @sergio-mena 's proposal. If the block is valid it will not be passed to processProposal, where its "timely"ness would be evaluated.

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

This discussion should be reopened when we port PBTS to main.

This discussion was taken into consideration when merging the specs from master to main.