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

Detect and fail-back monitor-blocked un-forwarded HTLCs at close

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Detect and fail-back monitor-blocked un-forwarded HTLCs at close

If we have pending HTLCs which we intended to forward, but which
were waiting on a `ChannelMonitorUpdate` to be forwarded when we
closed, they will neither be in the `ChannelMonitor` nor in the
`Channel` in a state which indicates they need to be failed (i.e.
in the holding cell). As a result, we previously did not fail such
HTLCs back immediately. Note that we cannot rely on the catch-all
fail-back-before-channel-closure logic either as it is done by the
`ChannelMonitor` that is unaware of these HTLCs.

Here we fix this by detecting the specific case - HTLCs which are
in `LocalSent` (i.e. the counterparty has not provided an RAA yet)
and we have a blocked `ChannelMonitorUpdate` containing a remote
commitment transaction update (which will always contain the HTLC).

In such a case, we can be confident the counterparty does not have
a commitment transaction containing the HTLC, and can fail it back
immediately.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug in the Lightning Dev Kit where certain pending forwarded payments could get stuck and not be returned to the sender if a channel closed at exactly the wrong moment. Normally, stuck payments are automatically failed back, but a specific edge case involving a delayed channel-monitor update caused the software to lose track of them. The fix detects these stranded payments during channel closure and immediately fails them back so funds are not left in limbo.

Recommended action

Review the new closure-time HTLC scan for correctness and completeness, ensure the regression test covers both monitor-update step variants, and consider whether any other blocked-update states could strand HTLCs similarly.

Security signals we found

01

Funds-availability / stuck-HTLC bug fixed

02

Channel closure edge case with incomplete monitor update

03

Missing fail-back of un-forwarded HTLCs

04

Regression test added for the exact failure path

Risk score

Why this scored 66/100

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