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

lnrouter: use separate timestamp per liquidity hint value

Public commit record

What the developer wrote

Authored by f321x

85/100 · Strong
lnrouter: use separate timestamp per liquidity hint value

Use a separate timestamp for each value in a `LiquidityHint`
instead of a single shared one for all values.

Fixes:
1. We send 1M sat, failure, record cannot_send = 1M
2. Two hours pass, hint expired (shared ts reset)
3. We send 10k, update_can_send resets the shared ts
> cannot_send is active again, even though it is outdated
> We won't try sending >1M sat through the channel until the
process is restarted and the in-memory data is gone.

The setter method comparisons now also use the value from the getter
to prevent an expired larger value from blocking a new smaller one.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit fixes a bug in Electrum's Lightning payment routing that could cause the wallet to avoid using a channel for large payments longer than it should. After a small payment succeeded, an old record of a failed large payment could incorrectly become active again, making Electrum think the channel still could not handle large amounts until the app was restarted. The fix gives each routing hint its own expiration timestamp instead of sharing one across all hints.

Recommended action

Reviewers should verify that HINT_DURATION boundaries are correctly handled and that the new per-value expiry does not introduce any path where a stale can_send could incorrectly override a fresh cannot_send. The regression test should be run. No immediate security advisory appears necessary, but the fix should be included in the next release.

Security signals we found

01

Logic bug in routing state expiration could cause denial of service for large Lightning payments

02

Shared timestamp allowed stale failure hints to be reactivated by unrelated success updates

03

Setter comparisons against raw internal values instead of getter-validated values allowed expired hints to block new data

04

Fix includes regression test demonstrating expiry resurrection scenario

Risk score

Why this scored 51/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 10/15
Affected reach 10/15
Confidence 7/10
Evidence quality 4/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.