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

peer: never use RBF coop close for aux channels

Public commit record

What the developer wrote

Authored by Jared Tobin

76/100 · Adequate
peer: never use RBF coop close for aux channels

The RBF coop close flow was selected purely from the peer-level
feature bits (rbfCoopCloseAllowed), with no per-channel exclusion.
The RBF close state machine does not invoke any of the aux closer
hooks: the Shutdown message it sends carries no aux custom records,
and the close transaction it negotiates contains no aux outputs. For
a taproot asset (overlay) channel this means the funding output --
which anchors the asset commitment -- is spent by a transaction that
does not re-commit the assets, irrevocably destroying them on-chain.
The aux closer then fails to finalize the confirmed close (it was
never asked to produce vPackets), which blocks the chain watcher's
coop close handler and leaves the channel stuck in waiting-close.

See lightninglabs/taproot-assets#2196 for an instance of this
happening in the wild.

Extend rbfCoopCloseAllowed to take the channel type: it now requires
the RBF feature bits AND that the channel type carries no tapscript
root, and is used at every site that chooses between the RBF closer
and the legacy negotiate closer. The RBF close actor's own eligibility
check is dropped entirely: an actor is only ever registered after
initRbfChanCloser has vetted the channel, so the check was redundant.
Aux channels now always fall back to the legacy closer, which is
aux-aware, regardless of the negotiated feature bits. Since no RBF
msg-router endpoint is registered for aux channels, an incoming Shutdown
from the peer likewise falls through to the legacy close handling. As a
backstop, initRbfChanCloser now refuses to construct an RBF closer for
aux channels outright.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a bug in LND where a new cooperative channel-closing mechanism (RBF coop close) was being used for special 'aux' channels that carry Taproot Assets. Those aux channels need extra steps to safely move the assets out, but the RBF close machine skipped those steps. If triggered, the closing transaction would spend the channel's funding output without preserving the asset commitment, effectively destroying the committed assets on-chain and leaving the channel stuck in a 'waiting-close' state. The fix forces aux channels to use the older, aux-aware close path even when both peers support the new RBF feature.

Recommended action

Upgrade LND nodes that may open or operate taproot asset overlay channels to a release containing this commit. Verify that no aux channels were closed via the RBF path while running affected code; affected closes would require manual recovery and asset-state inspection. Review other feature-gated flows for similar channel-type assumptions.

Security signals we found

01

Loss-of-funds / asset-destruction bug for aux (taproot asset overlay) channels

02

Channel-stuck / denial-of-service side effect (waiting-close state)

03

Feature-bit selection bypassed per-channel safety checks

04

Missing integration of aux closer hooks in RBF close state machine

05

Fix includes defense-in-depth: predicate change, redundant actor check removal, and constructor backstop

Risk score

Why this scored 74/100

Our methodology →
Potential impact 25/30
Exploitability 15/25
Stealth signal 10/15
Affected reach 10/15
Confidence 9/10
Evidence quality 5/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.