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

Cache pending offer in specific invoice slot

Public commit record

What the developer wrote

Authored by Valentine Wallace

68/100 · Adequate
Cache pending offer in specific invoice slot

When we as an async recipient receive offer paths from the static invoice server,
we create an offer and cache it, retrying persisting a corresponding invoice with
the server until it succeeds.

In the initially-merged version of this protocol, we would put this cached
offer in any slot in the cache that needed an offer at the time the offer paths
were received. However, in the last commit we started requesting offer paths
for a specific slot in the cache, as part of eliminating the use of the
invoice_id field in the overall protocol.

As a result, here we put the cached offer in the specific cache slot that the
original OfferPathsRequest indicated, rather than any slot that could use a new
offer.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit tightens up how a Lightning node caches payment offers when receiving them from a static invoice server. Previously, the node would place a newly received offer into any open slot in its cache. After this change, it stores the offer only in the specific slot it originally requested. The change is part of a protocol cleanup to remove reliance on an invoice_id field. It is primarily a correctness and protocol-consistency fix rather than a clear security patch, though the old behavior could theoretically have allowed a server to confuse or overwrite unrelated cached offers.

Recommended action

Treat as a normal correctness/protocol-alignment commit. Reviewers should verify that all callers of cache_pending_offer and should_build_offer_with_paths pass a validated invoice_slot, and that the slot index cannot be attacker-controlled beyond the protocol's intended range. No urgent security action is indicated from the diff alone.

Security signals we found

01

Binding an incoming offer to a specific cache slot prevents cross-slot offer injection/overwriting

02

Removes server-influenced choice of which cached offer to replace

03

Adds slot validation and debug assertions for out-of-range slots

04

Refactors refresh logic into a dedicated needs_refresh helper

Risk score

Why this scored 26/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 5/15
Confidence 6/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.