AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 28 Bitcoin

Async recipient: track static invoice creation time

Public commit record

What the developer wrote

Authored by Valentine Wallace

73/100 · Adequate
Async recipient: track static invoice creation time

Start tracking invoice creation time in cached async offers. This field will be
used in the next commit to start only updating static invoices for Used offers
every few hours instead of once a minute.

We also remove the blinded path context
StaticInvoicePersisted::path_absolute_expiry field here, replacing it with the
new invoice_created_at field. We don't actually want to terminate early if the
reply path a bit stale like we did before, since we want to use the
invoice_created_at field regardless to drive a faster refresh of the invoice.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how a Lightning node tracks timing information for cached asynchronous payment offers. It replaces the previous 'reply path expiry' timestamp with a new 'invoice creation time' timestamp. The stated goal is to enable less frequent refreshes of static invoices in a follow-up commit. A side effect is that the node no longer ignores 'invoice persisted' messages just because the reply path is a little stale. The change is framed as a refactor/preparation step, not a security fix.

Recommended action

Review the follow-up commit that uses invoice_created_at to throttle static invoice updates, and verify that removing the stale-path drop does not allow replay or acceptance of outdated invoices beyond safe windows. Consider whether a replacement freshness bound (e.g., maximum invoice age) is enforced elsewhere before relying on this change in production.

Security signals we found

01

Removal of an expiry-based drop/ignore check on async payment reply paths

02

Replacement of path_absolute_expiry with invoice_created_at in persisted state

03

Deletion of test ignore_expired_invoice_persisted_message that enforced stale-path rejection

04

Serialization format change for cached offer status (TLV required field)

05

Behavior change: stale StaticInvoicePersisted messages are now processed rather than discarded

Risk score

Why this scored 28/100

Our methodology →
Potential impact 4/30
Exploitability 3/25
Stealth signal 5/15
Affected reach 6/15
Confidence 7/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.