cometbft · zrbecker · Apr 20, 2025 · Mar 26, 2025 · Mar 26, 2025 · Mar 26, 2025
@@ -113,6 +113,8 @@ among all of the validators in the network.
 Any two validators are expected to have clocks that differ by at most
 `Precision` at any given instant.
 
+**Note:** The `Precision` value must not exceed 30 seconds. This is a hard-coded upper limit enforced in the implementation to avoid overflow errors when used in timestamp calculations.
+
 The `Precision` parameter is of [`time.Duration`](https://pkg.go.dev/time#Duration) type.
 
 Networks should choose a `Precision` that is large enough to represent the
@@ -126,6 +128,9 @@ The `MessageDelay` parameter configures the acceptable upper-bound for the
 end-to-end delay for transmitting a `Proposal` message from the proposer to
 _all_ validators in the network.
 
+**Note:** The `MessageDelay` value must not exceed `24 hours`. This cap is enforced in the implementation to avoid overflow errors in time-based computations, especially when combined with round-based  
+exponential delay adjustments.
+
 The `MessageDelay` parameter is of [`time.Duration`](https://pkg.go.dev/time#Duration) type.
 
 Networks should choose a `MessageDelay` that is large enough to represent the

@@ -71,6 +71,12 @@ proposal message broadcast by correct processes: it is a *worst-case* parameter.
 As message delays depends on the message size, the above requirement implicitly
 indicates that the size of proposal messages is either fixed or upper bounded.
 
+**Note:** In the actual implementation of PBTS, the system parameters `MSGDELAY` and `PRECISION` are capped to upper bounds in order to prevent overflow errors in time-based computations:
+- `MSGDELAY ≤24h`
+- `PRECISION ≤30s`
+
+These limits are not inherent to the formal model, and do not affect its properties. They are practical constraints introduced in the implementation to ensure arithmetic safety.
+
 #### **[PBTS-MSG-DELAY-ADAPTIVE.0]**
 
 This specification is written assuming that there exists an end-to-end maximum

@@ -568,6 +568,10 @@ These parameters are part of the Proposer-Based Timestamps (PBTS) algorithm.
 For more information on the relationship of the synchrony parameters to
 block timestamps validity, refer to the [PBTS specification][pbts].
 
+**Note:** Both `precision` and `message_delay` have upper bounds enforced in the implementation to prevent overflow errors during timestamp validation:
+- `precision` must not exceed `30s`
+- `message_delay` must not exceed `24h`
+
 [pbts]: ../consensus/proposer-based-timestamp/README.md
 [bfttime]: ../consensus/bft-time.md
 [proto-duration]: https://protobuf.dev/reference/protobuf/google.protobuf/#duration