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

Merge pull request #10877 from f321x/swaps_pop_invoice

Public commit record

What the developer wrote

Authored by ThomasV

73/100 · Adequate
Merge pull request #10877 from f321x/swaps_pop_invoice

swap server: simplify LN invoice payment
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides an explanatory body✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit refactors how Electrum's submarine-swap server pays Lightning invoices from clients. The main visible change is that the swap server no longer maintains its own retry queue for pending invoices; instead it delegates directly to the wallet's existing invoice-payment logic, which now rejects duplicate in-flight payment attempts. A new regression test confirms that a second payment attempt with the same payment hash is blocked while the first is still running. The commit also fixes a small bug where an HTTP endpoint called a coroutine without awaiting it. Overall the change looks like a hardening/cleanup rather than an obvious vulnerability fix, but it removes a custom retry mechanism and tightens duplicate-payment protection, which can have security relevance in Lightning.

Recommended action

Review the change as a defensive refactor. Verify that removing the swap-server retry loop does not allow a client to trigger repeated payment attempts by re-submitting the same invoice, and that the wallet-level duplicate-in-flight guard is sufficient. Run the new regression test and consider whether additional swap-server-specific tests are needed.

Security signals we found

01

Duplicate payment attempt prevention added/tested for in-flight Lightning invoices

02

Custom swap-server invoice retry queue removed in favor of wallet-level payment logic

03

Missing await on async server_add_swap_invoice() fixed in HTTP handler

04

Payment status update moved into finally block, ensuring status is always set

05

Invoice status check changed from payment-direction-based to invoice-based

Risk score

Why this scored 42/100

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