From d392cdbd7d1ecc53f4ef26b5557ca3acdffeb1d3 Mon Sep 17 00:00:00 2001 From: "Tobin C. Harding" Date: Tue, 18 Feb 2025 13:28:11 +1100 Subject: [PATCH] Remove PartialOrd from locktimes Currently it is possible to write ```rust if this_locktime < that_locktime { do_this(); } ``` with the hope that this code means if a locktime is satisfied by the value in the other locktime. This is a footgun because locktimes are incommensurate. We provide the `is_satisfied_by` API to help users do locktime comparisons. Remove the `PartialOrd` implementation from both locktime types. --- primitives/src/locktime/absolute.rs | 23 +++-------------------- primitives/src/locktime/relative.rs | 22 +++------------------- 2 files changed, 6 insertions(+), 39 deletions(-) diff --git a/primitives/src/locktime/absolute.rs b/primitives/src/locktime/absolute.rs index da8ef86b7..6d88388db 100644 --- a/primitives/src/locktime/absolute.rs +++ b/primitives/src/locktime/absolute.rs @@ -28,7 +28,9 @@ pub use units::locktime::absolute::{ConversionError, Height, ParseHeightError, P /// ### Note on ordering /// /// Locktimes may be height- or time-based, and these metrics are incommensurate; there is no total -/// ordering on locktimes. We therefore have implemented [`PartialOrd`] but not [`Ord`]. +/// ordering on locktimes. In order to compare locktimes, instead of using `<` or `>` we provide the +/// [`LockTime::is_satisfied_by`] API. +/// /// For [`Transaction`], which has a locktime field, we implement a total ordering to make /// it easy to store transactions in sorted data structures, and use the locktime's 32-bit integer /// consensus encoding to order it. We also implement [`ordered::ArbitraryOrd`] if the "ordered" @@ -319,19 +321,6 @@ impl From