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

Adjust FundingContribution for acceptor

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

58/100 · Thin
Adjust FundingContribution for acceptor

When constructing a FundingContribution, it's always assumed the
estimated_fee is for when used as the initiator, who pays for the common
fields and shared inputs / outputs. However, when the contribution is
used as the acceptor, we'd be overpaying fees.

Additionally, the initiator's chosen fee rate may not be compatible with
the acceptors contributions. The selected UTXOs may not be enough to pay
for a higher feerate (i.e., the change output is not enough to pay or
there is no change output).

This change provides a method on FundingContribution for adjusting the
fee rate with the above concerns in mind. It also updates it to include
a max_feerate specified by the user when initiating a splice. This
ensures the acceptor isn't forced to pay an overly high fee rate.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a fee-calculation bug in Lightning splicing. Previously, when both sides tried to splice at the same time, the loser of a tie-break (the 'acceptor') built their contribution as if they were going to pay for the whole shared transaction. That made them overpay fees, and a high fee rate chosen by the other side could drain more from their wallet than intended or even make the transaction invalid. The patch adds logic to re-estimate fees from the acceptor's perspective and lets users set a maximum fee rate they are willing to accept.

Recommended action

Review the new fee-adjustment logic for off-by-one and dust-limit edge cases; ensure the max_feerate default in existing callers (FeeRate::MAX) is intentional and documented; run the new unit tests and any splicing integration/fuzz tests.

Security signals we found

01

Fee overpayment / economic griefing: acceptor previously paid fees estimated for the initiator role

02

Insufficient-fee risk: acceptor's selected UTXOs might not cover a higher counterparty feerate

03

New defensive validation: min_feerate > max_feerate is rejected at API entry

04

New fee-buffer checks with checked arithmetic to prevent overflow and underpayment

05

Splice-out balance check prevents spending more than the channel balance

Risk score

Why this scored 44/100

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