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

swaps: rm until filter when fetching server pairs

Public commit record

What the developer wrote

Authored by f321x

88/100 · Strong
swaps: rm until filter when fetching server pairs

The `until` filter would limit the relay to only send us events created
up until this timestamp. If the user opens a swap transport by opening
the swap dialog, and keeps the dialog open the dialog will naturally age
above this limit and the relay will stop sending the client swapserver
events as they have (legitimately) been created after this timestamp.

As sanity check we still have the comparison against the current
timestamp in the event parsing loop to prevent pre/backdating.

Fixes https://github.com/spesmilo/electrum/issues/10520
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit removes an 'until' time limit when Electrum asks a Nostr relay for swap server advertisements. Previously, if a user left the swap dialog open for more than an hour, the 'until' timestamp would expire and the relay would stop sending newly created swap server events, causing the client to miss live server offers. The fix keeps a 'since' window and still validates event timestamps when parsing, so backdated or pre-dated events are rejected. It is a reliability/availability fix for swap discovery rather than a cryptographic or theft bug.

Recommended action

Treat as a routine bugfix. Users who perform submarine swaps should upgrade to a version containing this commit to avoid stale or missing swap server offers. No immediate incident response is indicated.

Security signals we found

01

Time-window filter caused denial of live swap-server advertisements

02

Remaining timestamp sanity check in event parsing loop mitigates pre/backdating

03

Fixes reported issue #10520

04

No cryptographic, key-handling, or payment-flow code changed

Risk score

Why this scored 36/100

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