server: do not auto-enable RBF coop close for overlay channels
What the developer wrote
Authored by George Tsagkarelis
server: do not auto-enable RBF coop close for overlay channels
An earlier commit added an auto-enable that forces RbfCoopClose=true
whenever either taproot channel flag is set. This breaks
taproot-overlay channels, because the RBF coop close state machine in
lnwallet/chancloser/rbf_coop_*.go does not integrate the AuxCloser
(or any other aux) hook that overlay channels depend on to build
aux-aware close transactions. A node that enables
--protocol.simple-taproot-overlay-chans ends up with RBF force-on and
its overlay channel closes silently fail, leaving the aux closer
unable to finalize on-chain.
Narrow the auto-enable so it only fires for TaprootChans (staging /
final taproot) and explicitly skips it when TaprootOverlayChans is set.
Operators that positively want RBF can still opt in via
--protocol.rbf-coop-close; this change only removes the forced path
that silently breaks overlay closes.
What changed, and why it matters
This commit fixes a configuration bug in the LND Lightning node software. Previously, enabling experimental 'taproot-overlay' channels automatically forced on a related but incompatible 'RBF cooperative close' feature. That combination would silently break channel closings for those overlay channels. The patch narrows the auto-enable so it does not apply when overlay channels are turned on, while users who want RBF can still opt in manually. There is no attacker exploit here; it is a reliability/functional bug fix.
Treat as a normal bug fix. Users running --protocol.simple-taproot-overlay-chans should upgrade to avoid silent cooperative close failures. No emergency security response is warranted because the issue is a reliability incompatibility, not an exploitable vulnerability.
Security signals we found
Functional bug in feature flag interaction
Silent failure of channel close operations
No input validation or memory safety issue visible
No cryptographic or network-level vulnerability evident
Evidence from the diff
The change in server.go revises the condition that auto-enables cfg.ProtocolOptions.RbfCoopClose. Originally it was enabled whenever either TaprootChans or TaprootOverlayChans was set. The new condition enables it only when TaprootChans is true and TaprootOverlayChans is false. The commit message explains that the RBF cooperative close state machine (lnwallet/chancloser/rbf_coop_*.go) does not integrate the AuxCloser hook required by taproot-overlay channels, so forcing RBF on overlay channels causes cooperative closes to fail silently. The fix removes the forced path; operators can still opt in via –protocol.rbf-coop-close.
Changed components
server.goProtocol option configuration logicTaproot overlay channels featureRBF cooperative close featureInspect captured patch +12 / −5
diff --git a/server.go b/server.go
index 9eddf92..09cb485 100644
--- a/server.go
+++ b/server.go
@@ -670,11 +670,18 @@ func newServer(ctx context.Context, cfg *Config, listenAddrs []net.Addr,
"in a standalone lnd build")
}
- // If either taproot channel type is enabled, we also need to enable
- // the RBF cooperative close protocol, as it is required for taproot
- // channel interoperability.
- if cfg.ProtocolOptions.TaprootChans ||
- cfg.ProtocolOptions.TaprootOverlayChans {
+ // If taproot channels are enabled, we also enable the RBF cooperative
+ // close protocol, as it is required for taproot channel
+ // interoperability.
+ //
+ // Exception: when taproot-overlay channels are enabled we do NOT
+ // auto-enable RBF, because the RBF coop close state machine does not
+ // yet thread through the AuxCloser hook that overlay channels rely on
+ // to build the aux-aware close transaction. Forcing RBF on for a
+ // node that holds overlay channels would silently break their coop
+ // closes.
+ if cfg.ProtocolOptions.TaprootChans &&
+ !cfg.ProtocolOptions.TaprootOverlayChans {
cfg.ProtocolOptions.RbfCoopClose = true
}
Why this scored 39/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.