As with the current proposed change 31872905167c5205f92a670af6a5b2f2ae1e1626, a buffer should be introduced only for the upper bound. If introduced for the lower bound, timestamps cannot be guaranteed to monotonically increase.
My slight concern is, if the buffer for the upper bound is too large compared to the block period, it might damage the soundness of the election:
As an extreme example, suppose that a leader with an outstandingly advanced system time created a block in the previous round, and most validators barely approved the block thanks to the large buffer. In this case, other leaders in the current round might not be able to create timestamps that meet the lower bound, which means view changes will be repeated until the same amount of time as the buffer has elapsed or the same leader as in the previous round is elected
My slight concern is, if the buffer for the upper bound is too large compared to the block period, it might damage the soundness of the election: As an extreme example, suppose that a leader with an outstandingly advanced system time created a block in the previous round, and most validators barely approved the block thanks to the large buffer. In this case, other leaders in the current round might not be able to create timestamps that meet the lower bound, which means view changes will be repeated until the same amount of time as the buffer has elapsed or the same leader as in the previous round is elected
_Originally posted by @s8sato in https://github.com/hyperledger/iroha/pull/4928#discussion_r1714319195_