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

swaps: allow reverse swaps to external address

Public commit record

What the developer wrote

Authored by f321x

68/100 · Adequate
swaps: allow reverse swaps to external address

Implement logic to claim a reverse swap funding output to any given
address. This allows to do onchain payments to external recipients
through a submarine swap.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a feature to Electrum that lets users route reverse submarine swaps to an external Bitcoin address, effectively turning a Lightning payment into an on-chain payment to someone else. The change renames a database field, adds wallet-upgrade logic, and introduces a new code path that builds and broadcasts a claim transaction. There is no direct evidence in the commit of a security vulnerability, but the new code handles private keys, transaction signing, and broadcasting, so it is a sensitive area worth reviewing carefully.

Recommended action

Treat this as a feature commit in a security-sensitive area rather than a confirmed vulnerability. Reviewers should verify that _claim_to_output validates the external address format and script type, ensures the claim transaction cannot be fee-sniped or replayed, checks that ignore_warnings=True does not suppress important safety checks, and confirms the migration preserves wallet integrity. End users do not need to take immediate action unless the project later discloses a related security issue.

Security signals we found

01

New transaction signing and broadcast path added for reverse swap claims

02

wallet.sign_transaction called with ignore_warnings=True

03

External address accepted as claim destination with only a value assertion (claim_to_output.value < onchain_amount_sat)

04

Database schema migration deletes old field and adds new nullable field

05

Future transaction height logic depends on claim_txin.get_block_based_relative_locktime()

06

No explicit input validation or address-type checks visible in the diff for claim_to_output.address

Risk score

Why this scored 29/100

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