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

lnworker: use config lightning fee for estimate

Public commit record

What the developer wrote

Authored by f321x

80/100 · Strong
lnworker: use config lightning fee for estimate

I was unable to do a "Max" amount submarine swap because the
`fee_estimate` method used by `LNWallet.num_sats_can_send()` uses a
hardcoded `fee_proportional_millionths` to estimate the fee for the
lightning payment.
When the actual fee determined later is higher
than the estimated fee the payment fails as the channel is unable to add
the htlc sum including the real fees as the amount exceeds the balance of
the channel.
Using the fees the maximum fees user has configured and estimate the
potential fee as inverse of PaymentFeeBudget is more
reliable/conservative as we definitely aren't going to pay more fees
than this amount.
✓ 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 wallet where the app guessed Lightning routing fees using hardcoded values. The old guess could be too low, causing 'Max' amount submarine swaps and similar payments to fail because the real fee later exceeded the reserved amount. The patch now uses the user's own configured maximum fee settings to make a more conservative estimate, so the wallet reserves enough for fees upfront.

Recommended action

No immediate security action required; this is a reliability/bug-fix improvement. Users relying on submarine swaps or max Lightning sends should benefit from fewer failed payments. Reviewers may want to verify the inverse math handles edge cases (e.g., very small amounts, zero config values) correctly.

Security signals we found

01

Fixes a functional bug in fee estimation that could cause payment failures

02

Replaces hardcoded fee constants with user-configured maximum fee budget

03

Adds clamping constants and inverse fee calculation to PaymentFeeBudget

04

Adds unit tests for the new reverse fee calculation

Risk score

Why this scored 20/100

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