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

splice: Fix weight calculations & use opening feerate

Public commit record

What the developer wrote

Authored by Dusty Daemon

73/100 · Adequate
splice: Fix weight calculations & use opening feerate

Here we update `psbt_input_get_weight` to allow the caller to specify what kind of input size estimation they would like. Before it was just “zero witness bytes” which we now move to the default behavior and add an assumption option for P2WSH -> 2of2 multisig which is what we typically see in splicing.

At the same time we move channeld over to using the opening feerate estimation instead of the less useful “max feerate.” We make splice script use this same feerate.

After auditing the feerates for these two places against each other and the actually created transaction, we implement some fixes making them all match.

While we’re here, we add relevant debug log messages.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes how Core Lightning estimates the size (and therefore the required mining fee) of Bitcoin transactions used in channel splicing. Before, the code underestimated input weights for common 2-of-2 multisig splicing inputs and used a less useful 'maximum feerate' as a safety cap. The patch adds better size-estimation options, switches the safety cap to the 'opening feerate,' and aligns the math between the different components that negotiate a splice. The main risk is that incorrect fee math could cause a splice transaction to be rejected by the network (too low fee) or to overpay/underpay, potentially disrupting channel operations or funds movement.

Recommended action

Treat as a correctness fix with operational-security implications. Review the updated weight calculations against real splicing transactions, run splicing tests with varied input types (P2WSH 2-of-2, P2WPKH, P2TR), and verify that the new opening-feerate cap behaves safely under volatile mempool conditions. Monitor for any follow-up commits that further adjust these calculations.

Security signals we found

01

Incorrect transaction weight estimation could lead to insufficient fees, causing transactions to stall or be rejected

02

Use of 'max feerate' as a fee cap could permit overpayment or unsafe fee acceptance; replaced with opening feerate

03

Splicing involves collaborative transaction construction where one peer's miscalculation can affect the other's funds

04

Fixes are framed as matching estimated weight against the actually created transaction, implying prior discrepancy

05

No explicit vulnerability identifier, exploit proof, or security advisory is present in the commit or supplied references

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.