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

splice: Make feerate opening + feerate_offset

Public commit record

What the developer wrote

Authored by Dusty Daemon

90/100 · Strong
splice: Make feerate opening + feerate_offset

Splicing feerate was being derived by `default_feerate` which was actually `unilateral_feerate`, which is incorrect.

Instead we define an explicit `splice_feerate` in the chain topology that is `opening` + `feerate_offset`.

This slipped through testing because regtest isn’t a great test of fees we see in the wild.

Changelog-Fixed: Fixes high fee issue that caused `splicein` and `spliceout` to abort.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a bug in Core Lightning's splicing feature where the fee rate used for splice transactions was accidentally based on the much higher 'unilateral close' fee rate instead of the intended 'opening' fee rate plus a small offset. The result was that normal splice-in and splice-out operations could be rejected or aborted because the calculated fee looked too high. The fix introduces a dedicated splice fee rate and updates the safety checks and tests accordingly. It is a correctness/availability issue rather than a remote exploit, but it could cause users to pay excessive fees or fail to use splicing.

Recommended action

Apply the patch. After upgrading, operators using splicing should see splice transactions use the lower, correct opening-based fee rate. Nodes that have not yet upgraded may experience splice aborts or overpayment when network unilateral-close feerates spike. No immediate incident response is required beyond normal patching.

Security signals we found

01

Incorrect fee-rate source used for splice transactions (unilateral close rate instead of opening rate)

02

New dedicated splice_feerate helper clamps value to feerate_max to prevent runaway fees

03

Balance safety checks in channeld updated to use max feerate boundary

04

Changelog explicitly calls this a 'high fee issue' fix

05

No remote attacker-controlled input identified; issue is operational/fee policy

Risk score

Why this scored 55/100

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