With PBTS, proposed values (for the first time) can only be accepted when they are timely. This requires comparing the proposal time with the time at which the proposal is received by a validator. One of the rules, for rejecting proposal times too much in the past, assumes a maximum propagation delay MSGDELAY for Proposal messages.

In the original PBTS specification, the MSGDELAY parameter, together with ACCURACY, was also used to compute a minimum duration for the propose round step timeout. The rationale is that a validator should not timeout, thus prevoting nil, while a timely proposal could still be received.

Several internal discussions occurred after this specification was compiled, and some preliminary decisions are not in line with this association between timeout_propose and MSGDELAY parameters.

A first reason is the decision to evaluate the timely predicate upon receiving a Proposal message, not upon receiving the full proposed value, carried by BlockPart messages. While the timeout_propose duration should encompass the maximum delay for receiving the full proposed value/block, MSGDELAY only considers the maximum delay for a Proposal message.

A second reason is the fact that MSGDELAY is a parameter added to the proposal time field, i.e., its timestamp. So, the fact that a process enters a round before or after, in terms of real time, the proposer does that is not reflected by this parameter. But this lack of synchronization between processes should be taken into consideration when configuring the timeout_propose.

So, in particular while we consider MSGDELAY a fixed parameter, that is not incremented when rounds of consensus fail, I propose to remove this association between timeout_propose and MSGDELAY.