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

Include change output weight in estimate_transaction_fee

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Include change output weight in estimate_transaction_fee

Add a `change_output: Option<&TxOut>` parameter to
`estimate_transaction_fee` so the initial fee estimate accounts for the
change output's weight. Previously, the change output weight was omitted
from `estimated_fee` in `FundingContribution`, causing the estimate to
be slightly too low when a change output was present.

This also eliminates an unnecessary `Vec<TxOut>` allocation in
`compute_feerate_adjustment`, which previously cloned outputs into a
temporary Vec just to include the change output for the fee estimate.

A mock `TightBudgetWallet` is added to `splicing_tests` to demonstrate
that `validate()` correctly rejects contributions where the input value
is sufficient without the change output weight but insufficient with it.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
✓ 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 a fee-estimation bug in rust-lightning's channel funding and splicing code. When building a transaction that creates a change output, the code previously forgot to include the change output's size/weight when estimating the required transaction fee. That made the fee estimate slightly too low. The patch adds the missing weight and adds a test showing that a contribution with barely enough money would now be correctly rejected, whereas before it might have been accepted and later failed to broadcast or confirm reliably.

Recommended action

Treat as a routine correctness/defensive fix. Review callers of `estimate_transaction_fee` to ensure the new `change_output` argument is supplied everywhere. Consider whether any production wallet integrations could have produced under-funded splice/funding transactions and monitor for related failures. No emergency response is indicated by the diff alone.

Security signals we found

01

Underestimation of transaction fees in funding/splicing transaction construction

02

Potential acceptance of under-funded contributions leading to invalid or non-broadcastable transactions

03

Added defensive validation test (`test_validate_accounts_for_change_output_weight`)

04

No explicit CVE, advisory, or security disclosure referenced in commit

Risk score

Why this scored 37/100

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