Drop one-year limit on invoice expiry

[TheBlueMatt]

We shouldn't fail to parse just because an invoice is kinda dumb. This should be more practical now that we switched to Duration instead of SystemTime.

[jkczyz]

Seems the simplest way to fix this for 64-bit systems is:

diff --git a/lightning-invoice/src/lib.rs b/lightning-invoice/src/lib.rs
index b6abecf3..91a7d3a8 100644
--- a/lightning-invoice/src/lib.rs
+++ b/lightning-invoice/src/lib.rs
@@ -88,11 +88,11 @@ pub use de::{ParseError, ParseOrSemanticError};
 // TODO: fix before 2037 (see rust PR #55527)
 /// Defines the maximum UNIX timestamp that can be represented as `SystemTime`. This is checked by
 /// one of the unit tests, please run them.
-const SYSTEM_TIME_MAX_UNIX_TIMESTAMP: u64 = core::i32::MAX as u64;
+const SYSTEM_TIME_MAX_UNIX_TIMESTAMP: u64 = (core::usize::MAX >> 1) as u64;
 
 /// Allow the expiry time to be up to one year. Since this reduces the range of possible timestamps
 /// it should be rather low as long as we still have to support 32bit time representations
-const MAX_EXPIRY_TIME: u64 = 60 * 60 * 24 * 356;
+const MAX_EXPIRY_TIME: u64 = (core::usize::MAX >> 7) as u64;
 
 /// Default expiry time as defined by [BOLT 11].
 ///
@@ -1277,7 +1277,10 @@ impl Invoice {

32-bit systems would support a bit over a year of expiry. Presuming for both the representation is based around usize at least.

Otherwise, we could get rid of MAX_EXPIRY_TIME entirely, but I think there's still some edge case in Invoice::would_expire.

[TheBlueMatt]

Wait, I'm confused why usize would imply only a year? We should have until 2038 :)

[jkczyz]

Ah, it would only imply a year if you had to add the creation since Unix epoch to the relative expiry (offset from creation time) in order to get an expiry offset from the Unix epoch. But after a closer look it seems we only add the two in Invoice::would_expire, where they are represented as the u64-based Duration. So addition would only be a problem for extremely large durations, now that I think of it, and could be handled independent of SystemTime representation.

[TheBlueMatt]

Right, I figured basically since we moved to Duration we can get away with not really caring anymore.