server: use new FundingConfsForAmounts helper func
What the developer wrote
Authored by Olaoluwa Osuntokun
server: use new FundingConfsForAmounts helper func
What changed, and why it matters
This commit is a simple code cleanup in LND. It removes an inline calculation that decided how many confirmations a new Lightning channel needs before being considered open, and replaces it with a call to a new helper function named FundingConfsForAmounts. The change itself does not appear to alter the security behavior; it just moves the same logic into a shared helper. There is no indication of a security fix or vulnerability.
No security action required. Treat as routine refactor. If assessing risk, verify that lnwallet.FundingConfsForAmounts preserves the prior 3–6 confirmation scaling and wumbo-channel max-conf behavior, but the diff itself does not suggest a change.
Security signals we found
No strong security signals were identified.
Evidence from the diff
In server.go, the anonymous NumRequiredConfs callback previously computed confirmation requirements inline: 3–6 confirmations scaled linearly by channel amount plus push amount, with wumbo channels (> MaxFundingAmount) requiring the maximum. The patch deletes that inline logic and delegates to lnwallet.FundingConfsForAmounts(chanAmt, pushAmt). The commit message and diff only describe a refactor to use a new helper function. No security relevance, bug fix, or behavior change is stated or visible in the diff.
Changed components
lnd/server.goNumRequiredConfs callback in newServerInspect captured patch +11 / −33
diff --git a/server.go b/server.go
index 06e5e8f..508ffed 100644
--- a/server.go
+++ b/server.go
@@ -1482,16 +1482,6 @@ func newServer(ctx context.Context, cfg *Config, listenAddrs []net.Addr,
DefaultMinHtlcIn: cc.MinHtlcIn,
NumRequiredConfs: func(chanAmt btcutil.Amount,
pushAmt lnwire.MilliSatoshi) uint16 {
- // For large channels we increase the number
- // of confirmations we require for the
- // channel to be considered open. As it is
- // always the responder that gets to choose
- // value, the pushAmt is value being pushed
- // to us. This means we have more to lose
- // in the case this gets re-orged out, and
- // we will require more confirmations before
- // we consider it open.
-
// In case the user has explicitly specified
// a default value for the number of
// confirmations, we use it.
@@ -1500,29 +1490,17 @@ func newServer(ctx context.Context, cfg *Config, listenAddrs []net.Addr,
return defaultConf
}
- minConf := uint64(3)
- maxConf := uint64(6)
-
- // If this is a wumbo channel, then we'll require the
- // max amount of confirmations.
- if chanAmt > MaxFundingAmount {
- return uint16(maxConf)
- }
-
- // If not we return a value scaled linearly
- // between 3 and 6, depending on channel size.
- // TODO(halseth): Use 1 as minimum?
- maxChannelSize := uint64(
- lnwire.NewMSatFromSatoshis(MaxFundingAmount))
- stake := lnwire.NewMSatFromSatoshis(chanAmt) + pushAmt
- conf := maxConf * uint64(stake) / maxChannelSize
- if conf < minConf {
- conf = minConf
- }
- if conf > maxConf {
- conf = maxConf
- }
- return uint16(conf)
+ // Otherwise, scale the number of confirmations based on
+ // the channel amount and push amount. For large
+ // channels we increase the number of
+ // confirmations we require for the channel to be
+ // considered open. As it is always the
+ // responder that gets to choose value, the
+ // pushAmt is value being pushed to us. This
+ // means we have more to lose in the case this
+ // gets re-orged out, and we will require more
+ // confirmations before we consider it open.
+ return lnwallet.FundingConfsForAmounts(chanAmt, pushAmt)
},
RequiredRemoteDelay: func(chanAmt btcutil.Amount) uint16 {
// We scale the remote CSV delay (the time the
Why this scored 11/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.