Describe `ConfirmationTarget::MaximumFeeEstimate` more accurately
What changed, and why it matters
This commit only changes a documentation comment for an enum variant called MaximumFeeEstimate. It does not modify any code logic, function behavior, or security mechanism. The change clarifies that the value represents the highest fee rate the user considers reasonable from a counterparty, and suggests adding a small buffer to account for estimation disagreements. There is no security fix or vulnerability present in the diff.
No action required. This is a documentation-only clarification. If reviewing related fee-estimation logic, consider whether the suggested buffer is already applied in caller code, but that is outside the scope of this commit.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch updates the rustdoc comment for ConfirmationTarget::MaximumFeeEstimate in lightning/src/chain/chaininterface.rs. It rephrases the description from ‘most aggressive (i.e. highest) feerate estimate available’ to ‘most aggressive feerate estimate which we think is reasonable’ and adds guidance that users may want to set this above their own maximum estimate to avoid rejecting honest counterparties. No code, types, constants, or logic were changed.
Changed components
lightning/src/chain/chaininterface.rs documentationInspect captured patch +5 / −2
diff --git a/lightning/src/chain/chaininterface.rs b/lightning/src/chain/chaininterface.rs
index b619821..1f945a5 100644
--- a/lightning/src/chain/chaininterface.rs
+++ b/lightning/src/chain/chaininterface.rs
@@ -49,11 +49,14 @@ pub trait BroadcasterInterface {
/// estimation.
#[derive(Clone, Copy, Debug, Hash, PartialEq, Eq)]
pub enum ConfirmationTarget {
- /// The most aggressive (i.e. highest) feerate estimate available.
+ /// The most aggressive feerate estimate which we think is reasonable.
///
/// This is used to sanity-check our counterparty's feerates and should be as conservative as
/// possible to ensure that we don't confuse a peer using a very conservative estimator for one
- /// trying to burn channel balance to dust.
+ /// trying to burn channel balance to dust. To ensure that this is never lower than an honest
+ /// counterparty's feerate estimate you may wish to use a value which is higher than your
+ /// maximum feerate estimate, for example by adding a constant few-hundred or few-thousand
+ /// sats-per-kW.
MaximumFeeEstimate,
/// We have some funds available on chain which we need to spend prior to some expiry time at
/// which point our counterparty may be able to steal them.
Why this scored 15/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.