Relax feerate requirements in `TxBuilder::get_next_commitment_stats`
What changed, and why it matters
This commit relaxes an internal requirement about when a special fee rate (used to limit dust exposure) must be provided when computing commitment transaction statistics. Previously, callers had to fabricate a fake fee rate just to avoid triggering a debug assertion, even when they did not care about dust exposure. The change allows callers to pass None for that fee rate, simplifying internal code. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a cleanup/refactoring change.
Review as normal code maintenance. No immediate security action is indicated by the commit itself. If this change is being backported, verify that the removed debug assertion did not mask any invariant needed for correct fee or dust handling in production builds (debug_assert is typically compiled out in release builds).
Security signals we found
Removes a debug assertion coupling dust exposure fee rate to channel type
Changes fee arithmetic fallback from 0 to feerate_per_kw when dust_exposure_limiting_feerate is None
Commit message does not describe security relevance
Evidence from the diff
In TxBuilder::get_next_commitment_stats, the code previously required dust_exposure_limiting_feerate to be Some(feerate_per_kw) for non-zero-fee commitment channels, and enforced this with a debug assertion. The commit removes that assertion and changes the excess feerate calculation to treat a missing dust fee rate as equivalent to the current feerate (so excess becomes zero). This lets callers that only want basic commitment stats (balances, fees) pass None without hitting a debug assert. The change is small and localized, and the commit message frames it as a relaxation of requirements for convenience, not a security fix.
Changed components
lightning/src/ln/channel.rslightning/src/sign/tx_builder.rsInspect captured patch +4 / −16
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 4cb417f..d30089f 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -11979,21 +11979,12 @@ where
fn get_holder_counterparty_balances_floor_incl_fee(
&self, funding: &FundingScope,
) -> Result<(Amount, Amount), String> {
- // We don't care about the exact value of `dust_exposure_limiting_feerate` here as
- // we do not validate dust exposure below, but we want to avoid triggering a debug
- // assert.
- //
- // TODO: clean this up here and elsewhere.
- let dust_exposure_limiting_feerate =
- if funding.get_channel_type().supports_anchor_zero_fee_commitments() {
- None
- } else {
- Some(self.context.feerate_per_kw)
- };
let include_counterparty_unknown_htlcs = true;
// Make sure that that the funder of the channel can pay the transaction fees for an additional
// nondust HTLC on the channel.
let addl_nondust_htlc_count = 1;
+ // We are not interested in dust exposure
+ let dust_exposure_limiting_feerate = None;
let local_commitment_stats = self
.context
diff --git a/lightning/src/sign/tx_builder.rs b/lightning/src/sign/tx_builder.rs
index a4bcdff..8583bde 100644
--- a/lightning/src/sign/tx_builder.rs
+++ b/lightning/src/sign/tx_builder.rs
@@ -206,11 +206,8 @@ impl TxBuilder for SpecTxBuilder {
channel_type: &ChannelTypeFeatures,
) -> Result<NextCommitmentStats, ()> {
let excess_feerate_opt =
- feerate_per_kw.checked_sub(dust_exposure_limiting_feerate.unwrap_or(0));
- // Dust exposure is only decoupled from feerate for zero fee commitment channels.
- let is_zero_fee_comm = channel_type.supports_anchor_zero_fee_commitments();
- debug_assert_eq!(is_zero_fee_comm, dust_exposure_limiting_feerate.is_none());
- if is_zero_fee_comm {
+ feerate_per_kw.checked_sub(dust_exposure_limiting_feerate.unwrap_or(feerate_per_kw));
+ if channel_type.supports_anchor_zero_fee_commitments() {
debug_assert_eq!(feerate_per_kw, 0);
debug_assert_eq!(excess_feerate_opt, Some(0));
debug_assert_eq!(addl_nondust_htlc_count, 0);
Why this scored 20/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.